Oracle資料庫打補丁方法

給軟體打補丁相當於給人打預防針，對系統的穩定執行至關重要。本文詳細、系統地介紹了Oracle資料庫補丁的分類、安裝、管理等問題。

    廠商提供給使用者的軟體補丁的形式多為編譯後的庫函式，所以安裝軟體補丁實際上就是把這些庫函式複製到相應目錄，並在需要時進行聯接操作。軟體公司一般在一段時間後會把針對某一版本的所有補丁進行整理：合併融合，解決衝突，進行整體測試，並使檔案複製和聯接操作自動執行，得到一個軟體補丁“包 ”。不同的公司使用不同的名稱，現在一般計算機使用者都熟悉的Windows Service Pack就是這樣的補丁包。Oracle公司給出的補丁包的名稱是Patch Set，安裝Patch Set後的版本稱Patch Set Release（PSR）。

    Oracle公司對處於標準技術支援的產品不定期地提供PSR，例如在完成本文時，版本10.2的最新PSR是10.2.0.2；版本10.1的最新PSR是10.1.0.5；版本9.2的最新（也極可能是最終）PSR是9.2.0.8.

    在安裝最新PSR後新發現的Bug，其相應補丁當然會收錄到下一個PSR中。PSR是累積型的，即下一個PSR中會包括當前PSR中所有補丁和新發現Bug的補丁。同時存在幾個PSR時，只需安裝最新版本一次就可以了。但是由於PSR的發行有一定間隔，如果這些Bug對使用者有比較大的影響，那麼Oracle公司也會向使用者公開和提供這些補丁，這些補丁被稱為個別補丁（Interim Patch，one-off patch 或 Patch Set Exception）。而對於最終補丁發行版而言，由於不再有下一個PSR，所以當發現影響系統的新Bug時，個別補丁成為惟一選擇。

    此外，Oracle公司還定期釋出安全補丁，稱之為CPU（Critical Patch Updates）。安全補丁用來修復軟體的易受攻擊性（vulnerability）或通常說的安全漏洞。這類問題本來不屬於軟體錯誤，在正常使用中不會出現任何問題。但是別有用心的人可以透過執行非常精巧設計的程式碼，繞過資料庫系統的安全管理機制，達到非授權存取的目的。

    另外還存在一類補丁：診斷用補丁（diagnostic patch）。顧名思義，這類補丁不是用來解決問題的，而是用來尋找問題的原因的。這類補丁只在Oracle技術支援部門要求安裝時，才需要安裝。在得到需要的診斷資訊後，應立即解除安裝這一補丁。

    利弊及時機選擇

    負責管理支撐大型應用系統的資料庫的DBA會容易理解安裝軟體補丁的代價。安裝PSR需要停止資料庫服務，關閉資料庫，對於許多應用系統安排這樣的停機時間本身就是一件比較困難的事情。事實上，更為嚴重的是由於安裝PSR可能“引入”新的Bug，反而影響應用系統的正常執行。軟體補丁本來是修正Bug，怎麼會帶來新的Bug？雖然有些讓人匪夷所思，但很不幸這是現實存在的。

    對於每一個PSR，其中都包括了少則幾百多則上千個嚴重Bug的修正。即便是如此，在PSR釋出後，很快就又會在安裝PSR後的資料庫中發現一些新問題。其中一部分Bug是以前就一直存在的只是以前沒有發現，而現在偶爾被發現，或者是由於PSR修正了某一錯誤從而將其“啟用”或容易發現。但是確實有一些Bug是由這一PSR造成的，Oracle技術支援部門稱其為倒退（Regression）。對於每一PSR，在metalink中有兩個重要的與之有關的文件，一個是“List of fixes added in XXXX”，是這一PSR修復的Bug的清單，是一本“功德簿”；另一個是“Known issues and alerts affecting XXXX”，是安裝PSR後發現的問題，可以稱其為“悔過簿”。由於大型軟體的複雜性，Bug幾乎是不可避免的。重要的是能夠及時提供資訊，DBA可以結合自己系統的情況做出正確的判斷。讀者不必因為知道還存在著Bug，就對Oracle資料庫產品失去信心。PSR修復的上千個Bug中絕大多數是在一些很少見的環境中，或者是若干個元件的複雜組合使用的情形中發生的。

    如果系統在執行中出現過某種問題，由Oracle技術支援部門或第三方的專家確認原因是PSR中的某一Bug，這樣就必須儘早安裝；如果系統一直執行正常，並且在PSR已發現的問題中涉及的元件或功能（如Logical Standby， JVM，RAC等）在系統中並不使用，此時可以選擇安裝也可以選擇不安裝。

    另一個需要考慮的因素是安裝補丁的時機。上述這些考慮的一個重要前提是系統已經投入執行，擔心“倒退”的Bug影響系統。如果系統還處在開發和測試階段，不需要有任何猶豫，安裝最新的PSR，並在此基礎上測試應用系統是否工作正常。如果發現異常，要及時請Oracle技術支援部門確認是否新Bug，如果是請其提供個別補丁。目的就是在一個儘可能完善穩定的資料庫平臺上測試應用系統。我們可以把這種安裝補丁的策略概括為“補丁補新不補舊”。

    以上都是針對PSR的安裝，對於個別補丁，由於補丁修復的Bug單一，容易判斷是否需要安裝。需要注意的是，如果在當前PSR之上安裝了若干個個別補丁，那麼在下一個PSR釋出後，在安裝下一個PSR之前，需要解除安裝所有個別補丁。為便於管理，現在Oracle技術支援部門要求必須使用工具opatch安裝管理個別工具，而儘量避免手動複製檔案等操作。

