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

Patrick Roozen
0 0
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:
DG Admin
And the Data Guard Performance page shows:

DG Performance

Data Guard DGMGRL view of the configuration is:

DG DGMGRL

Screen Shot 2014-07-09 at 14.08.50 pm

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):
Verify configuration progress
And it completes with warnings:
Verify Configuration Results

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:

Screen Shot 2014-07-09 at 14.15.25 pm

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

na verifyScreen Shot 2014-07-09 at 15.06.25 pm

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.

Screen Shot 2014-07-09 at 14.19.11 pm
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:

Screen Shot 2014-07-09 at 14.33.15 pm

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…

About Post Author

Patrick Roozen

Patrick is an Oracle consultant at AMIS interested in storage, hardware, Solaris, Linux, Weblogic, performance, the Oracle Database and much more.
Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %
Next Post

Google Glass from a developers perspective

During the last two weeks I have had the opportunity to work on a proof of concept that uses the Google Glass. In this post I will share my experiences with this device from a developers perspective. Related posts: 2 dagen seminar door Steven Feuerstein: Best of Oracle PL/SQL (8 […]
%d bloggers like this: