The last few months I’ve been working with Oracle Data Guard, reading lots of manuals and (parts of) books, to make smart decisions and get a solid foundation. I consider myself part of the people who like to work with the command line. That way you really get to understand what you are doing and you won’t have to panic when you don’t have a GUI at your disposal. Once that’s an acquired skill I will look at the GUI’s.
So now I’m ready to integrate my existing Primary and Standby RAC databases into OEM Cloud Control. FYI I’m using Oracle Enterprise Edition 11.2.0.4 without Active Data Guard on Red Hat Linux 6.5 with OEM Cloud Control 12.1.0.4.
The landscape looks as follows: I’ve got a 2 node cluster in data center A and a 2 node cluster in data center B. The cluster in data center A has a Primary RAC database that is replicated via Data Guard to a Standby RAC database in data center B. And I have a different Primary RAC database in data center B that is replicated the same way to a Standby RAC database to data center A. So four databases in total on two clusters.
First I deploy the necessary agents on the hosts involved, then I manually add my targets that are on hosts. I immediately see a difference between the target names Cloud Control is using for the Primary RAC database versus the Standby RAC database. For the primary database (BIJS2A) it is using target names like: BIJS2A_wesb-a-ora02_BIJS2A1 etc. But for the standby database (BIJS2AD) it wants to use a name like: BIJS2AD_BIJS2AD1 etc. I do not like that and thus change it to include the cluster name of it’s cluster, similar to the target names of the primary database.
Once that’s done I look at the new database targets (with a filter on it to keep the screenshots uncluttered)
My standby database is not recognized as such, and appears to be down. But I know for a fact that it is up but only mounted (No Active Data Guard, remember?).
When trying to connect to that database in SQL*Plus with the dbsnmp user I get the same error that I ignored while adding the database to Cloud Control: ORA-01033 ORACLE initialization or shutdown in progress.
But I have no issues logging on with a sysdba user. So let’s change the monitoring configuration:
And supply the corresponding password:
And now Cloud Control recognizes my standby database as such:
Now take a look at the Data Guard Administration page for the primary database and we see several things (highlighted):
- The name of the primary cluster database is different then I used in my Broker configuration
- It’s cluster name is correct
- The standby cluster database HAS the name I used in my Broker configuration
- It’s cluster name is missing / unknown.
Clicking on the “verify configuration” link will result in errors mentioning that the Data Guard configuration could not be verified.
Logging on to dgmgrl and showing the database properties for the Primary and Standby shows:
Somehow the Enterprise Manager Name shows up for the primary database but not the standby database.
Having a look at the Broker log file shows that the following commands have been executed (I’m not sure when, but I believe it was during the “verify configuration” that I executed in Cloud Control).
EDIT DATABASE BIJS2A SET PROPERTY DbDisplayName = BIJS2A_wesb-a-ora02 EDIT DATABASE BIJS2A SET PROPERTY ClusterName = wesb-a-ora02
So let’s repeat similar code in dgmgrl for the standby database.
EDIT DATABASE BIJS2AD SET PROPERTY ClusterName = wesb-a-ora01; EDIT DATABASE BIJS2AD SET PROPERTY DbDisplayName = BIJS2AD_wesb-a-ora01;
But this results in a lowercase display name (in DGMGRL and Cloud Control).
So repeat is with quotes at the appropriate places:
EDIT DATABASE BIJS1A SET PROPERTY DbDisplayName = 'BIJS1A_wesb-a-ora01'; EDIT DATABASE BIJS1A SET PROPERTY ClusterName = wesb-a-ora01;
And this results in the following view in Cloud Control:
And clicking on the “verify configuration” link will now succeed.
