如果系統在執行中出現過某種問題，由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.更新資料庫資料字典
更新資料字典時，必須以特殊的升級方式開啟資料庫。
|
執行結束後，關閉重定向：
|
開啟檔案patch.log檢查是否有錯誤“ORA-”。（這一檔案在啟動sqlplus時的當前目錄中，當然也可以在“SPOOL patch.log”語句中顯式指定檔案路徑。）如果出現錯誤要分析原因，在解決問題後，需要再次執行catpatch.sql程式。
更新資料字典時，由於對某些PL/SQL包刪除後又重新生成，造成相關PL/SQL包的狀態為異常（invalid）。在以後呼叫這些包時，檢測到其狀態為非法，會自動執行編譯命令，使狀態成為正常（valid）。雖然不會出錯，但會造成個別處理第一次執行時變慢。顯然，與其留到應用系統執行時再一個個編譯，不如之前集中一次重編譯所有異常包。
|
最後，根據Known Issues中的指示，完成與本系統有關的操作。例如，修改Pro*C的配置檔案。這裡執行一個修改檔案存取許可權的“後操作”，以便非同組使用者和程式可以存取客戶端工具和庫函式。
|
個別補丁管理工具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命令格式為：
|
命令有：apply（安裝個別補丁）、rollback（解除安裝個別補丁）、lsinventory（對inventory進行列表）、query（顯示某一個別補丁的詳細資訊）、version（顯示opatch版本資訊）。在opatch目錄下，有使用者使用指南檔案（Users_Guide.txt），其中有詳細的命令格式和使用示例，讀者可以參考。Opatch執行操作時，除在螢幕輸出結果外，還生成日誌檔案。日誌檔案的路徑和檔名格式如下：
|
其中“patch_id”是Oracle技術支援部門為個別補丁分配的編號。
個別補丁安裝例項
沿用安裝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子目錄中，執行以下命令：
|
執行解除安裝命令時，也必須使4518443子目錄成為當前目錄。其中，Rollback命令需要兩個引數：-id給出個別補丁號；-ph 給出個別補丁解壓縮後的路徑。
|
隨後再對inventory列表，則會看到這一個別補丁已經被移去。
使用opatch顯示已安裝的版本資訊
不需要啟動資料庫，執行加選項的對inventory的列表命令，可以得到已安裝的軟體的各個元件的詳細版本資訊。
|
安全補丁CPU
一個CPU內包含了對多個安全漏洞的修復，並且也包括相應必需的非安全漏洞的補丁。CPU是累積型的，只要安裝最新發布的CPU即可，其中包括之前釋出的所有CPU的內容。事實上，在CPU之前的安全漏洞修改除去個別例外也被包括在CPU中。Oracle公司只對處於標準技術支援和延長支援期間的產品提供CPU更新，對處於維持支援範圍的產品不提供新的CPU.（對於9.2以前的版本，只對處於ECS和EMS期間的版本提供CPU更新。）一般對當前補丁發行版及前一個版本提供CPU，但也有隻限於當前補丁發行版的例外情形。也就是說，一般需要先安裝最新PSR後才可能安裝CPU.由於是累積型的定期釋出，所以對於某一平臺的某一版本，如果兩次CPU釋出期間沒有發現新的安全漏洞，則新發布的CPU與前一版本完全相同。