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$;
- 清理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> select * from global_name;
-
- GLOBAL_NAME
- --------------------------------------------------------------------------------
- http://www.oracledatabase12g.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
-
-
- 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/目錄下找到。
