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', ptions => '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
指出了各版本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/目錄下找到。
相關文章 | Related posts:
<!--