本文轉自ML的Blog：
Oracle數據庫升級向來是一門紛繁複雜的工程，DBA需要爲產品數據庫的升級耗費大量時間精力在準備工作上；因爲其升級複雜度高，所以即便做了較爲充分的準備仍可能在升級過程中遇到意想不到的問題，爲了更高效地完成升級任務和減少停機時間，我們有必要爲升級工作營造一種”舒適的”防禦式的數據庫”氛圍”:
1.爲了保障升級後的數據庫性能，我們有必要在升級前有效地收集數據庫的性能統計信息，以便升級後若發生性能問題可以做出對比:
(1) 爲了保證性能統計信息真實有效，有必要在數據庫升級前的一個月即開展收集工作
(2) 收集的性能統計信息應當儘可能的精確真實
(3) 在Oracle 8i/9i中使用Statspack性能報表，將快照級別設置爲6或更高，設置快照間隔爲30分鐘，在具體升級前將perfstat用戶使用exp工具導出，參考Metalink文檔Note:466350.1介紹了若何對比升級前後的Statspack快照
(4) 在Oracle 10g/11g中使用AWR自動負載倉庫性能報告，保證採集30天左右的快照，快照間隔最好爲30-60分鐘;之後可以使用dbms_swrf_internal.awr_extract存儲過程將AWR導出到dumpfile文件，在升級完成後載入這部分AWR信息，並可以使用DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_HTML函數對比升級前後的性能
2.正式升級前的防禦性措施:
（1）過多的審計信息可能會導致升級速度下降，可以在升級前將審計數據導出，並清理審計字典基表:
截斷SYS.AUD$基表:
SQL>TRUNCATETABLE SYS.AUD$;
Oracle 11g 的審計，更多內容參考：
http://blog.csdn.net/tianlesoftware/article/details/6707887
（2）同樣的有必要清理10g後出現的回收站：
清理DBA回收站:
SQL>purge DBA_RECYCLEBIN;
（3）移除一些”過期”的參數，設置這些參數的原因很有可能是爲了修正原版本上的一些問題，例如我們都會做的設置event參數；但在新版本中這些參數是否仍有必要設置是一個值得討論的問題，當然你完全可以就此事去提交一個SR：
這些"過期"參數可能包括:過老的如optimizer_features_enable=8.1.7.4,_always_semi_join=off,_unnest_subquery=false
或者event ="10061 trace name context forever, level 10"，如此之類等等。
有關參數是否過時，可以從V$OBSOLETE_PARAMETER視圖查看。
更多內容參考：
http://blog.csdn.net/tianlesoftware/article/details/5583655
（4）爲數據庫中的數據字典收集統計信息:
在Oracle 9i中可以執行以下過程收集數據字典統計信息,
SQL> exec DBMS_STATS.GATHER_SCHEMA_STATS
('SYS', options => 'GATHER',estimate_percent =>
DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR
ALL COLUMNS SIZE AUTO', cascade => TRUE);
在Oracle10g/11g中收集字典統計信息可以由GATHER_DICTIONARY_STATS存儲過程來完成:
SQL> execDBMS_STATS.GATHER_DICTIONARY_STATS;
這個腳本在Oracle11g升級前的檢查腳本（utlu112i.sql）中也會推薦我們執行。
（5）爲策萬全，我們有必要爲回退數據庫升級任務做好準備，10g以前只能通過備份恢復來完成，10g以後我們可以利用閃回數據庫的還原點特性來回退數據庫，但需要注意以下幾點:
(1) 利用還原點要求數據庫處於歸檔且打開flashback database的模式下
(2) 在特性僅在版本10.2之後可用
(3) 必須保證閃回回復區flashback recovery area有足夠的磁盤空間
(4) 注意在升級後不要立即修改compatible參數，restore point無法跨越compatible工作
有關FlashbackRestore Points的更多說明和示例，參考我的Blog：
OracleFlashback Database and Restore Points 說明
http://blog.csdn.net/tianlesoftware/article/details/6917546
（6）下載最新版本的預升級檢查腳本(pre-upgrade checkscript)，如utlu102i.sql/ utlu111i.sql / utlu112i.sql；Metalink文檔Note:884522.1 <Howto Download and Run Oracle’s Database Pre-Upgrade Utility> 指出了各版本utluxxx腳本的下載地址
在11g中自帶了這個腳本，不需要下載。
/* 將升級信息spool到日誌文件中 */
SQL> SPOOL /tmp/UPGRADE/utlu112i.log
SQL> @/tmp/UPGRADE/utlu112i.sql
這2個腳本的具體使用示例，可以參考：
Oracle 使用RMAN 將 DB 從10g 直接Restore 到11g 示例
http://blog.csdn.net/tianlesoftware/article/details/7311352
http://blog.csdn.net/tianlesoftware/article/details/6833591
（7）需要關注SYS和SYSTEM用戶模式下的失效對象，有必要在升級前修復所有的失效對象：
SELECT UNIQUE object_name, object_type,owner
FROM dba_objects
WHERE status = 'INVALID';
（8） 在升級完成後推薦執行utlrp.sql腳本以重新編譯(Recompile)對象，從11.1.0.7開始升級前後的失效對象將自動對比，執行?/rdbms/admin/utluiobj.sql腳本可以列出對比信息，同時基表registry$sys_inv_objs和registry$nonsys_inv_objs分別列出了數據庫中失效的sys或非sys對象:
SQL> @?/rdbms/admin/utluiobj.sql
.
Oracle Database 11.1 Post-Upgrade InvalidObjects Tool 03-05-2012 16:52:29
.
This tool lists post-upgrade invalidobjects that were not invalid
prior to upgrade (it ignores pre-existingpre-upgrade invalid objects).
.
Owner Object Name Object Type
.
SYS DBMS_CUBE_EXP PACKAGE BODY
SYS DBMS_NETWORK_ACL_ADMIN PACKAGE BODY
SYS DBMS_XS_PRINCIPAL_EVENTS_INT PACKAGE BODY
SYS KUPW$WORKER PACKAGE BODY
SYS XS$CATVIEW_UTIL PACKAGE BODY
PL/SQL procedure successfully completed.
3.解決升級過程中失效的組件(component)
(1) 確保該部分組件確實被link到目前的Oracle軟件2進制可執行文件或庫文件中
(2) 如果確認不會用到某些組件(component)，想要通過手動徹底移除這部分組件(亦或者希望reinstall重新安裝這部分組件)，那麼可以參考以下文檔:
Note:472937.1 Information On InstalledDatabase Components/Schemas
Note.300056.1 Debug and Validate InvalidObjects
Note:753041.1 How to diagnose Componentswith NON VALID status
Note.733667.1 How to Determine if XDB isBeing Used in the Database?
組件升級失敗實例1:
數據庫從10.2升級到11.2，在10g的環境中Database Vault組件已經安裝，Database Vault組件在升級relink前被turned off，在升級到11.2的過程中XDB組件升級失敗；其原因在於安裝或切換Database Vault將使得XDB組件失效，或者由Bug 8942758引起。
解決方案：在升級前執行utlrp.sql腳本重新編譯失效對象和組件，在此例中執行utlrp.sql可以使XDB組件valid.
組件升級失敗實例2:
數據庫從10.2.0.4升級到11.1.0.7，在升級過程中"ORACLE SERVER"組件失效；其原因在於DMBS_SQLPA包引用了某個不存在的列，該問題可以參考metalink文檔782735.1和Notes:605317.1/736353.1。
有效的解決方案是：
（1）.在升級前將SYS.PLAN_TABLE$基表或者同義詞PUBLIC.PLAN_TABLE DROP掉
（2）.若已執行了升級操作並遭遇了該問題，那麼可以使用以下手段修復該問題:
@catplan.sql -- recreate the plan table
@dbmsxpln.sql -- reload dbms_xplan spec
@prvtxpln.plb -- reload dbms_xplanimplementation
@prvtspao.plb -- reload dbms_sqlpa
alter package SYS.DBMS_SUMADVISOR compile ;
alter package SYS.DBMS_SUMADVISOR compilebody;
更多有關組件中間的問題，參考：
http://blog.csdn.net/tianlesoftware/article/details/7339998
Oracle8i/9i/10g/11g 組件（Components） 說明
http://blog.csdn.net/tianlesoftware/article/details/5937382
4. 使用例如AIX上的slibclean等命令清理操作系統環境，在少數專有平臺上不清理載入的共享庫文件可能導致升級失敗
5.在執行catupgrd.sql腳本正式升級前打開sqlplus的echo輸出，將升級過程中所有的輸出信息轉儲到日誌文件中:
SQL> set echo on
--默認爲off，設爲on 會顯示執行的sql語句，而不僅僅是結果。
SQL> SPOOL /tmp/upgrade.log
SQL> @catupgrd.sql
SQL> spool off
DBUA圖形化升級工具默認使用spool和”echo”輸出，這些日誌可以在$ORACLE_HOME/cfgtoollogs/dbua//upgrade/目錄下找到。