『壹』 linux安裝oracle補丁報錯libjvm.so: cannot open shared object file: No such file or directory
在oracle的安裝目錄中先找到libjvm.so的路徑，然後把路徑加入到LD_LIBRARY_PATH這個環境變數中。
確認用安裝oracle的用戶去安裝oracle的補丁。ORACLE_HOME、ORACLE_BASE什麼的都正確。
『貳』 如何利用oracle opatch打補丁
給軟體打補丁相當於給人打預防針，對系統的穩定運行至關重要。本文詳細、系統地介紹了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、mp等命令完成。如果希望縮短文件拷貝時間，可以考慮分區備份的方法。分區備份常用的命令是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/， 選中procts.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與前一版本完全相同。