廠商提供給用戶的軟件補丁的形式多為編譯後的庫函數，所以安裝軟件補丁實際上就是把這些庫函數拷貝到相應目錄，並在需要時進行聯接操作。軟件公司壹般在壹段時間後會把針對某壹版本的所有補丁進行整理：合並融合，解決沖突，進行整體測試，並使文件拷貝和聯接操作自動執行，得到壹個軟件補丁“包”。不同的公司使用不同的名稱，現在壹般計算機用戶都熟悉的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下生成了多個數據庫，則每個數據庫都必須更新數據字典。
. 實施操作
制訂壹個詳細的計劃後，實施操作就可以“照本宣科”，是壹個簡單的體力勞動。要認識到“忙中出錯”的概率遠比“急中生智”大得多，操作時盡量減少失誤的可能性。例如，需要執行的復雜命令，盡可能從壹個文件拷貝到終端執行，而不要現場輸入。另外，在實施過程中，要記錄各個階段實際的執行時間，以供以後制訂類似計劃時參考。
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與前壹版本完全相同。