最後是安全補丁安裝的判斷。雖然安全漏洞這個詞看上去讓人覺得非常嚴重，但是還要冷靜綜合分析這些漏洞在系統中的危害程度。事實上，不安裝安全補丁的危險性可能遠遠小於始終不渝地使用scott/tiger這樣人人都知道的使用者名稱和口令的“標準預設”做法。

    安裝PSR

    使用oui工具安裝PSR時只需要用滑鼠做幾個選擇就可以進入自動執行的階段，操作過程本身非常簡單。但是如果要求必須一次安裝成功；要求必須在凌晨2點到4點這個有限的停機時間段完成操作；要求安裝過程不出差錯，以後出現問題時能夠完全排除此次操作失誤的可能性，那麼就需要在啟動oui之前做一些準備工作。

    1. 收集資訊

    有關PSR的資訊中，一個最重要的文件就是軟體補丁說明，這個檔案相當於技術手冊中的安裝指南和發行說明。檔案本身包含在下載的軟體補丁檔案之中，檔名是patchnote.htm或README.Html.需要注意的一個問題是在軟體補丁檔案之中找到的這一Patch Set Notes可能不是最新版，可以根據檔案內的提示資訊在metalink中檢索最新版。

    另外兩個重要檔案就是前面已經提及的“功德簿”和“悔過簿”，相對於“功德簿”更應該仔細閱讀“悔過簿”中的每一項內容。另外，在Patch Set Notes的已知問題（Known Issues）一節內列出了安裝PSR後出現的一些問題。

    除去這三個主要檔案外，還應在metalink中檢索，尋找是否還有其他涉及這一PSR的技術文章，尋找其他使用者在安裝這一PSR時或安裝後遇到問題時所發的救助的帖子，前車之鑑更應重視。

    2. 做出判斷

    在認真閱讀收集到的文章之後，根據自己系統的實際情況，做出是立即安裝PSR，或是等待下一PSR的決定。如果是暫緩安裝，則要記錄原因，以便以後跟蹤Bug的修復程式。

    3. 制訂實施計劃

    在決定安裝PSR後，需要制訂一個實施計劃。在計劃中不僅要包括正常的操作步驟，更要考慮在出現意外時的應急處理（如果安裝PSR失敗，則在正常應用開始時間之前，要恢復系統到安裝之前的狀態）。如果可能，在對正式系統開始實施之前，應在測試系統中進行演練和應用處理的測試，保證在安裝PSR後不會影響應用系統的執行。

    安裝PSR的計劃大致有以下幾個部分：停止資料庫服務關閉資料庫；備份DBMS軟體和資料庫以備恢復之用；安裝PSR軟體；更新資料庫資料字典升級PSR版本；正常啟動資料庫開始資料庫服務。

    看似簡單的關閉資料庫的操作，在系統構成複雜時也會變得不容易。另外，如果夜間作業時間不允許在完成資料庫完全備份之後再安裝PSR，則安裝PSR的日期應該選擇在例行的資料庫完全備份的下一個晚上，只備份重做日誌。

    在安裝PSR之前備份DBMS軟體的目的是，由於安裝PSR會對許多程式和庫函式進行更新，如果安裝PSR中途失敗（雖然可能性非常小），有可能造成DBMS軟體出現不一致。另外一種可能的情形是，在安裝PSR，更新資料字典後，測試應用系統時，出現了某種異常，原因不明，最終決定放棄PSR.如果操作之前沒有備份，則此時只有重新安裝軟體一種選擇（PSR不同於完整軟體安裝，在oui中無法單獨解除安裝PSR軟體）。

    對檔案、目錄和檔案系統的備份，最簡單的方式可以使用cp、tar、dump等命令完成。如果希望縮短檔案複製時間，可以考慮分割槽備份的方法。分割槽備份常用的命令是dd.但是，分割槽複製比檔案複製速度快的前提是良好的分割槽設計：Oracle軟體單獨佔一個大小適中（如4GB）的分割槽，這樣扇區複製才會體現優勢，這也就是為什麼在安裝軟體時，Oracle建議單獨使用一個分割槽安裝軟體的原因之一。

    在制定實施計劃時，應認真閱讀Patch Set Notes中有關操作前準備工作一節。在這節內會介紹對於一些特殊系統構成，如果你的系統屬於文件中提到的構成，一定要首先閱讀文內提示的相關技術文章，找到正確的安裝步驟。

    使用oui， PSR軟體安裝完成後，一定不要忘記更新資料字典這一步驟。如果在這一ORACLE_HOME下生成了多個資料庫，則每個資料庫都必須更新資料字典。

    4. 實施操作

    制訂一個詳細的計劃後，實施操作就可以“照本宣科”，是一個簡單的體力勞動。要認識到“忙中出錯”的機率遠比“急中生智”大得多，操作時儘量減少失誤的可能性。例如，需要執行的複雜命令，儘可能從一個檔案複製到終端執行，而不要現場輸入。另外，在實施過程中， 要記錄各個階段實際的執行時間，以供以後制訂類似計劃時參考。

    5. 檢查操作結果並記錄備案

