遷移式升級的一點思考

目前有一個很實際的需求，因為硬體老化嚴重，需要能夠藉助一次維護時機把資料庫遷移到一臺較好配置的機器上，避免潛在的硬體故障導致的業務停頓，也算防患於未然吧。
本來這個事情不是很緊急，但是因為硬體故障導致的問題防不勝防，踩過幾次坑，就會有些經驗教訓，在這種情況下維持現狀就是一個潛在的炸彈。
當前的硬體環境是Solaris，Oracle 10gR2 單例項,資料量在800G左右。我大體想了下，主要的目標有以下幾個。
    1.藉助這次維護的時機，能夠把資料庫升級至11g
    2.升級的過程需要儘可能保留一個較短的時間視窗，計劃在2個小時以內完成
    3.有較好的解決方案去演練整個過程，多次總結，提高遷移的效率，保證質量
    4.有完善的回退計劃，能夠支援回退場景下業務平滑過渡
    5.目前對於跨平臺沒有明確的要求，可以繼續使用Solaris，也可以考慮跨平臺，但是影響範圍要小。
大體就是如上的要求，這是我的想法，也得我自己想辦法來落實這些問題：）
有以下幾種方式可以做，不過都是在評估和考慮。
    exp的方案肯定是pass,這個資料量遷移2個小時是完全不可能。
    expdp的方案2個小時也是無法達到，有兩個瓶頸，一個是CPU使用的瓶頸，匯出dump,匯入dump得依賴於系統資源，二是主庫還得備有額外的空間，三是網路的瓶頸，傳輸dump這個地方無法控制，而且因為硬體老化，網路卡在大批次併發的情況下出現故障那就悲劇了。
    OGG的方案可行性高，之前和幾個兄弟討論過，先在備庫的基礎上基於SCN做全量同步，再設定資料同步的頻率從主庫同步，這樣第一次的初始化對於主庫的壓力大大降低。不過有個問題是伺服器實在是年歲已高，不能完全保證在主庫，備庫折騰一番，伺服器還依舊吃得消。當然這個也是藉口啦，OGG也得花一些時間才能玩得轉。高效，可控的基礎是熟練掌握它。
    使用XTTS的方案也不錯，技術實現上肯定是妥妥的。這種方案的一個瓶頸還是在於網路的頻寬，而且XTTS的方案實現在10g版本上還沒有親自嘗試過，如果試水，還是有一些風險。
    使用DBUA的方式來升級，也是一個不錯的方案，先使用Data Guard切換，然後直接升級至11g，圖形的方式或者是命令列的方式均可。這種方式的優點很明顯，升級前的檢查和準備足夠充分，升級資料庫的時候就會平滑許多，自己也這麼參與過不少的案例。這種方案和資料量就沒有太大的關係了，升級的本質就是升級資料字典，所以這部分的時間主要就花費在升級上。
    還有一種方案自己也在琢磨中，那就是Data Guard+TTS，實現的思路大體是備庫上建立一個11g同名的資料庫，然後原來10g的資料庫Failover變為主庫，匯出後設資料，然後修改11g資料庫的配置，匯入後設資料，這個過程中出了系統表空間外，資料表空間不動。這樣就可以直接避免檔案遷移帶來的很毒瓶頸和限制。
    這幾種方案個人比較喜歡最後一種，先說維護視窗，如果免去了複製資料檔案的時長，那麼匯出匯入的過程就會很快，應該比手工/圖形方式升級資料庫還要快。如果保證能夠反覆演練，可以合理利用備庫的閃回功能，failover之後閃回照樣能夠修改為物理備庫正常應用日誌，為了方便演練，可以複製一份資料的映象，隨時啟用，這樣10g,11g的庫都可以正常執行。一旦出現災難，直接把連線切到原來的主庫端去即可。