Oracle數據庫升級向來是一門紛繁復雜的工程，DBA需要為產品數據庫的升級耗費大量時間精力在准備工作上；因為其升級復雜度高，所以即便做了較為充分的准備仍可能在升級過程中遇到意想不到的問題，為了更高效地完成升級任務和減少停機時間，我們有必要為升級工作營造一種”舒適的”防御式的數據庫”氛圍”:
1.為了保障升級后的數據庫性能，我們有必要在升級前有效地收集數據庫的性能統計信息，以便升級后若發生性能問題可以做出對比:
- 為了保證性能統計信息真實有效，有必要在數據庫升級前的一個月即開展收集工作
- 收集的性能統計信息應當盡可能的精確真實
- 在Oracle 8i/9i中使用Statspack性能報表，將快照級別設置為6或更高，設置快照間隔為30分鍾，在具體升級前將perfstat用戶使用exp工具導出，參考Metalink文檔Note:466350.1介紹了若何對比升級前后的Statspack快照
- 在Oracle 10g/11g中使用AWR自動負載倉庫性能報告，保證采集30天左右的快照，快照間隔最好為30-60分鍾;之后可以使用dbms_swrf_internal.awr_extract存儲過程將AWR導出到dumpfile文件，在升級完成后載入這部分AWR信息，並可以使用DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_HTML函數對比升級前后的性能
2.正式升級前的防御性措施:
- 過多的審計信息可能會導致升級速度下降，可以在升級前將審計數據導出，並清理審計字典基表:
截斷SYS.AUD$基表: SQL>TRUNCATE TABLE SYS.AUD$;
- 同樣的有必要清理10g后出現的回收站：
清理DBA回收站: SQL>purge DBA_RECYCLEBIN;
- 移除一些”過期”的參數，設置這些參數的原因很有可能是為了修正原版本上的一些問題，例如我們都會做的設置event參數；但在新版本中這些參數是否仍有必要設置是一個值得討論的問題，當然你完全可以就此事去提交一個SR：
這些"過期"參數可能包括:過老的如optimizer_features_enable=8.1.7.4,_always_semi_join=off,_unnest_subquery=false 或者event = "10061 trace name context forever, level 10"，如此之類等等。
- 為數據庫中的數據字典收集統計信息:
在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> exec DBMS_STATS.GATHER_DICTIONARY_STATS;
- 為策萬全，我們有必要為回退數據庫升級任務做好准備，10g以前只能通過備份恢復來完成，10g以后我們可以利用閃回數據庫的還原點特性來回退數據庫，但需要注意以下幾點:
- 利用還原點要求數據庫處於歸檔且打開flashback database的模式下
- 在特性僅在版本10.2之后可用
- 必須保證閃回回復區flashback recovery area有足夠的磁盤空間
- 注意在升級后不要立即修改compatible參數，restore point無法跨越compatible工作
/* 首先我們在正式升級前創建一個有效的保證閃回數據庫的還原點 */
SQL> create restore point pre11gupgrd guarantee flashback database;
Restore point created.
/* 確認以上4個注意后，我們可以大膽放心地實施升級工作了 */
SQL> shutdown immediate;
..............
SQL> @?/rdbms/admin/catupgrd.sql
.............
upgrade failed
/* 在升級過程中出現了不可繞過的錯誤時，我們可能不得不回退數據庫到還原點，也就是升級前*/
/* 關閉實例后，還原環境到10g下 */
SQL> startup mount;
/* 正式閃回到還原點pre11gupgrd */
SQL> flashback database to restore point pre11gupgrd;
Flashback complete.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
SQL> alter database open resetlogs;
/* 以resetlogs打開數據庫 */
/* 之后有必要刪除這一個還原點 */
SQL> select * from v$restore_point;
SCN DATABASE_INCARNATION# GUA STORAGE_SIZE
---------- --------------------- --- ------------
TIME
---------------------------------------------------------------------------
NAME
--------------------------------------------------------------------------------
5081633 3 YES 15941632
08-FEB-11 08.20.33.000000000 PM
PRE11GUPGRD
SQL> drop restore point pre11gupgrd;
Restore point dropped.
- 下載最新版本的預升級檢查腳本(pre-upgrade check script)，如utlu102i.sql / utlu111i.sql / utlu112i.sql；Metalink文檔Note:884522.1 <How to Download and Run Oracle’s Database Pre-Upgrade Utility> 指出了各版本utluxxx腳本的下載地址
/* 將升級信息spool到日志文件中 */ SQL> SPOOL /tmp/UPGRADE/utlu112i.log SQL> @/tmp/UPGRADE/utlu112i.sql
- 需要關注SYS和SYSTEM用戶模式下的失效對象，有必要在升級前修復所有的失效對象：
SELECT UNIQUE object_name, object_type, owner FROM dba_objects WHERE status = 'INVALID';
- 在升級完成后推薦執行utlrp.sql腳本以重新編譯(Recompile)對象，從11.1.0.7開始升級前后的失效對象將自動對比，執行?/rdbms/admin/utluiobj.sql腳本可以列出對比信息，同時基表registry$sys_inv_objs和registry$nonsys_inv_objs分別列出了數據庫中失效的sys或非sys對象:
SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production PL/SQL Release 11.2.0.1.0 - Production CORE 11.2.0.1.0 Production TNS for Linux: Version 11.2.0.1.0 - Production NLSRTL Version 11.2.0.1.0 - Production SQL> @?/rdbms/admin/utluiobj.sql . Oracle Database 11.1 Post-Upgrade Invalid Objects Tool 02-08-2011 22:23:22 . This tool lists post-upgrade invalid objects that were not invalid prior to upgrade (it ignores pre-existing pre-upgrade invalid objects). . Owner Object Name Object Type . SH FWEEK_PSCAT_SALES_MV MATERIALIZED VIEW PL/SQL procedure successfully completed.
3.解決升級過程中失效的組件(component)
- 確保該部分組件確實被link到目前的Oracle軟件2進制可執行文件或庫文件中
- 如果確認不會用到某些組件(component)，想要通過手動徹底移除這部分組件(亦或者希望reinstall重新安裝這部分組件)，那么可以參考以下文檔:
Note:472937.1 Information On Installed Database Components/Schemas Note.300056.1 Debug and Validate Invalid Objects Note:753041.1 How to diagnose Components with NON VALID status Note.733667.1 How to Determine if XDB is Being 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_xplan implementation @prvtspao.plb -- reload dbms_sqlpa alter package SYS.DBMS_SUMADVISOR compile ; alter package SYS.DBMS_SUMADVISOR compile body;
4. 使用例如AIX上的slibclean等命令清理操作系統環境，在少數專有平台上不清理載入的共享庫文件可能導致升級失敗
5.在執行catupgrd.sql腳本正式升級前打開sqlplus的echo輸出，將升級過程中所有的輸出信息轉儲到日志文件中:
SQL> set echo on SQL> SPOOL /tmp/upgrade.log SQL> @catupgrd.sql SQL> spool off
DBUA圖形化升級工具默認使用spool和”echo”輸出，這些日志可以在$ORACLE_HOME/cfgtoollogs/dbua//upgrade/目錄下找到。
轉載自：http://www.askmaclean.com/archives/oracle%E6%95%B0%E6%8D%AE%E5%BA%93%E5%8D%87%E7%BA%A7%E5%89%8D%E5%BF%85%E8%A6%81%E7%9A%84%E5%87%86%E5%A4%87%E5%B7%A5%E4%BD%9C.html