HP RISC平臺9i升級到HP Itanium平臺上10g

        Oracle已經不再對9i進行支援，HP對RISC平臺支援將到2013年截止，因此陸續將有相關的升級專案出現，以下是對涉及到的資料庫升級步驟和方法進行闡述。

一、版本要求
   
 建議9i資料庫版本至少9.2.0.7，10g的版本至少10.2.0.2

二、測試環境
源    :   HP-UX RISC/ RP8420/B.11.11/oracle9.2.0.8
目標:    HP-UX Itanium/RX3600/B.11.31/10.2.0.4

 三、源資料庫遷移準備步驟

1、源資料庫生成控制檔案指令碼
SQL>alter database backup controlfile to trace
$ strings spfile.ora >init.ora

2、從10.2.0.4拷貝utlu102i.sql和utltzuv2.sql，並執行
      utlu102i.sql -- 生成資料庫升級檢查資訊報告
      utltzuv2.sql -- 檢查時間區域

3、收集資料庫使用者許可權資訊

4、檢查資料庫是否存在dblink設定

5、檢查是否存在N-type的列，如果存在，需要先前轉化

6、進行統計分析，並備份統計資訊

7、檢查資料庫是否存在無效物件，損壞字典

8、確認物化檢視和快照是否完成，是否存在複製設定

9、檢查v$recover_file，是否存在資料檔案正進行media recovery

10、確保沒有檔案處於備份狀態

11、檢查是否存在正執行的交易，如果有，對該交易進行終止

12、檢查是否存在批量匯入匯出，或定時執行作業

13、檢查系統使用者是否正常指向對應表空間

14、檢查AUD$是否存在系統表空間

15、檢查是否存在XDB.MIGR9202STATUS表，如果存在，刪除它

16、正常關閉資料庫，進行備份，備份方法：
         --使用RMAN進行冷備份
         --通過儲存裝置卷快照功能進行復制
         --資料檔案是檔案型別，採用ftp傳送到目標系統

四、目標資料庫升級步驟

完成10.2.0.4資料庫軟體安裝後，執行以下步驟

1、檢查修改引數檔案init.ora，修改引數
       -- compatible=9.2.0.0.0
       -- shared_pool_size , pga_aggregate_target， 
           large_pool_size,      java_pool_size
           streams_pool_size根據3.1檢查報告建議值設定
       -- 如果設定NLS_LENGTH_SEMANTICS=CHAR需要改成bytes
       -- db_domain
       -- AQ_TM_PROCESSES=0 和JOB_QUEUE_PROCESSES=0
       -- UNDO_MANAGEMENT=AUTO
       -- fixed_date沒有設定

2、啟動資料庫為nomount狀態，修改並執行控制檔案指令碼

3、啟動資料庫為升級模式
SQL>startup upgrade

4、根據3.1檢查報告，有可能增加表空間大小
SQL> alter database datafile 'xxxxx' size xxxm;

5、建立SYSAUX表空間，至少500M

6、升級資料庫字典
SQL> @catupgrd.sql

7、檢查資料庫元件狀態
SQL>@utlu102s.sql TEXT
SQL>select comp_name, status, version from dba_registry;

8、正常關閉資料庫，並重新啟動
SQL>shutdown immediate
SQL>startup restrict pfile='/xxxx/init.ora'

9、重建Oracle Label Security 表中DML觸發器
SQL>@olstrig.sql

10、檢查是否存在無效物件，必要時候進行編譯

11、重啟，統計分析字典
SQL>EXEC DBMS_STATS.GATHER_DICTIONARY_STATS ;

五、通過SQL效能分析器測試新舊資料庫SQL效能

在11g引入了一個Real Application Testing Option，通過一臺配置降低機器，安裝11g資料庫。通過源和目標資料庫SQL跟蹤對比，生成升級前後效能分析報告，具體步驟：

1、在源資料庫建立SQL trace檔案
2、生成對映表
3、將跟蹤檔案拷貝到11g主機目錄下，生成SQL資料集
4、建立資料庫效能分析任務，在源和目標資料庫執行測試指令碼
5、比對兩者之間的效能資料，生成差異性SQL效能報告
6、應用開發人員根據該報告進行修改調整

因為從9i到10gCBO發生了變化，還有一個省事的辦法，設定OPTIMIZER_FEATURES_ENABLE=9.2.0。

六、其他建議

因為CBO發生變化，對以下幾個環節需要注意

1、統計分析使用dbms_stats，不建議使用analyze
2、在引數檔案中不要在設定db_file_muitlblock_read_count
3、要注意捆綁變數窺探(bind variable peeking)，因為其可能造成執行計劃變化
4、執行計劃中採用Index skip scans，需要檢查
5、In-List成本計算公式有可能發生變化
6、Transitive Closure成本計算公式發生變化（可參看前面部落格）
7、sysdate演算法變化
8、Indexing Null
9、pga_aggregate_target，在10.2.0.4有一個PLSQL中forall loop的bug
10、_complex_view_merging，（參看前面部落格）
11、子查詢語句中執行計劃變化最大，效能問題也最多，通常需要加hint來解決
12、並行查詢發生變化
13、動態取樣發生變化，9i是1，10g是2
14、資料字典統計，10g預設每天自動進行統計分析，有可能造成統計資料變化，導致執行計劃發生突變。




      

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/354732/viewspace-661737/，如需轉載，請註明出處，否則將追究法律責任。