According to metalink note
278641.1 before applying a patch to a physical standby environment log transport must be stopped on the primary site. Although the note says to shutdown all standby instance, it should still be possible to do a rolling patch on the standby environment if patch allows it. However recovery may need to be stopped before patching and since redo transport is stopped, there won't be anything to recover anyway.
From 11.2.0.1 onwards if the patch set says it's applicable in a standby-first manner then these patches could be applied on standby without stopping redo transport nor recovery on the standby database.
This post shows the highlights of applying GI PSU 11.2.0.3.4 (which is a rolling and Standby-First applicable patch) to a
physical data guard environment.
Before the patch apply both standby and primary are at the same patch level.primary
rac5 psu]$ /opt/app/oracle/product/11.2.0/db_2/OPatch/opatch lsinventory -local | grep "Database Patch Set Update"
Patch description: "Database Patch Set Update : 11.2.0.3.3 (13923374)"
Sub-patch 13696216; "Database Patch Set Update : 11.2.0.3.2 (13696216)"
Sub-patch 13343438; "Database Patch Set Update : 11.2.0.3.1 (13343438)"
Standby
rac5b psu]$ /opt/app/oracle/product/11.2.0/db_2/OPatch/opatch lsinventory -local | grep "Database Patch Set Update"
Patch description: "Database Patch Set Update : 11.2.0.3.3 (13923374)"
Sub-patch 13696216; "Database Patch Set Update : 11.2.0.3.2 (13696216)"
Sub-patch 13343438; "Database Patch Set Update : 11.2.0.3.1 (13343438)"
Identify the apply instance and start patch applying on the none apply instance first
show database rac11g2s
Database - rac11g2s
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
Real Time Query: OFF
Instance(s):
rac11g2s1 (apply instance)
rac11g2s2
Database Status:
SUCCESSIn this case apply instance was rac11g2s1 running on rac4b hence patching will being on rac5b.
Once patched rac5b will be at a higher patch level than rac4b and all nodes on primary
rac5b psu]$ /opt/app/oracle/product/11.2.0/db_2/OPatch/opatch lsinventory -local | grep "Database Patch Set Update"
Patch description: "Database Patch Set Update : 11.2.0.3.4 (14275605)"
Sub-patch 13923374; "Database Patch Set Update : 11.2.0.3.3 (13923374)"
Sub-patch 13696216; "Database Patch Set Update : 11.2.0.3.2 (13696216)"
Sub-patch 13343438; "Database Patch Set Update : 11.2.0.3.1 (13343438)"
Switch the apply instance to patched node and patch the remaining nodes as well
DGMGRL> edit database rac11g2s set state ='APPLY-ON' with apply instance = 'rac11g2s2';
Succeeded.
DGMGRL> show database rac11g2s
Database - rac11g2s
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
Real Time Query: OFF
Instance(s):
rac11g2s1
rac11g2s2 (apply instance)
Database Status:
SUCCESS
rac4b ~]$ /opt/app/oracle/product/11.2.0/db_2/OPatch/opatch lsinventory -local | grep "Database Patch Set Update"
Patch description: "Database Patch Set Update : 11.2.0.3.4 (14275605)"
Sub-patch 13923374; "Database Patch Set Update : 11.2.0.3.3 (13923374)"
Sub-patch 13696216; "Database Patch Set Update : 11.2.0.3.2 (13696216)"
Sub-patch 13343438; "Database Patch Set Update : 11.2.0.3.1 (13343438)"At this stage all Oracle binaries in standby environment are patched.
It is possible to run the data guard configuration like this with primary and standby at different patch level but there are limitations to how long this configuration will be supported (less than 1 month) and these are explained in
1265700.1. This gives time to evaluate the patch either by creating a snapshot standby or with role transition.
Once patch is evaluated on standby environment apply it on the primary site as well. Since this patch is applicable in a rolling fashion log transport will be active at all times during the patch application.
DGMGRL> show database rac11g2
Database - rac11g2
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
rac11g21
rac11g22
Database Status:
SUCCESSAfter patching rac5
rac5 ~]$ /opt/app/oracle/product/11.2.0/db_2/OPatch/opatch lsinventory -local | grep "Database Patch Set Update"
Patch description: "Database Patch Set Update : 11.2.0.3.4 (14275605)"
Sub-patch 13923374; "Database Patch Set Update : 11.2.0.3.3 (13923374)"
Sub-patch 13696216; "Database Patch Set Update : 11.2.0.3.2 (13696216)"
Sub-patch 13343438; "Database Patch Set Update : 11.2.0.3.1 (13343438)"
Shutdown the remaining instances and apply the patch (rac4 in this case) and at the same time execute the post-installation tasks on the already patched instance.
After patching rac4
rac4 psu]$ /opt/app/oracle/product/11.2.0/db_2/OPatch/opatch lsinventory -local | grep "Database Patch Set Update"
Patch description: "Database Patch Set Update : 11.2.0.3.4 (14275605)"
Sub-patch 13923374; "Database Patch Set Update : 11.2.0.3.3 (13923374)"
Sub-patch 13696216; "Database Patch Set Update : 11.2.0.3.2 (13696216)"
Sub-patch 13343438; "Database Patch Set Update : 11.2.0.3.1 (13343438)"
Useful metalink notes
Oracle Patch Assurance - Data Guard Standby-First Patch Apply
[ID 1265700.1]
Mixed Oracle Version support with Data Guard Redo Transport Services
[ID 785347.1]
How do you apply a Patchset,PSU or CPU in a Data Guard Physical Standby configuration
[ID 278641.1]