執行一個操作，操作是否成功，一定要進行檢查，不能簡單認為沒有出錯資訊就是成功。要知道驗證的方法。除去極個別極費時間的驗證（分割槽備份的內容是否可以成功恢復系統，必須恢復分割槽，啟動資料庫，測試應用系統後才能確認），其餘操作都應進行驗證。所有螢幕輸出資訊和日誌檔案都應保留，作為安裝報告的附件提交給上級或客戶。

    在螢幕輸出或日誌檔案中出現異常/錯誤資訊時，應即時分析，決定馬上採取的措施。出現嚴重錯誤時，可能需要重新執行某一SQL程式，或者重新安裝PSR.所以在制訂實施計劃時應在時間上留出異常情況處理的時間。

    下面給出一個在Linux平臺上安裝10.1的PSR的例項，給從未安裝PSR的讀者有一個感性認識。

    作業系統是RHEL AS4.0 Update3，Oracle的當前版本是10.1.2.在metalink中檢索，找到10.1版的最新PSR10.1.0.5.下載壓縮檔案。在壓縮檔案中找到Patch Set Notes，該文件的完成日期是2006年1月。而按照文件內的提示在metalink中檢索得到的此文件的最新版本完成日期是2006年4月。使用檔案比較工具進行比較，兩個版本沒有實質性差別，只有語句措詞的修改，但是養成總是檢索最新文件的習慣有益無害。

    根據Patch Set Notes中的說明，有一些特殊系統構成需要額外的步驟，本例中由於全部沒有涉及到，所以可以按標準步驟執行。

    另外，檢查“Known issues and alerts affecting 10.1.0.5”文件後，發現10.1.0.5引入的影響最大的一個Bug是執行SELECT MAX（）在某些特定條件下結果不正確。而這一Bug可以透過設定事件（event）關閉FIRST ROW最佳化而避免。最後的結論是這一BUG不會對本系統有影響，可以安裝PSR10.1.0.5.

    1. 檢查資料庫表空間和初始化引數是否需要調整。

    System表空間要求有一定未使用空間：初始化引數SHARED_POOL_SIZE 和 Java_POOL_SIZE不能低於最小值150MB.

    2. 關閉資料庫，停止listener和agent等程式。

    3. 解壓縮下載檔案至某一目錄，執行oui.

    在壓縮檔案中附帶的oui的版本要比已經安裝的版本高，應總是使用新版本的oui.在oui視窗中，要求選擇本次安裝的軟體的位置，正確的位置是解壓縮目錄下的子目錄Disk1/stage/， 選中prodUCts.XML即可開始檔案複製。

    要注意視窗中會出現本次安裝的日誌檔案的檔案路徑和檔名。檔案的位置是在Oracle的inventory所在目錄的子目錄logs中，檔名由字首InstallActions和安裝日期時間組成，如： InstallActions2006-08-30-11-32-48AM.log.

    正常結束後，退出oui.開啟日誌檔案，檢索是否出現error 或“ORA-”的錯誤資訊。本次安裝產生的日誌檔案內，沒有任何此類的資訊，表明PSR軟體安裝成功。如果此時再次啟動oui，點選“已安裝軟體”，則可以看到在原有的10.1.0.2軟體之下，新出現了10.1.0.5一項，這也證實PSR軟體安裝成功。

    4.更新資料庫資料字典

    更新資料字典時，必須以特殊的升級方式開啟資料庫。

    $ sqlplus /nolog

    SQL> CONNECT / AS SYSDBA

    SQL> STARTUP UPGRADE

    SQL> SPOOL patch.log

    SQL> @？/rdbms/admin/catpatch.sql

    執行結束後，關閉重定向：

    SQL> SPOOL OFF

    開啟檔案patch.log檢查是否有錯誤“ORA-”。（這一檔案在啟動sqlplus時的當前目錄中，當然也可以在“SPOOL patch.log”語句中顯式指定檔案路徑。）如果出現錯誤要分析原因，在解決問題後，需要再次執行catpatch.sql程式。

