一、項目背景
經過綜合評估后，考慮到停機的時間窗口要求等關鍵因素，決定通過升級數據字典方式，將數據庫從10.2.0.4升級到11.2.0.4
二、數據庫升級項目階段劃分
Oracle數據庫系統升級和遷移是一項機遇和風險并存的復雜的系統工程。
對現有系統的全面了解和評估、升級需求的分析、合理的實施技術方案設計是升級項目的基礎；
數據庫升級劃分為可行性分析與評估、前期準備、升級測試、正式升級和后期值守與性能優化等5個主要階段：
.jpg)
二、數據庫升級評估方案及選擇
|
|
升級安排
|
環境要求
|
現狀
|
需要添加設備
|
|
方案1
|
CRM4個中心/資源/公共庫 同時割接(停機1次)
|
12臺割接主機,6份存儲空間
|
1.容災系統的主機配置約為生產1/2，無法支撐全業務運行。
|
8臺主機,5份存儲空間
|
|
方案2
|
1階段CRM 4個中心同時割接;
|
8臺割接主機,4份存儲空間
|
2.當前僅有4臺高配空閑機器。
|
4臺主機,3份存儲空間
|
|
2階段資源和公共庫同時割接;
|
3.有1套<統一備份恢復平臺>環境可用于SPA等測試。
|
|
方案3
|
1階段CRM1,CRM2同時割接;
|
4臺割接主機,2份存儲空間
|
|
1份存儲空間
|
|
2階段CRM3,CRM4同時割接;
|
|
|
3階段資源/公共庫同時割接
|
|
經過綜合評估后，考慮到硬件資源情況，以及對停機窗口的要求，最終決定采用方案2作為升級方案。
三、升級步驟
1.過渡災備環境主機在搬遷前安裝Oracle10g RAC /11g RAC；
2.割接當晚,停止生產10g數據庫，停止生產環境到災備環境的存儲CA,重新同步BCV卷；
3.在過渡災備端開始手工運行數據庫腳本,升級10g到11g；
4.升級成功后，測試當前應用系統是否可以正常訪問升級后的數據庫，如有必要則更改oci/jdbc/odbc等訪問方式的tnsnames，url，DNS配置信息等，正常訪問成功后，可以提供生產運營，完成割接；
5.過渡災備環境作為新生產環境使用約2～3天；
6.新災備環境（原生產環境）第二天中午12點開始升級整改,安裝11gRAC；
7.存儲反向復制(GI OCR VOTE盤獨立)，容災切換。
四、回退方案
1.在確認過渡災備環境升級成功且正常工作前，不要立即啟動遠端到生產端的存儲CA，原生產環境的DB數據做為數據回退保障；
2.當升級失敗導致遠端容災端的CA復制數據損壞，無法修復，可以啟動生產端原生產環境主機上的Oracle 10gR2 RAC數據庫支持生產運營；
五、性能測試11g工具——SPA
1、不僅要加載生產環境的TOP SQL，還要盡量多的加載所有業務的SQL，在生產環境中的非TOP SQL，在升級到11g后可能也會變成TOP SQL
2、加載優化集同時加載所有的統計信息，轉換10g SQL優化集(無須在10g環境中測試執行)，大大減少了時間，并且這些信息反映了實際的執行情況。
