簡(jiǎn)介面向 Linux x86-64 平臺(tái)的 Oracle Database 11.2.0.4 官方 PSU 補(bǔ)丁包 p36575425是 2024 年 7 月發(fā)布的季度更新適用于需要保持?jǐn)?shù)據(jù)庫(kù)安全與穩(wěn)定的 DBA、系統(tǒng)管理員及企業(yè)運(yùn)維團(tuán)隊(duì)。該版本為長(zhǎng)期支持版補(bǔ)丁內(nèi)容涵蓋安全漏洞修復(fù)、穩(wěn)定性改進(jìn)和性能優(yōu)化可顯著降低生產(chǎn)環(huán)境運(yùn)行風(fēng)險(xiǎn)。資源為 zip 壓縮包共包含 2000 個(gè)文件其中以 732 個(gè) o 編譯對(duì)象和 693 個(gè) so 共享庫(kù)為核心文件支撐補(bǔ)丁的實(shí)際鏈接與替換同時(shí)提供 208 個(gè) xml 描述文件、164 個(gè) sql 腳本以及 class、jar、a、mk 等輔助文件便于安裝時(shí)校驗(yàn)、配置和擴(kuò)展壓縮包整體約 536MB。目前已有 911 人學(xué)習(xí)下載。借助該補(bǔ)丁包DBA 可在 Oracle 11.2.0.4 數(shù)據(jù)庫(kù)上執(zhí)行 OPatch 沖突檢測(cè)、補(bǔ)丁應(yīng)用和狀態(tài)核對(duì)并能對(duì)照其中的腳本與清單檢查補(bǔ)丁是否生效資源也適合作為補(bǔ)丁升級(jí)演練、版本回滾和故障排查的參考素材幫助運(yùn)維人員在正式變更前充分驗(yàn)證。 每個(gè)周末晚上還在折騰一個(gè) 11.2.0.4 的數(shù)據(jù)庫(kù)這在 2024 年聽起來(lái)確實(shí)挺魔幻但做了多年 DBA 的人都知道老版本 Oracle 的存量用戶比想象中多得多。最近剛好在處理一套 Linux x86-64 環(huán)境上的 11.2.0.4 數(shù)據(jù)庫(kù)需要上最新一季的 PSUPatch Set Update補(bǔ)丁補(bǔ)丁號(hào) p36575425對(duì)應(yīng)的版本串是 11.2.0.4.240717。整套流程走下來(lái)從下載補(bǔ)丁到驗(yàn)證完成差不多花了一個(gè)維護(hù)窗口中間還踩了幾個(gè)不算深但足夠煩的坑所以把完整過(guò)程整理成這篇文章。這篇文章寫給誰(shuí)兩類人最需要一類是還在維護(hù) 11.2.0.4 單機(jī)或 RAC 環(huán)境的運(yùn)維/DBA另一類是被等保檢查或安全通告逼著打補(bǔ)丁但不敢輕易動(dòng)手的同事。文章會(huì)覆蓋從補(bǔ)丁包識(shí)別、前置檢查、opatch 升級(jí)、正式 apply、SQL 腳本執(zhí)行到驗(yàn)證回滾的完整鏈路所有命令都是我在真實(shí)環(huán)境驗(yàn)證過(guò)的直接抄作業(yè)即可。1. 11.2.0.4熬到2024這個(gè)PSU補(bǔ)丁為何非打不可1.1 一個(gè)老版本的真實(shí)處境先說(shuō)明一個(gè)背景Oracle 11.2.0.4 是 11gR2 的最終版本官方 Premier Support 早就結(jié)束了現(xiàn)在能拿到的是 Sustaining Support 和部分 Extended Support 窗口下的更新。這意味著什么意味著你不會(huì)再有新功能但關(guān)鍵安全漏洞和嚴(yán)重 bug 的修復(fù)補(bǔ)丁依然會(huì)以季度 PSU 的形式發(fā)布。對(duì)于很多跑著核心業(yè)務(wù)、因?yàn)閼?yīng)用兼容性沒(méi)法升級(jí)到 12c/19c 的系統(tǒng)來(lái)說(shuō)打 PSU 幾乎是唯一能緩解安全隱患的手段。所以別覺(jué)得給 11.2.0.4 打補(bǔ)丁是無(wú)用功恰恰相反在一堆 CVE 通告面前季度 PSU 是你最實(shí)在的防線。等保測(cè)評(píng)里對(duì)數(shù)據(jù)庫(kù)安全補(bǔ)丁及時(shí)更新的要求也是靠這套機(jī)制來(lái)滿足的。p36575425 這個(gè)補(bǔ)丁從命名上拆解一下p36575425是 Oracle 官方補(bǔ)丁平臺(tái)的內(nèi)部補(bǔ)丁號(hào)。112040表示適用于 11.2.0.4.0 基礎(chǔ)版本。240717是補(bǔ)丁發(fā)布日期對(duì)應(yīng) 2024 年 7 月 17 日。平臺(tái)后綴Linux-x86-64就是 Linux 64 位標(biāo)準(zhǔn)版。補(bǔ)丁文件名一般是p36575425_112040_Linux-x86-64.zip大小通常在幾百 MB 到 1GB 不等。PSU 是一種累積補(bǔ)丁意思是只要你從 11.2.0.4.0 直接打這個(gè) PSU之前季度的安全修復(fù)和關(guān)鍵 bug 修復(fù)都會(huì)被包含進(jìn)來(lái)不需要先打之前的舊 PSU。這一點(diǎn)很關(guān)鍵很多新手會(huì)誤以為要按順序一個(gè)一個(gè)打其實(shí)不用。1.2 補(bǔ)丁包里的內(nèi)容構(gòu)成補(bǔ)丁包解壓后你會(huì)得到一個(gè)以補(bǔ)丁號(hào)命名的目錄里面包含etc/目錄補(bǔ)丁元數(shù)據(jù)opatch 依賴這些文件做沖突檢查和安裝。files/目錄真正的二進(jìn)制替換文件包括 oracle 可執(zhí)行文件、庫(kù)文件、SQL 腳本等。README.txt補(bǔ)丁的完整說(shuō)明文檔必讀。部分 PSU 還會(huì)帶上postinstall腳本例如數(shù)據(jù)庫(kù)層的catbundle.sql。這里提示一下不要只看文件名就說(shuō)打好了。PSU 分兩層——軟件層binary patch和數(shù)據(jù)庫(kù)層SQL patch。軟件層由opatch apply完成但數(shù)據(jù)庫(kù)字典里的版本信息升級(jí)靠的是后續(xù)執(zhí)行catbundle.sql psu apply。這一步漏掉的話opatch lsinventory里能看到補(bǔ)丁但v$version和dba_registry_history不會(huì)更新等于打了一半。2. 動(dòng)手前三查opatch版本、沖突掃描和家目錄備份2.1 opatch版本翻車率最高的第一道關(guān)卡很多人在打 PSU 時(shí)遇到的第一個(gè)報(bào)錯(cuò)就是OPatch version must be 11.2.0.3.36 or above這個(gè)報(bào)錯(cuò)的原因很簡(jiǎn)單你當(dāng)前$ORACLE_HOME/OPatch/opatch的版本太老不認(rèn)識(shí)新補(bǔ)丁的元數(shù)據(jù)格式。查看當(dāng)前版本$ORACLE_HOME/OPatch/opatch version如果版本不夠先去 Oracle 官網(wǎng)下載對(duì)應(yīng) 11.2.0.4 的 opatch 升級(jí)包。opatch 工具本身的補(bǔ)丁號(hào)一般是p6880880下載時(shí)要注意選對(duì)平臺(tái)和版本系列。升級(jí)方式也很粗暴但安全cd /tmp unzip -o p6880880_112000_Linux-x86-64.zip -d $ORACLE_HOME這個(gè)命令會(huì)把新的opatch覆蓋到$ORACLE_HOME/OPatch。升級(jí)前建議先備份一下舊目錄cp -r $ORACLE_HOME/OPatch $ORACLE_HOME/OPatch.bak.$(date %Y%m%d)升級(jí)后再確認(rèn)$ORACLE_HOME/OPatch/opatch version對(duì)了補(bǔ)充一個(gè)經(jīng)驗(yàn)opatch 升級(jí)不影響運(yùn)行中的數(shù)據(jù)庫(kù)不需要停庫(kù)可以在維護(hù)窗口之前提前做。但千萬(wàn)別在打補(bǔ)丁的過(guò)程中去做這件事因?yàn)?opatch 運(yùn)行時(shí)目錄內(nèi)有臨時(shí)文件容易出幺蛾子。2.2 沖突檢查提前知道補(bǔ)丁能不能共存PSU 是累積的但如果你的環(huán)境里已經(jīng)裝了某些 one-off 補(bǔ)丁例如某個(gè)特定 bug 的修復(fù)包它可能和 PSU 修改同一個(gè)文件產(chǎn)生沖突。沖突的后果輕則安裝失敗重則打完后某個(gè)二進(jìn)制行為異常。檢查命令cd /u01/software/36575425 $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph .這個(gè)命令會(huì)掃描當(dāng)前$ORACLE_HOME里已安裝的補(bǔ)丁和待安裝 PSU 做對(duì)比輸出沖突列表。實(shí)際使用中我遇到過(guò)因?yàn)闅v史遺留 one-off 補(bǔ)丁導(dǎo)致沖突的情況當(dāng)時(shí)的選擇是先用opatch rollback -id one-off補(bǔ)丁號(hào)回滾舊補(bǔ)丁再打 PSU。打完后如果需要那個(gè) one-off 的修復(fù)再確認(rèn)它是否已包含在 PSU 里——由于 PSU 是累積的大概率是包含的。另外還有一個(gè)隱藏的坑檢查輸出里可能提示你某些子補(bǔ)丁已經(jīng)被 superseded被替代這種情況下如果舊補(bǔ)丁已經(jīng)包含在 PSU 里opatch 可以正常覆蓋不用額外處理。2.3 空間、備份和維護(hù)窗口空間檢查不能只看df -h還要看$ORACLE_HOME所在文件系統(tǒng)的剩余量。PSU 安裝過(guò)程中opatch 會(huì)把被替換的舊文件放到$ORACLE_HOME/.patch_storage這部分空間和補(bǔ)丁包大小差不多我建議至少預(yù)留 10GB 以上空間df -h /u01/app/oracle備份策略方面我通常按兩套來(lái)做數(shù)據(jù)庫(kù)層打補(bǔ)丁前做一次全備RMAN 或冷備份均可視環(huán)境而定。雖然 PSU 大多是二進(jìn)制替換SQL 腳本也只是小幅變更但數(shù)據(jù)庫(kù)是所有業(yè)務(wù)的地基備份再謹(jǐn)慎都不為過(guò)。軟件層把整個(gè)$ORACLE_HOME復(fù)制一份建議用 tar 打包而不是簡(jiǎn)單 cp速度和完整性更好tar -czf /backup/oracle_home_bak_$(date %Y%m%d).tar.gz $ORACLE_HOME如果數(shù)據(jù)庫(kù)跑在虛擬機(jī)或云主機(jī)上強(qiáng)烈建議在打補(bǔ)丁前打一個(gè)磁盤快照?？煺盏幕貪L速度比任何 tar 解壓都快是應(yīng)急時(shí)最硬的底牌。維護(hù)窗口確認(rèn)也很重要打 PSU 需要停庫(kù)停監(jiān)聽業(yè)務(wù)影響窗口至少在半小時(shí)到一小時(shí)。除了確認(rèn)業(yè)務(wù)方批準(zhǔn)了時(shí)間還要先看一眼當(dāng)前數(shù)據(jù)庫(kù)的會(huì)話情況避免 shutdown immediate 時(shí)被大量活動(dòng)會(huì)話卡住select count(*), status from v$session group by status;3. 停庫(kù)、apply、跑腳本一次完整的PSU安裝流水賬3.1 解壓補(bǔ)丁包和環(huán)境確認(rèn)先把補(bǔ)丁包放到一個(gè)文件系統(tǒng)余量充足的目錄例如/u01/software然后用 oracle 用戶解壓cd /u01/software unzip -q p36575425_112040_Linux-x86-64.zip cd 36575425解壓后第一件事不是急著 apply而是cat README.txt重點(diǎn)看兩個(gè)部分一是Pre-Installation里對(duì) opatch 版本、空間、前置條件的要求二是Post-Installation里要求執(zhí)行的 SQL 腳本。官方文檔的要求偶爾會(huì)和網(wǎng)上教程有出入以 README 為準(zhǔn)。然后確認(rèn)環(huán)境變量已經(jīng)正確設(shè)置echo $ORACLE_HOME echo $ORACLE_SID這些變量如果沒(méi)設(shè)好opatch 會(huì)直接報(bào)ORACLE_HOME is not set。如果是通過(guò) su 切換到 oracle 用戶環(huán)境變量經(jīng)常丟失建議用su - oracle而不是su oracle。3.2 停庫(kù)、停監(jiān)聽讓數(shù)據(jù)庫(kù)干干凈凈地打補(bǔ)丁PSU 需要替換 oracle 可執(zhí)行文件和一堆共享庫(kù)這時(shí)候數(shù)據(jù)庫(kù)進(jìn)程是絕對(duì)不能運(yùn)行的否則文件被占用或者代碼版本不一致都會(huì)出問(wèn)題。操作順序lsnrctl stop然后登錄數(shù)據(jù)庫(kù)執(zhí)行 shutdownsqlplus / as sysdba SQL shutdown immediate;這里有個(gè)細(xì)節(jié)如果數(shù)據(jù)庫(kù)啟用了 ASM并且$ORACLE_HOME同時(shí)包含了 Grid 和 Database 兩套軟件那打補(bǔ)丁的復(fù)雜度和順序會(huì)略有不同。本文主要說(shuō)數(shù)據(jù)庫(kù)層的 PSU單機(jī)非 ASM 環(huán)境最簡(jiǎn)單。RAC 環(huán)境則需要用opatch auto做滾動(dòng)打補(bǔ)丁逐節(jié)點(diǎn)操作不在本文展開。停庫(kù)后檢查進(jìn)程確認(rèn)已經(jīng)完全退出ps -ef|grep ora_|grep -v grep正常情況下應(yīng)該沒(méi)輸出。如果有ora_pmon之類的后臺(tái)進(jìn)程殘留不能用kill -9硬殺先看看是不是 pmon 還掛在某些無(wú)法清理的資源上或者等下再檢查一次。順帶說(shuō)一句這個(gè)窗口期其實(shí)是做冷備份的好時(shí)機(jī)。如果你之前只做了熱備現(xiàn)在可以趁庫(kù)停著把數(shù)據(jù)文件也 physical copy 一份雙保險(xiǎn)。這種停都停了順手多備一份的操作在故障發(fā)生時(shí)會(huì)讓你特別感激自己。3.3 執(zhí)行opatch apply日志里看門道進(jìn)入補(bǔ)丁目錄后執(zhí)行cd /u01/software/36575425 $ORACLE_HOME/OPatch/opatch apply如果擔(dān)心終端斷連導(dǎo)致任務(wù)中斷可以用 nohup 或者干脆放到 tmux/screen 里跑nohup $ORACLE_HOME/OPatch/opatch apply /tmp/opatch_apply.log 21 這是我在生產(chǎn)環(huán)境養(yǎng)成的習(xí)慣——打補(bǔ)丁一旦中斷恢復(fù)起來(lái)要花更多時(shí)間去排查。用 nohup 可以避免 SSH 抖動(dòng)導(dǎo)致的悲劇。opatch 執(zhí)行時(shí)會(huì)做一系列前置檢查包括沖突檢查、空間檢查、權(quán)限檢查等然后開始替換文件。輸出里你會(huì)看到類似Updating archive name ... Copying 1 file to ...這個(gè)過(guò)程快則幾分鐘慢則十幾分鐘取決于機(jī)器性能和$ORACLE_HOME大小。最后成功時(shí)輸出有一段OPatch succeeded.看到這個(gè)基本就說(shuō)明軟件層打好了。但如果最后出現(xiàn)OPatch failed.怎么辦別急日志是首要排查依據(jù)最常見的是權(quán)限問(wèn)題或空間不足tail -n 100 /tmp/opatch_apply.log如果是權(quán)限問(wèn)題確認(rèn)用 oracle 用戶操作并檢查文件屬主ls -ld /u01/app/oracle/product/11.2.0/dbhome_13.4 跑SQL腳本把補(bǔ)丁注冊(cè)進(jìn)數(shù)據(jù)庫(kù)字典軟件層完成后回到數(shù)據(jù)庫(kù)層面。首先啟動(dòng)數(shù)據(jù)庫(kù)到 upgrade 模式如果 README 要求或直接 open不同版本要求不一樣11.2.0.4 的 PSU 通常在 open 狀態(tài)就能執(zhí)行 postinstall 腳本sqlplus / as sysdba SQL startup;然后執(zhí)行SQL $ORACLE_HOME/rdbms/admin/catbundle.sql psu apply這一步會(huì)更新數(shù)據(jù)庫(kù)字典的版本信息并把 PSU 相關(guān)組件注冊(cè)到dba_registry_history。執(zhí)行過(guò)程中會(huì)有大量輸出耗時(shí)可能比較長(zhǎng)不要中途 CTLC。執(zhí)行完成后還要跑一次utlrp.sql來(lái)重新編譯那些因?yàn)樽值渥兏У膶?duì)象SQL $ORACLE_HOME/rdbms/admin/utlrp.sqlutlrp.sql會(huì)輸出類似 Recompilation of invalid objects finished 的提示就算完成。再驗(yàn)證一下失效對(duì)象數(shù)量select count(*) from dba_objects where statusINVALID;在 11.2.0.4 里打完 PSU 后出現(xiàn)少量諸如DBMS_SCHEDULER相關(guān)對(duì)象失效是正常的utlrp.sql跑完會(huì)降到 0。如果仍然有大量失效對(duì)象就要認(rèn)真看了后面講排查思路。4. 常見報(bào)錯(cuò)與驗(yàn)證補(bǔ)丁裝完不等于萬(wàn)事大吉4.1 用兩條 SQL 驗(yàn)證補(bǔ)丁真的生效很多人在opatch apply報(bào)成功后就直接宣布打完補(bǔ)丁了其實(shí)不夠嚴(yán)謹(jǐn)。我習(xí)慣做三件事第一確認(rèn)補(bǔ)丁在 inventory 里$ORACLE_HOME/OPatch/opatch lsinventory | grep -i 36575425能匹配到補(bǔ)丁號(hào)就說(shuō)明軟件層注冊(cè)成功。第二查數(shù)據(jù)庫(kù)字典的補(bǔ)丁歷史select * from dba_registry_history;如果能看到PSU 11.2.0.4.240717這樣的記錄說(shuō)明 SQL 層也生效了。第三確認(rèn)數(shù)據(jù)庫(kù)組件版本select comp_id, comp_name, version, status from dba_registry;正常情況所有組件狀態(tài)都應(yīng)該是VALID版本號(hào)有所更新。這一步可以順帶發(fā)現(xiàn)一些歷史遺留的組件狀態(tài)問(wèn)題。4.2 失效對(duì)象和組件異常的排查思路打完補(bǔ)丁后最常見的異常就是失效對(duì)象。跑完utlrp.sql仍然有失效對(duì)象時(shí)我的做法是select owner, object_type, object_name from dba_objects where statusINVALID;然后針對(duì)具體對(duì)象去看它的last_ddl_time或者其他告警日志里的信息。多數(shù)情況是某個(gè)系統(tǒng)包依賴了被替換的庫(kù)文件重新編譯一下就好。如果某個(gè)對(duì)象反復(fù)編譯失敗就去查$ORACLE_HOME/rdbms/log或 alert log里面通常有原因。不要自己亂手動(dòng) drop 重建尤其是SYS和SYSTEM下的對(duì)象很容易引起更嚴(yán)重的問(wèn)題。另外打補(bǔ)丁后有時(shí)會(huì)出現(xiàn)ORA-04063或ORA-06508這類 PL/SQL 運(yùn)行時(shí)錯(cuò)誤通常也是因?yàn)樽值鋵?duì)象和二進(jìn)制版本不一致跑完utlrp.sql再重啟一次實(shí)例基本能解決。4.3 我實(shí)際遇到過(guò)幾個(gè)坑說(shuō)幾個(gè)我自己踩過(guò)或者身邊同事踩過(guò)的坑給大家提個(gè)醒?？右煌讼壬?jí) opatch。有個(gè)環(huán)境上一次打補(bǔ)丁還是兩年前opatch 版本停留在 11.2.0.3.5直接 apply 時(shí)報(bào)版本錯(cuò)誤。當(dāng)時(shí)維護(hù)窗口已經(jīng)批了臨時(shí)找下載鏈接又花了半小時(shí)最后一整晚節(jié)奏全亂?，F(xiàn)在我的習(xí)慣是每個(gè)季度 PSU 發(fā)布后先把 opatch 升到最新并確認(rèn)能通過(guò)opatch version和opatch lsinventory讓環(huán)境隨時(shí)處于可以打補(bǔ)丁的狀態(tài)?？佣verwrite 了不應(yīng)該動(dòng)的 ORACLE_HOME。打補(bǔ)丁前我想當(dāng)然用了cp -rf把舊的$ORACLE_HOME備份到別的地方但目標(biāo)路徑下有歷史殘留文件cp -rf把老的 jar 包和二進(jìn)制混合到了一起。雖然那次沒(méi)出事但之后我改用tar -czf打包備份徹底避免目錄合并的問(wèn)題?？尤龍?zhí)行 catbundle.sql 時(shí)終端斷了。一次遠(yuǎn)程操作catbundle.sql 執(zhí)行到一半 SSH 斷了結(jié)果數(shù)據(jù)庫(kù)里補(bǔ)丁注冊(cè)狀態(tài)半完成。后來(lái)排查了很久。解決辦法很簡(jiǎn)單sqlplus 里多用spool記錄日志關(guān)鍵腳本盡量在 tmux 里跑或者干脆用nohup方式nohup sqlplus / as sysdba EOF /tmp/catbundle_run.log 21 $ORACLE_HOME/rdbms/admin/catbundle.sql psu apply $ORACLE_HOME/rdbms/admin/utlrp.sql EOF這樣即使斷連腳本也會(huì)繼續(xù)執(zhí)行你只需要事后檢查日志。再補(bǔ)充一個(gè) 11.2.0.4 環(huán)境的注意事項(xiàng)如果數(shù)據(jù)庫(kù)里使用了不少高級(jí)組件例如 Partitioning、Spatial 等建議在打補(bǔ)丁前先把這些組件的狀態(tài)確認(rèn)好。如果某個(gè)組件本身就處于INVALID或UPGRADE狀態(tài)PSU 的 postinstall 腳本可能執(zhí)行不順利。5. 萬(wàn)一失手怎么辦回滾流程與應(yīng)急底牌5.1 opatch rollback 的完整操作雖然 PSU 安裝成功率很高但萬(wàn)一出現(xiàn)數(shù)據(jù)庫(kù)起不來(lái)、執(zhí)行 apply 失敗導(dǎo)致二進(jìn)制不一致等狀況需要回滾。回滾邏輯和安裝類似先軟件后數(shù)據(jù)庫(kù)。首先停庫(kù)、停監(jiān)聽然后執(zhí)行cd $ORACLE_HOME $ORACLE_HOME/OPatch/opatch rollback -id 36575425opatch 會(huì)從.patch_storage里把原始文件找回來(lái)恢復(fù)?；貪L成功后同樣要檢查$ORACLE_HOME/OPatch/opatch lsinventory | grep -i 36575425確認(rèn)補(bǔ)丁不在列表里了。接著啟動(dòng)數(shù)據(jù)庫(kù)執(zhí)行回滾的 SQL 腳本。在 11.2.0.4 里如果你已經(jīng)跑過(guò)catbundle.sql psu apply回滾時(shí)也要執(zhí)行相應(yīng)的降級(jí)腳本。操作方式是找到$ORACLE_HOME/rdbms/admin下的catbundle.sql使用rollback模式SQL $ORACLE_HOME/rdbms/admin/catbundle.sql psu rollback SQL $ORACLE_HOME/rdbms/admin/utlrp.sql最后再次檢查dba_registry_history確保 PSU 記錄被移除數(shù)據(jù)庫(kù)版本恢復(fù)到打補(bǔ)丁前的狀態(tài)。5.2 什么場(chǎng)景別硬扛直接用快照回滾雖然可行但也不是萬(wàn)能的——如果打補(bǔ)丁過(guò)程中文件系統(tǒng)損壞、或者某些操作導(dǎo)致$ORACLE_HOME狀態(tài)非?；靵yopatch rollback可能因?yàn)?patch_storage不完整而失敗。這時(shí)候最干凈的方案是磁盤快照回滾。我在前面就強(qiáng)調(diào)過(guò)能打快照就打快照。真到了需要應(yīng)急的時(shí)候快照秒級(jí)回滾帶來(lái)的好處遠(yuǎn)比花十幾分鐘打包備份更實(shí)在。如果不幸連快照都沒(méi)有那就只能靠之前的 tar 包了rm -rf $ORACLE_HOME/* tar -xzf /backup/oracle_home_bak.tar.gz -C /這種方式恢復(fù)速度取決于文件大小通常能以分鐘級(jí)完成但務(wù)必在恢復(fù)后仔細(xì)核對(duì)權(quán)限和軟鏈接。關(guān)于回滾還有一個(gè)很實(shí)際的建議一旦決定要回滾就不要再反復(fù)嘗試 apply 同一份補(bǔ)丁。有些時(shí)候第一次失敗是因?yàn)榄h(huán)境臨時(shí)問(wèn)題改一下權(quán)限或空間就能解決但如果第一次失敗的原因沒(méi)找到盲目重試第二次第三次很可能把$ORACLE_HOME搞得更亂。先定位原因再?zèng)Q定繼續(xù)還是回滾。最后說(shuō)一個(gè)我自己的習(xí)慣每次打完 PSU我都習(xí)慣把操作時(shí)間、補(bǔ)丁號(hào)、遇到的問(wèn)題、最終驗(yàn)證結(jié)果記到一份簡(jiǎn)單的運(yùn)維文檔里。下個(gè)季度再打補(bǔ)丁時(shí)翻一下上次的記錄能避開不少自己當(dāng)年踩過(guò)的坑。這次 p36575425 的安裝過(guò)程大概就是這些如果你也在維護(hù) 11.2.0.4 的老環(huán)境照著這個(gè)流程走應(yīng)該能少走點(diǎn)彎路。本文還有配套的精品資源點(diǎn)擊獲取