環境：RHEL6.5 + Oracle 11.2.0.4 DataGuard physical standby
主庫和備庫都是單節點。
需求：主備庫同時應用160719的PSU和OJVM PSU補丁。
先參考MOS文檔 ID 278641.1 的解決方案如下：
SOLUTION
Process Overview:
In the primary disable log shipping to the standby site.
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. Start the standby site to mount only, do not restart managed recovery.
Shutdown the primary site, apply the Patchset/PSU/CPU patch to the RDBMS binaries and patch the RDBMS itself using the instructions in the README (run catpatch/catbundle/catcpu etc).
NOTE: The latest Patchsets for Oracle 11gR2 (11.2.0) require to be installed into a new ORACLE_HOME. So mind to reset your Environment and copy corresponding Files (like SPFILE, Network Files,..) to the new ORACLE_HOME, too. Follow the Database Upgrade Guide for further Details.
Start the primary site, re-enable log shipping to the standby.
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.
NOTE: Step 5. should be done immediately after upgrading the Database Binaries on the Standby Database. It is to ensure the Data Dictionary (CATPROC)-Version matches the Version of the Database Binaries. If this does not match (eg. when you upgrade the Standby Database Binaries first and perform a Role Change on the Standby before you upgrade the Primary) you may run into severe Problems. Having different Patchlevels in a Data Guard Physical Standby Database Environment is not supported anyway, see
Mixed Oracle Version support with Data Guard Redo Transport Services (Doc ID 785347.1)
for further Details and Reference.
- Checks to perform to ensure the patch has been applied successfully at the primary and standby sites.
提煉核心步驟就是：
- 1.主庫禁用日志傳送到備庫
- 2.關閉備庫應用補丁，但不執行腳本(catpatch.sql等)，啟動到mount，不啟用日志恢復
- 3.關閉主庫應用補丁，執行腳本(run catpatch/catbundle/catcpu等)
- 4.啟動主庫，重新開啟日志傳送到備庫
- 5.備庫開啟日志恢復
- 6.檢查補丁應用情況
1.主庫禁用日志傳送到備庫
``` 主庫； show parameter log_archive_dest_state_X alter system set log_archive_dest_state_X=defer scope=both sid='*';SQL> show parameter log_archive_dest_2
NAME TYPE VALUE
log_archive_dest_2 string SERVICE=ZHZYNEW2 ASYNC LGWR VA
LID_FOR=(ONLINE_LOGFILES,PRIMA
RY_ROLE) DB_UNIQUE_NAME=ZHZYNE
W2
SQL> show parameter log_archive_dest_state_2
NAME TYPE VALUE
log_archive_dest_state_2 string enable
所以我這里的環境執行：
SQL> alter system set log_archive_dest_state_2=defer scope=both;
<h1 id="2">2.關閉備庫應用補丁，但不執行腳本(catpatch.sql等)，啟動到mount，不啟用日志恢復</h1>
lsnrctl stop
SQL> shutdown immediate;
1).OPatch更新
2).應用PSU補丁 但不執行數據庫腳本
3).應用OJVM PSU補丁 但不執行數據庫腳本
NOTE:上面步驟跟《[Oracle 11.2.0.4單實例打PSU,OJVM PSU補丁快速參考](http://www.cnblogs.com/jyzhao/p/5895617.html)》區別不大，但是注意只是軟件應用補丁，不要執行數據庫腳本。
最后啟動數據庫到mount，啟動監聽
SQL> startup mount;
lsnrctl start
<h1 id="3">3.關閉主庫應用補丁，執行腳本(run catpatch/catbundle/catcpu等)</h1>
lsnrctl stop
SQL> shutdown immediate;
1).OPatch更新
2).應用PSU補丁 執行數據庫腳本
3).應用OJVM PSU補丁 執行數據庫腳本
<h1 id="4">4.啟動主庫，重新開啟日志傳送到備庫</h1>
最后確認正常啟動主庫數據庫和監聽, 然后重新開啟日志傳送到備庫
SQL> alter system set log_archive_dest_state_X=enable scope=both sid='*'
這里環境就是：
SQL> alter system set log_archive_dest_state_2=enable scope=both;
<h1 id="5">5.備庫開啟日志恢復</h1>
mount狀態開啟日志恢復：
SQL> startup mount;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE disconnect;
最終可以切換為ADG：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE OPEN;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
<h1 id="6">6.檢查補丁應用情況</h1>
$ORACLE_HOME/OPatch/opatch lspatches
$ORACLE_HOME/OPatch/opatch lsinventory
SQL> select ACTION_TIME,ACTION,NAMESPACE,VERSION,BUNDLE_SERIES,ID from registry$history;
這里尤其注意第三項，備庫只有在ADG模式下才可以查詢。
主庫補丁應用的查詢結果：
SQL> r
1* select ACTION_TIME,ACTION,NAMESPACE,VERSION,BUNDLE_SERIES,ID from registry$history
ACTION_TIME ACTION NAMESPACE VERSION BUNDLE_SERIES ID
24-AUG-13 12.03.45.119862 PM APPLY SERVER 11.2.0.4 PSU 0
08-JUL-16 02.50.00.349757 PM APPLY SERVER 11.2.0.4 PSU 0
22-SEP-16 03.48.39.295292 PM jvmpsu.sql SERVER 11.2.0.4.160719OJVMPSU 0
22-SEP-16 03.49.37.935537 PM APPLY SERVER 11.2.0.4 PSU 160719
22-SEP-16 03.51.55.999773 PM APPLY SERVER 11.2.0.4.160719OJVMPSU 0
22-SEP-16 03.51.56.010800 PM APPLY 23177551
6 rows selected.
ADG模式下，最終備庫補丁應用的查詢結果：
SQL> select ACTION_TIME,ACTION,NAMESPACE,VERSION,BUNDLE_SERIES,ID from registry$history;
ACTION_TIME ACTION NAMESPACE VERSION BUNDLE_SERIES ID
24-AUG-13 12.03.45.119862 PM APPLY SERVER 11.2.0.4 PSU 0
08-JUL-16 02.50.00.349757 PM APPLY SERVER 11.2.0.4 PSU 0
22-SEP-16 03.48.39.295292 PM jvmpsu.sql SERVER 11.2.0.4.160719OJVMPSU 0
22-SEP-16 03.49.37.935537 PM APPLY SERVER 11.2.0.4 PSU 160719
22-SEP-16 03.51.55.999773 PM APPLY SERVER 11.2.0.4.160719OJVMPSU 0
22-SEP-16 03.51.56.010800 PM APPLY 23177551
6 rows selected.
至此已確定主庫備庫都已經成功完成應用PSU，OJVM PSU補丁。
<h1 id="7">Reference</h1>
- How do you apply a Patchset,PSU or CPU in a Data Guard Physical Standby configuration (文檔 ID 278641.1)