How do you apply a Patchset,PSU or CPU in a Data Guard Physical Standby configuration [ID 278641.1]
		修改时间 04-JUN-2010     类型 HOWTO     状态 PUBLISHED

In this Document
  Goal
  Solution
     
  References

---

Applies to:

Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 11.2.0.1.0 - Release: 10.1 to 11.2
Information in this document applies to any platform.

Goal

To apply an Interim Patchset for example the 10.2.0.4 Patchset or January 2010 10.2.0.4 RDBMS PSU, to both the Primary and Standby Sites.

Configurations with a logical standby should refer instead to My Oracle Support Article "Upgrading Oracle Database with a Logical Standby Database In Place (Doc ID 437276.1)".


The process for applying the Patchset/PSU/CPU to a Primary and Standby site will be the same as that used to apply a patchset.   The following is one approach to performing this task:

Solution

Process Overview:

1. In the primary disable log shipping to the standby site.

2. Shutdown the standby site and apply interim patchsets to the RDBMS binaries as per the README. This includes Patchset/Patchset Update(PSU)/Critical Patch Update (CPU). You will not be able to and do not need to run the scripts(catpatch.sql etc) against the standby rdbms itself.

3. Shutdown the primary site and apply the Patchset/PSU/CPU patch to the RDBMS binaries as per the README.

4. Start the primary site, re-enable log shipping to the standby and patch the RDBMS itself using the instructions in the README (run catpatch/catbundle/catcpu etc).

5. At the standby site restart redo apply/managed recovery and the RDBMS changes implemented in the Primary Site through catpatch/catbundle/catcpu will also be applied to the standby.

The Interim Patchset application in detail - in this case 10.2.0.4 PSU 3 or Patch 9119284

1. If you are using a Data Guard Broker configuration, in the Primary Site disable archiving to Standby Site.

If this is RAC you will need to ensure that archiving is disabled from all Primary Site Instances. When a Data Guard Broker configuration is in place this will be managed through dgmgrl. If you are using sqlplus and DO NOT have a broker configuration this would need to be performed from the sql prompt.

1.1 Disable log shipping using DGMGRL.




OR

1.2 If you are managing the environment using sqlplus

In this case you DO NOT have a Data Guard Broker configuration disable the destination used to ship archives from the primary to the standby site using sqlplus.






2. Apply the patch at the Standby Site binaries.

If this is a RAC standby this patch application would occur across all nodes.

2.1.1 If this is a single instance environment shutdown ALL processes running from the home.

This will include all listeners, database instances, asm instances etc running from the home to patched.




OR

2.1.2 If this a RAC standby shutdown all the RAC services that are running from the ORACLE_HOME to be patched.

In this case the RAC database is called plb and the listener name for the listener running from the ORACLE_HOME to patched is lsnrplb.





2.2 The release of OPatch that is supplied with 10.2.0.4 will not be able to apply a PSU as seen through the errors below.





2.2.1 To overcome the patch issue apply the latest copy of OPatch to the home via Patch 6880880.

If you already have a later release of OPatch then it is not necessary to perform. this step.

Download Patch 6880880 and following the install instructions in the README




2.3 Once the new release of OPatch is in place apply the patch to the Standby Site

Please Note: In the Standby Site only the patching of the binaries is performed, there is no need to run the catupgrade/catcpu/catbundle.sql script. as this will be performed through redo apply at the Standby Site.


The example below is applying the patch to a Single Instance Standby Site and its applying PSU Patch 9119284.





2.4 Start the Standby Site database to mount and restart the listener(s).

2.4.1 If the environment is a single instance (non-RAC standby)

Start the listener:



Start the database:



OR

2.4.2 If this is a RAC standby






3. Apply the Patch to the Primary.

Please Note: the primary site may also require that Opatch be upgraded in the same way as it was in the Standby Site via Patch 6880880.

Change to the patch directory at the Primary Site and apply the PSU here





3.1 Stop all processes running from the home being patched.

This will include listeners and databases etc.


3.1.1 If this is a single instance Primary (non-RAC)




OR

3.1.2 If this is a RAC Primary Site





3.2 Apply the patch to the Primary Site binaries.

As per the standby site this example is applying Patchset Update 9119284 to a single instance Primary Site.





3.3 Upgrade/Patch the RDBMS and dictionary objects.

In a RAC environment this is performed from once instance only with the remaining cluster instances down and not running. The example below once again shows patch application to a single instance (non-RAC) Primary Site and is applying PSU 9119284.

Change to the $ORACLE_HOME/rdbms/admin directory where the patch has been applied and perform. the following.










4. Re-establish the Data Guard environment at the Primary Site.

4.1.1 In a Single Instance Primary restart processes running from the patched ORACLE_HOME.

This will include the listener, database instances, ASM instance and any other processes that were previously running from this ORACLE_HOME.




OR

4.1.2 If this were a RAC environment restart the listeners on each node running from the ORACLE_HOME being patched using srvctl.





4.1.3. Force the Primary to register its services with the listener.




4.2.1 In a single instance (non-RAC) disable restricted session to allow end user connectivity.




OR

4.2.2 In a RAC Primary Site restart the primary site and all its instances




If there are additional RAC services used to connect to this database these will need to be restarted using srvctl




4.3 Re-enable log shipping to the Standby Site.

This will allow the RDBMS changes made through running catupgrade/catbundle/catcpu can be applied to the standby.

4.3.1 If you are using a Data Guard Broker configuration




OR

4.3.2 If you are using sqlplus re-enable the archive destination used to ship archives from the Primary Site to the Standby Site




Where X is the number of the destination used for shipping redo to the standby site.



5. The Primary will then resume shipping and media recovery will continue at the Standby site and apply the changes made through the patch application at the Primary Site.

From the alert log at the Standby you will see logs generated during the running of the cat scripts shipped and applied to the standby:






6. To check the patch has been applied successfully at the primary and standby sites perform.

In this case it was the PSU Patch 9119284.

Please Note: Currently (10.2.0.4 PSU's) do not update the header information for tools like sqlplus nor the versioning information for the database. These will remain at 10.2.0.4.0 and NOT updated to 10.2.0.4.3 for example after the application of the PSU. You will only be able to see the PSU's application through the inventory or looking at the version





OR

In the case of a PSU examine the registry history view.

References

NOTE:241374.1 - Script. to Collect Data Guard Primary Site Diagnostic Information
NOTE:241438.1 - Script. to Collect Data Guard Physical Standby Diagnostic Information
NOTE:437276.1 - Upgrading Oracle Database with a Logical Standby Database In Place
NOTE:756671.1 - Oracle Recommended Patches -- Oracle Database