Oracle PSU（Patch Set Update）升級是 DBA 核心技能。本文記錄一次真實的 .patch_storage 目錄誤刪導致 opatch apply 失敗，通過備份節點拷貝目錄成功修復的完整過程，並總結官方修復方案與手工打補丁最佳實踐。
opatch apply 時發現之前備份的 .patch_storage 目錄被誤刪除。opatch 報錯無法繼續，提示缺少元數據目錄。官方 MOS 文檔 (Doc ID 1641136.1) 給出三種方案：
| 方案 | 操作 | 優點 | 缺點 |
|---|---|---|---|
| 1. 還原備份 | 從備份介質恢復完整 .patch_storage 目錄 | 最快、最完美、無風險 | 需有效備份 |
| 2. 重裝 ORACLE_HOME | 完全重新安裝 Oracle Home 並重新應用所有補丁 | 徹底乾淨 | 耗時極長、業務停機久、風險大 |
| 3. 克隆同環境 Home | 從完全一樣的環境（同版本、同補丁）克隆 ORACLE_HOME | 比重裝快 | 極難找到 100% 一致環境、克隆後仍需驗證 |
幸運的是節點 2 未動過目錄。採用方案 1 變體：從節點 2 拷貝目錄到節點 1。
# 節點 2 上打包
tar -czf patch_storage.tgz -C $GRID_HOME .patch_storage
tar -czf patch_storage_db.tgz -C $ORACLE_HOME .patch_storage
# 傳輸到節點 1
scp patch_storage.tgz node1:$GRID_HOME/
scp patch_storage_db.tgz node1:$ORACLE_HOME/
# 節點 1 解壓還原
cd $GRID_HOME && tar -xzf patch_storage.tgz
cd $ORACLE_HOME && tar -xzf patch_storage_db.tgz關鍵點： 保持目錄結構、權限、屬主完全一致。解壓後無需任何修改，直接執行 opatch apply 即可成功。
作者習慣手工逐節點打補丁，避免 opatch auto 環境變量、權限、SSH 等不可控因素導致失敗。
# 1. 解壓補丁包
unzip p20420937_112040_Linux-x86-64.zip # 含 3 個子補丁
# 2. 停止目標 Home 服務（DB Home 需停數據庫實例，GI Home 需停 CRS）
# 3. 進入各子補丁目錄依次應用
cd 20420937 # OCW PSU
opatch apply
cd ../20299019 # ACFS PSU
opatch apply
cd ../20299013 # Database PSU
opatch apply
# 4. 驗證清單
opatch lsinventory # 確認三個補丁均顯示 applied
sqlplus / as sysdba
SELECT * FROM dba_registry_history; # 確認數據庫級別記錄OPatch succeeded.
Interim patches (3) :
Patch 20420937 : applied on Sun Apr 19 14:36:44 CST 2015 -- OCW PSU 11.2.0.4.6
Patch 20299019 : applied on Sun Apr 19 14:30:46 CST 2015 -- ACFS PSU 11.2.0.4.6
Patch 20299013 : applied on Sun Apr 19 14:24:45 CST 2015 -- Database PSU 11.2.0.4.6
Sub-patch 19769489 (PSU 11.2.0.4.5) ...
Sub-patch 19121551 (PSU 11.2.0.4.4) ...
...
Rac system comprising of multiple nodes
Local node = elvis111
Remote node = elvis112dba_registry_history 顯示歷史遞進：11.2.0.4.5 -> 11.2.0.4.6。
opatch auto 黑盒。此次事件雖驚險，但通過冷靜分析、利用 RAC 多節點冗余特性，零代價完成修復。再次驗證：備份是容錯的基石，熟悉工具原理是化險為夷的關鍵。