更新資料字典時，由於對某些PL/SQL包刪除後又重新生成，造成相關PL/SQL包的狀態為異常（invalid）。在以後呼叫這些包時，檢測到其狀態為非法，會自動執行編譯命令，使狀態成為正常（valid）。雖然不會出錯，但會造成個別處理第一次執行時變慢。顯然，與其留到應用系統執行時再一個個編譯，不如之前集中一次重編譯所有異常包。

    SQL> SHUTDOWN

    SQL> STARTUP

    SQL> @？/rdbms/admin/utlrp.sql

    最後，根據Known Issues中的指示，完成與本系統有關的操作。例如，修改Pro*C的配置檔案。這裡執行一個修改檔案存取許可權的“後操作”，以便非同組使用者和程式可以存取客戶端工具和庫函式。

    $ cd $ORACLE_HOME/install

    $ ./ changePerm.sh

    個別補丁管理工具opatch

    如前所述，在釋出一個PSR後發現的新BUG，只能把其補丁收入到下一個PSR中。如果對資料庫有實質性影響，則這一補丁以個別補丁的形式向使用者提供。個別補丁是與某一個特定的PSR關聯，是安裝在這一PSR之上的。另外，如同其名字表明的，個別補丁只是單一Bug的補丁，不會包含其他個別補丁，即不是累積型的。

    在9.2版之前，安裝個別補丁的操作完全是手工的。這種手工方式的缺點不僅在於加重DBA的負擔，容易造成操作失誤，更嚴重的是無法對已安裝的個別補丁進行管理。

    為解決手工方式的缺陷，從9.2版開始，Oracle公司設計實現了個別補丁安裝管理工具opatch.opatch使用一個稱為inventory的系統資料結構（嚴格說是與oui共享inventory），集中管理所有已安裝的個別補丁；個別補丁的安裝和解除安裝都使用opatch命令完成，衝突檢測也由opatch在安裝時自動完成；提供列表命令可以很方便得到已安裝個別補丁的資訊。

    10g（10.1和10.2）版本中，opatch作為一個標準工具，在軟體安裝時自動安裝。（安裝在$ORACLE_HOME/OPatch下。）而對於9.2版，需要從metalink下載opatch.無論資料庫是哪一個版本，系統中是否已經安裝opatch，在使用之前，應從metalink下載最新版本的opatch.很遺憾，由於系統實現的問題，10.2使用的opatch與之前版本（10.1和9.2）使用的opatch不相容，不能混用，這一點必須注意。

    opatch是使用perl編寫的指令碼程式（其中也使用JAVA API）。程式設計使用的perl版本是5.6版，雖然在5.6之前的版本中也可執行，但應儘可能安裝5.6或以上的版本的perl.對於DBA來說一個好訊息是，如果安裝9.2版軟體時保留了HTTP伺服器，則在$ORACLE_HOME/Apache下會自動安裝perl.（10g會自動安裝配置perl和opatch.）

    opatch命令格式為：

    opatch < command > [< command_options >] [ -h[elp] ]

    命令有：apply（安裝個別補丁）、rollback（解除安裝個別補丁）、lsinventory（對inventory進行列表）、query（顯示某一個別補丁的詳細資訊）、version（顯示opatch版本資訊）。在opatch目錄下，有使用者使用指南檔案（Users_Guide.txt），其中有詳細的命令格式和使用示例，讀者可以參考。Opatch執行操作時，除在螢幕輸出結果外，還生成日誌檔案。日誌檔案的路徑和檔名格式如下：

    $ORACLE_HOME/.patch_storage/< patch_id >/< action >-< patch_id >_< mm-dd-yyyy_hh-mi-ss >.log

    其中“patch_id”是Oracle技術支援部門為個別補丁分配的編號。

    4. 個別補丁安裝例項

    沿用安裝PSR例項中的環境。在安裝PSR10.1.0.5後，檢索metalink，發現若干在其之上的個別補丁。選擇其中之一安裝。

    個別補丁Patch 4518443修復BUG4518443，這一BUG的主要問題是TNS LISTENER在註冊ONS（Oracle Notification Services）的同時如果建立子程式，那麼LISTENER會掛起（HANGUP）。

    安裝時，首先，從metalink下載補丁的壓縮檔案p4518443_10105_LINUX.zip.將此檔案解壓縮至某一目錄中。解壓縮後，這一補丁的所有檔案都在子目錄4518443下，目錄名就是個別補丁的補丁號，opatch依據目錄名獲得資訊，所以一定不要重新命名子目錄。

    然後，在終端視窗中，執行cd命令移動到4518443子目錄中，執行以下命令：

    $ $ORACLE_HOME/OPatch/opatch apply

