Cloud Control: How a Camel can make you cross a Data Guard Mountain

Read Time:2 Minute, 37 Second

In my recent post I already mentioned it a little bit: Integrating your manual Data Guard Broker configuration in OEM Cloud Control can become a sort of climbing a Mountain. And it doesn’t have to be.

But first a short description of the situation. I have a working Data Guard broker configuration between two Cluster Databases running Oracle 11.2.0.4 on linux x86-64. Both clusters have an Cloud Control agent (12.1.0.4) deployed on all the nodes in question. De databases are monitored just fine and accessible via Cloud Control. But the Data Guard Admin page shows:

And the Data Guard Performance page shows:

Data Guard DGMGRL view of the configuration is:

When you press the link “Verify Configuration” under the Additional Administration heading in the Data Guard Admin page Cloud Control starts to verify your Data Guard configuration (and changing it, but more on that later):

And it completes with warnings:

But it has changed some things in my broker configuration because when you look at the Data Guard Admin page and the Data Guard Performance Page now the following shows:

Thus the configuration is now recognized by Cloud Control.
In DGMGRL some things have obviously changed:

Nothing to big to deal with so far (Just have a look at your broker log file to see what else Cloud Control has changed).

But let’s remove the broker configuration via Cloud Control (with preserve all standby settings), and then add the Standby database again.

When that has finished DGMGRL will show:

and that is expected of course.

The Data Guard Admin page briefly showed the notification that the broker wasn’t configured but still shows some graphs for the Redo Generation Rate, Lag times and Apply rate.

Then I added the Standby Database again via:

Select the correct standby database (the one you just had removed):

Click next and expand the Data Guard Connect Identifiers to check if we still use the tnsname entries that I had created specifically for the Data Guard connection. That is not the case:

So I change them back to what I want:

Click next and Finish.

Now when we look at DGMGRL we see that the configuration name has changed somewhat:

But when I want to show my database configuration it doesn’t find my database! Huh??

You suddenly need to use quotes around your database names to make them (Camel)Case sensitive. Use Single or double quotes:

But I’m more concerned with the change in database “broker” parameters. I had configured one broker config file in +DATA and one in +FRA. Both in a sub directory called BROKER, but both have been changed to the same +DATA location (different file names) but no longer in my BROKER sub directory.
So I will need to set the dg_broker_start parameter to FALSE, change the config file locations to where I want them and set the start parameter to TRUE again. It bothers me that I wasn’t asked where I wanted the broker configuration files, and that the old broker config files are still there on ASM. That leaves room for errors in the future…