We need to upgrade our production database in a standby envirionment with Dataguard from 10.2 to 11G. The SAP oracle upgrade guide does not give any details regarding how to do this. Can we still use the SAP upgrade scripts and dbua.sap.sh to perform an upgrade in such an environment?
If the answer is yes, then my follow up question is : should we do a 'startup nomount' command on the standby with all env variables pointing to the new 11G environment and with an spfile having already all parameters set to the 11G values from oss note 1431798, including compatible set to '11.2.0' before we start the dbua.sap.sh script on the primary?
Reason I ask is because the dbua.sap.sh script will set the compatible parameter on the primary and the Metalink doc which explains how to upgrade oracle to 11G in an environment with physical standby says, and I quote : "the standby database should have a COMPATIBLE setting equal to, or higher than, the primary". I therefore assume it needs to be set on the standby before dbua_sap.sh starts if we want to use this SAP tool for the upgrade. Is that correct?
Or should we do a 'startup nomount' command on the standby with all env variables pointing to the new 11G environment but keeping the init parameters as they are for 10.2 and start the dbua.sap.sh script with the -no_compatible parameter?
Sorry, forgot to mention : Both primary and standby are already 10.2.0.4. Recreating the standby from the primary is one way to do it but we do not want to do that because it is a long & costly procedure and requires a lot of coordination with various teams in different data centers (Standby is in a different US State).
It is possible to upgrade the Physical Standby with upgrade logs from the Primary. It is just very unfortunate that SAP, although they support Dataguard, they do not explain how to use their upgrade scripts for a situation with a standby in place. I would just like clarification on how to use them, in specific to avoid incompatibility errors between the 2 during the upgrade.
howto proceed with the compatible parameter in a DG environemt is described very good in the official documentation (section B.4):
.. and yes you are right too - those upgrade scripts are a little bit "rude" in some enhanced environments.
Yes, it was actually reading that doc that made me ask the question in the 1st place. So can you canfirm that we need to run the dbua.sap.sh with the -no_compatible parameter?
This should avoid compatible being set to a higher version on the primary before we can do it on the standby.
Also, can you confirm if we need to mount the standby from the new 11G $oracle_home. The offical Oracle doc (Section B2 step 8) does not mention that detail
So can you canfirm that we need to run the dbua.sap.sh with the -no_compatible parameter?
Also, can you confirm if we need to mount the standby from the new 11G $oracle_home.
For sure - the official documentation states, that you should upgrade your standby database first like described in "Oracle Database Upgrade Guide" - and for that you have to change your oracle home. So you start your standby (in mount state !!) and start the recover mode with the new Oracle 11gR2 binaries before starting the upgrade on primary.
Just another (important) hint when running a physical standby with Oracle Data Guard 11.2:
We had upgraded from 10.2.0.4 to 126.96.36.199 production and standby database a week ago.
We upgraded production db.
After we opened standby db and upgraded it.
After I scratched the standby db and recreated it from the production db.
Pay attemption that standby db changes the behaviour in 188.8.131.52 from 10g.
For the switchover, follow the guide:Doc ID 1304939.1 11.2 Data Guard Physical Standby Switchover Best Practices using SQL*Plus