I got a demand for identifying the Oracle Active Data Guard on servers… so created this pattern which others might find useful.

Data Guard replicates data between a active database and a standby database (often in totally different physical locations).

Pattern only identifies the product and creates an instance based SI related to its database… I am still looking for ways to identify the communication relationship between the active and standby nodes. Any input on this is highly appreciated as we have not identified any good source for this information in the servers.

Edit:
Pattern replaced with minor changes after feedback below

if you have LSOF available… they you may be able to infer the primary/standby relationship via the “communicatingSi” function of the query lanuage. 

Both the primary and the standby should be discoverable as regular oracle databases (although you won’t be able to perform any database discovery on the standby since its in restriced access mode)

If you have processToPort data (which comes from lsof-i on some platforms, netstat on others) you might be able to find the connection.

However that relies on it being either a static connection or at least reasonably likely to be observed by discovery.

It also relies on the process opening the connection being the Data Guard Daemon, if in fact the daemon instructs the main oracle process to open the communication then the picture is a lot more complex.

As an aside Petrus I’m not sure you want to pull in the other Oracle processes as Associates as really they are components of the main Oracle SI and not the Data Guard Daemon. If you feel it’s important to do so then it’s probably better to find them via the Oracle SI

Final note, if there are two instances of Oracle running then this SI will be related to *both* of them.

From what I understand, the communiction between the active and standby nodes are not initiated by the dmon process… which makes it a bit more tricky. I was/am hoping for some ini or conf file on the db server to hold the configuration.

Charles, thanks for the feedback. I removed the Oracle processes from being related to the SI (makes sense)... also removed the for loop when relating to the DB SI…  The DB SI is related by its uniquely identified SID, so there should not the Data Guard should not be related to every DB SI on the server…

Found a way :)
The below commands are (in order)
“dgmgrl” (DataGuard Manger)
“connect sys@it0227elm7_0” (connect sys@<database name>
“Password:”
“show configuraton”

The output provides information about the current database (being the

From this information we can create a relationship type between the databases.

Another option for this is to do a normal search query from the pattern to look for a DB SI where type = %type% and instance = %instance% on another host from where the pattern is triggered.

Apparently the Oracle Data Guard requires the two databases (primary and standby) to share the same SID, only DB Unique Name / Global DB Name is unique. On the other hand, the SID is not unique on a “normal” database either. :)

For the pattern provided in this thread, I will develop both approaches, using the SQL method as the primary and if that fails, use the search method to link the two. This will of course require the pattern to obtain DB Unique Name and / or Global DB Name attributes as well…
Is there any TPL function to get these values and attributes from the Oracle DB pattern for instance?

Petrus,

Is this for the databases to have the same SID on the same host or separate hosts?

The current Oracle RDBMS pattern (TKU June) tries to obtain global DB name if it can.

The “issue” I´ve seen around Data Guard is that the Data Guard databases (active and standby) MUST share the same SID!!! Global DB Name is highly unique, as seen in the example output… but to obtain the standby Global DB Name you must enter the DGMGRL menu in the host running the active db.

A less reliable way could be to look for a DB instance with an identical SID on another than the one that is scanned. That would PROBABLY pick up the standby DB but it is not possible to confirm without DGMGRL command. :(

This is the “approved” pattern by my DBAs.
In this pattern we assume that the 2 nodes running DataGuard (active and passive node) are sharing the same exact SID, and that no other nodes are sharing the same SID.
As a fail-safe, we make the communication relationship between the active and passive SI between the Oracle Data Guard SIs, and NOT the Database SI. This way, IF some other database instance is running the same SID as the setup Data Guard monitored databases, those will NOT be included in the created relationship.

i:e - This pattern does NOT use any “deep” discovery as was suggested by me earlier in this thread.

Petrus Johansson - 22 July 2010 06:15 AM

i:e - This pattern does NOT use any “deep” discovery as was suggested by me earlier in this thread.

This can often be the hardest call in developing patterns, the robust deep way that is technically correct but is much more likely to fail due to permissions et al; or a simpler way that succeeds very often and is very often correct enough. I think in this case you made the right call.