根據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的配置文件。這裏執行一個修改文件存取權限的“後操作”，以便非同組用戶和程序可以存取客戶端工具和庫函數。
如前所述，在發佈一個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技術支持部門爲個別補丁分配的編號。
沿用安裝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 給出個別補丁解壓縮後的路徑。
$ $ORACLE_HOME/OPatch/opatch rollback -id 4518443 -ph /…/4518443
隨後再對inventory列表，則會看到這一個別補丁已經被移去。
不需要啓動數據庫，執行加選項的對inventory的列表命令，可以得到已安裝的軟件的各個組件的詳細版本信息。
$ $ORACLE_HOME/OPatch/opatch lsinventory -detail