Two Interesting Scenario in 11g RAC

From: Sanjay Mishra <>
Date: Wed, 2 Dec 2009 10:15:46 -0800 (PST)
Message-ID: <>

We are working on Oracle 11g R1 RAC setup and has seen two new issue and so want to check if this is correct or we missed something. This is The issue is linked to RAC1 (2-Node) and RAC2 (2-Node) Datagaurd environment. Standby was created as per Oracle Best Practices using the following Command DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE   What was found is the DBID is different on both Primary and Standby Server. The issue is not to our setup with the different DBID as we are able to switchover as well as failover and several test been done successfully and recovered. We are using Dataguard broker in the setup. There are some software which are not recognizing the Standby correctly like BMC Sqlbacktrack newer version has special Setup for Standby Monitoring but it is not able to recognize it as it use to Compare DBID as well as 2-3 more columns value.  IS IT something always happened as I personally never use the above command and had created Standby database using rman backup copy and Creating standby controlfile and found the same DBID with RAC and non-RAC database but all 10g environment     Secondly I am doing Swithover and Failover and been able to do it successfull including reinstate after the failover with Flashback setup. Interesting Scenario is that I stopped both RAC Cluster means CRS down on all nodes and then tried to bring it up. Both Shutdown and startup gracefull and so no crash or so. The intereseting point is that Oracle has started both RAC1 and RAC2 in MOUNT mode and so dataguard Broker is giving error that PROTECTION LEVEL is not matching PROTECTION MODE. Is it True and anyone has experience it before. I had resolution that I stop the Database on PRIMARY one and then modify the DATABASE with -s option to make it OPEN and restarted the database and everything is back.   So if somebody can share the views on such scenario   Sanjay
Received on Wed Dec 02 2009 - 12:15:46 CST

Original text of this message