對inventory列表，確認安裝操作：

    $ $ORACLE_HOME/OPatch/opatch lsinventory

    執行解除安裝命令時，也必須使4518443子目錄成為當前目錄。其中，Rollback命令需要兩個引數：-id給出個別補丁號；-ph 給出個別補丁解壓縮後的路徑。

    $ $ORACLE_HOME/OPatch/opatch rollback -id 4518443 -ph /…/4518443

    隨後再對inventory列表，則會看到這一個別補丁已經被移去。

    4. 使用opatch顯示已安裝的版本資訊

    不需要啟動資料庫，執行加選項的對inventory的列表命令，可以得到已安裝的軟體的各個元件的詳細版本資訊。

    $ $ORACLE_HOME/OPatch/opatch lsinventory -detail

    安全補丁CPU

    一個CPU內包含了對多個安全漏洞的修復，並且也包括相應必需的非安全漏洞的補丁。CPU是累積型的，只要安裝最新發布的CPU即可，其中包括之前釋出的所有CPU的內容。事實上，在CPU之前的安全漏洞修改除去個別例外也被包括在CPU中。Oracle公司只對處於標準技術支援和延長支援期間的產品提供CPU更新，對處於維持支援範圍的產品不提供新的CPU.（對於9.2以前的版本，只對處於ECS和EMS期間的版本提供CPU更新。）一般對當前補丁發行版及前一個版本提供CPU，但也有隻限於當前補丁發行版的例外情形。也就是說，一般需要先安裝最新PSR後才可能安裝CPU.由於是累積型的定期釋出，所以對於某一平臺的某一版本，如果兩次CPU釋出期間沒有發現新的安全漏洞，則新發布的CPU與前一版本完全相同。

 在以下網址中可以找到CPU釋出的資訊，但是很遺憾，只有技術支援簽約使用者才可以從metalink下載補丁檔案。

    http://www.oracle.com/technology/deploy/security/alerts.htm

    Oracle公司制定的CPU的釋出日期大約在一月、四月、七月和十月的最接近15的星期二。

    對於每一個CPU，附有相應的說明文件（Critical Patch Update Note），其中介紹安裝過程和注意事項，在安裝之前應認真閱讀此文件。同樣也存在文件“Oracle Critical Patch Update MM YYYY Known Issues for Oracle Database”，其中列出了說明文件中沒有給出的新資訊。

    在安裝時，首先下載壓縮檔案p5225797_10105_LINUX.zip，解壓縮到與其它個別補丁相同的目錄下。檢查其發行說明時，發現要求opatch版本比現已安裝版本要高，下載安裝指定版本opatch.進入子目錄5225797（這是此安全補丁的補丁號），執行apply命令。

    $ $ORACLE_HOME/OPatch/opatch apply

    開啟此次安裝生成的日誌檔案，其中沒有錯誤資訊出現。執行inventory列表命令確認安裝：

    $ $ORACLE_HOME/opatch lsinventory