簡(jiǎn)介面向 Linux x86-64 平臺(tái)的 Oracle Database 11.2.0.4 官方 PSU 補(bǔ)丁包 p36575425是 2024 年 7 月發(fā)布的季度更新適用于需要保持?jǐn)?shù)據(jù)庫安全與穩(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 共享庫為核心文件支撐補(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ù)庫上執(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ù)庫這在 2024 年聽起來確實(shí)挺魔幻但做了多年 DBA 的人都知道老版本 Oracle 的存量用戶比想象中多得多。最近剛好在處理一套 Linux x86-64 環(huán)境上的 11.2.0.4 數(shù)據(jù)庫需要上最新一季的 PSUPatch Set Update補(bǔ)丁補(bǔ)丁號(hào) p36575425對(duì)應(yīng)的版本串是 11.2.0.4.240717。整套流程走下來從下載補(bǔ)丁到驗(yàn)證完成差不多花了一個(gè)維護(hù)窗口中間還踩了幾個(gè)不算深但足夠煩的坑所以把完整過程整理成這篇文章。這篇文章寫給誰兩類人最需要一類是還在維護(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)證過的直接抄作業(yè)即可。1. 11.2.0.4熬到2024這個(gè)PSU補(bǔ)丁為何非打不可1.1 一個(gè)老版本的真實(shí)處境先說明一個(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)用兼容性沒法升級(jí)到 12c/19c 的系統(tǒng)來說打 PSU 幾乎是唯一能緩解安全隱患的手段。所以別覺得給 11.2.0.4 打補(bǔ)丁是無用功恰恰相反在一堆 CVE 通告面前季度 PSU 是你最實(shí)在的防線。等保測(cè)評(píng)里對(duì)數(shù)據(jù)庫安全補(bǔ)丁及時(shí)更新的要求也是靠這套機(jī)制來滿足的。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)來不需要先打之前的舊 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í)行文件、庫文件、SQL 腳本等。README.txt補(bǔ)丁的完整說明文檔必讀。部分 PSU 還會(huì)帶上postinstall腳本例如數(shù)據(jù)庫層的catbundle.sql。這里提示一下不要只看文件名就說打好了。PSU 分兩層——軟件層binary patch和數(shù)據(jù)庫層SQL patch。軟件層由opatch apply完成但數(shù)據(jù)庫字典里的版本信息升級(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ù)庫不需要停庫可以在維護(hù)窗口之前提前做。但千萬別在打補(bǔ)丁的過程中去做這件事因?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í)際使用中我遇到過因?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 安裝過程中opatch 會(huì)把被替換的舊文件放到$ORACLE_HOME/.patch_storage這部分空間和補(bǔ)丁包大小差不多我建議至少預(yù)留 10GB 以上空間df -h /u01/app/oracle備份策略方面我通常按兩套來做數(shù)據(jù)庫層打補(bǔ)丁前做一次全備RMAN 或冷備份均可視環(huán)境而定。雖然 PSU 大多是二進(jìn)制替換SQL 腳本也只是小幅變更但數(shù)據(jù)庫是所有業(yè)務(wù)的地基備份再謹(jǐn)慎都不為過。軟件層把整個(gè)$ORACLE_HOME復(fù)制一份建議用 tar 打包而不是簡(jiǎn)單 cp速度和完整性更好tar -czf /backup/oracle_home_bak_$(date %Y%m%d).tar.gz $ORACLE_HOME如果數(shù)據(jù)庫跑在虛擬機(jī)或云主機(jī)上強(qiáng)烈建議在打補(bǔ)丁前打一個(gè)磁盤快照。快照的回滾速度比任何 tar 解壓都快是應(yīng)急時(shí)最硬的底牌。維護(hù)窗口確認(rèn)也很重要打 PSU 需要停庫停監(jiān)聽業(yè)務(wù)影響窗口至少在半小時(shí)到一小時(shí)。除了確認(rèn)業(yè)務(wù)方批準(zhǔn)了時(shí)間還要先看一眼當(dāng)前數(shù)據(jù)庫的會(huì)話情況避免 shutdown immediate 時(shí)被大量活動(dòng)會(huì)話卡住select count(*), status from v$session group by status;3. 停庫、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這些變量如果沒設(shè)好opatch 會(huì)直接報(bào)ORACLE_HOME is not set。如果是通過 su 切換到 oracle 用戶環(huán)境變量經(jīng)常丟失建議用su - oracle而不是su oracle。3.2 停庫、停監(jiān)聽讓數(shù)據(jù)庫干干凈凈地打補(bǔ)丁PSU 需要替換 oracle 可執(zhí)行文件和一堆共享庫這時(shí)候數(shù)據(jù)庫進(jìn)程是絕對(duì)不能運(yùn)行的否則文件被占用或者代碼版本不一致都會(huì)出問題。操作順序lsnrctl stop然后登錄數(shù)據(jù)庫執(zhí)行 shutdownsqlplus / as sysdba SQL shutdown immediate;這里有個(gè)細(xì)節(jié)如果數(shù)據(jù)庫啟用了 ASM并且$ORACLE_HOME同時(shí)包含了 Grid 和 Database 兩套軟件那打補(bǔ)丁的復(fù)雜度和順序會(huì)略有不同。本文主要說數(shù)據(jù)庫層的 PSU單機(jī)非 ASM 環(huán)境最簡(jiǎn)單。RAC 環(huán)境則需要用opatch auto做滾動(dòng)打補(bǔ)丁逐節(jié)點(diǎn)操作不在本文展開。停庫后檢查進(jìn)程確認(rèn)已經(jīng)完全退出ps -ef|grep ora_|grep -v grep正常情況下應(yīng)該沒輸出。如果有ora_pmon之類的后臺(tái)進(jìn)程殘留不能用kill -9硬殺先看看是不是 pmon 還掛在某些無法清理的資源上或者等下再檢查一次。順帶說一句這個(gè)窗口期其實(shí)是做冷備份的好時(shí)機(jī)。如果你之前只做了熱備現(xiàn)在可以趁庫停著把數(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ù)起來要花更多時(shí)間去排查。用 nohup 可以避免 SSH 抖動(dòng)導(dǎo)致的悲劇。opatch 執(zhí)行時(shí)會(huì)做一系列前置檢查包括沖突檢查、空間檢查、權(quán)限檢查等然后開始替換文件。輸出里你會(huì)看到類似Updating archive name ... Copying 1 file to ...這個(gè)過程快則幾分鐘慢則十幾分鐘取決于機(jī)器性能和$ORACLE_HOME大小。最后成功時(shí)輸出有一段OPatch succeeded.看到這個(gè)基本就說明軟件層打好了。但如果最后出現(xiàn)OPatch failed.怎么辦別急日志是首要排查依據(jù)最常見的是權(quán)限問題或空間不足tail -n 100 /tmp/opatch_apply.log如果是權(quán)限問題確認(rèn)用 oracle 用戶操作并檢查文件屬主ls -ld /u01/app/oracle/product/11.2.0/dbhome_13.4 跑SQL腳本把補(bǔ)丁注冊(cè)進(jìn)數(shù)據(jù)庫字典軟件層完成后回到數(shù)據(jù)庫層面。首先啟動(dòng)數(shù)據(jù)庫到 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ù)庫字典的版本信息并把 PSU 相關(guān)組件注冊(cè)到dba_registry_history。執(zhí)行過程中會(huì)有大量輸出耗時(shí)可能比較長(zhǎng)不要中途 CTLC。執(zhí)行完成后還要跑一次utlrp.sql來重新編譯那些因?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ǔ)丁裝完不等于萬事大吉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)就說明軟件層注冊(cè)成功。第二查數(shù)據(jù)庫字典的補(bǔ)丁歷史select * from dba_registry_history;如果能看到PSU 11.2.0.4.240717這樣的記錄說明 SQL 層也生效了。第三確認(rèn)數(shù)據(jù)庫組件版本select comp_id, comp_name, version, status from dba_registry;正常情況所有組件狀態(tài)都應(yīng)該是VALID版本號(hào)有所更新。這一步可以順帶發(fā)現(xiàn)一些歷史遺留的組件狀態(tài)問題。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)包依賴了被替換的庫文件重新編譯一下就好。如果某個(gè)對(duì)象反復(fù)編譯失敗就去查$ORACLE_HOME/rdbms/log或 alert log里面通常有原因。不要自己亂手動(dòng) drop 重建尤其是SYS和SYSTEM下的對(duì)象很容易引起更嚴(yá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í)際遇到過幾個(gè)坑說幾個(gè)我自己踩過或者身邊同事踩過的坑給大家提個(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)能通過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)制混合到了一起。雖然那次沒出事但之后我改用tar -czf打包備份徹底避免目錄合并的問題。坑三執(zhí)行 catbundle.sql 時(shí)終端斷了。一次遠(yuǎn)程操作catbundle.sql 執(zhí)行到一半 SSH 斷了結(jié)果數(shù)據(jù)庫里補(bǔ)丁注冊(cè)狀態(tà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ù)庫里使用了不少高級(jí)組件例如 Partitioning、Spatial 等建議在打補(bǔ)丁前先把這些組件的狀態(tài)確認(rèn)好。如果某個(gè)組件本身就處于INVALID或UPGRADE狀態(tài)PSU 的 postinstall 腳本可能執(zhí)行不順利。5. 萬一失手怎么辦回滾流程與應(yīng)急底牌5.1 opatch rollback 的完整操作雖然 PSU 安裝成功率很高但萬一出現(xiàn)數(shù)據(jù)庫起不來、執(zhí)行 apply 失敗導(dǎo)致二進(jìn)制不一致等狀況需要回滾?；貪L邏輯和安裝類似先軟件后數(shù)據(jù)庫。首先停庫、停監(jiān)聽然后執(zhí)行cd $ORACLE_HOME $ORACLE_HOME/OPatch/opatch rollback -id 36575425opatch 會(huì)從.patch_storage里把原始文件找回來恢復(fù)?；貪L成功后同樣要檢查$ORACLE_HOME/OPatch/opatch lsinventory | grep -i 36575425確認(rèn)補(bǔ)丁不在列表里了。接著啟動(dòng)數(shù)據(jù)庫執(zhí)行回滾的 SQL 腳本。在 11.2.0.4 里如果你已經(jīng)跑過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ù)庫版本恢復(fù)到打補(bǔ)丁前的狀態(tài)。5.2 什么場(chǎng)景別硬扛直接用快照回滾雖然可行但也不是萬能的——如果打補(bǔ)丁過程中文件系統(tǒng)損壞、或者某些操作導(dǎo)致$ORACLE_HOME狀態(tài)非?；靵yopatch rollback可能因?yàn)?patch_storage不完整而失敗。這時(shí)候最干凈的方案是磁盤快照回滾。我在前面就強(qiáng)調(diào)過能打快照就打快照。真到了需要應(yīng)急的時(shí)候快照秒級(jí)回滾帶來的好處遠(yuǎn)比花十幾分鐘打包備份更實(shí)在。如果不幸連快照都沒有那就只能靠之前的 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í)問題改一下權(quán)限或空間就能解決但如果第一次失敗的原因沒找到盲目重試第二次第三次很可能把$ORACLE_HOME搞得更亂。先定位原因再?zèng)Q定繼續(xù)還是回滾。最后說一個(gè)我自己的習(xí)慣每次打完 PSU我都習(xí)慣把操作時(shí)間、補(bǔ)丁號(hào)、遇到的問題、最終驗(yàn)證結(jié)果記到一份簡(jiǎn)單的運(yùn)維文檔里。下個(gè)季度再打補(bǔ)丁時(shí)翻一下上次的記錄能避開不少自己當(dāng)年踩過的坑。這次 p36575425 的安裝過程大概就是這些如果你也在維護(hù) 11.2.0.4 的老環(huán)境照著這個(gè)流程走應(yīng)該能少走點(diǎn)彎路。本文還有配套的精品資源點(diǎn)擊獲取