一種Oracle快速的整合遷移方案（r12筆記第98天）

  最近在分析一個遷移案例的時候，突然多了一些額外的想法，也算是對原有方案的一個補充。

  比如存在兩個資料庫 peak和esales,彼此是獨立的業務，所幸兩者也沒有使用者的衝突等，都在10g版本，如果需要把他們整合到11g的環境中，遷移的方案就是一個重中之重。

   因為這兩個庫的資料量不大，都不到200G,所以遷移的時間估算下來在2個小時還是可行的。

    初步的想法就是常規的邏輯匯出匯入，比如使用資料泵來做。按照以往的經驗，每個資料庫大概會在40分鐘左右完成。兩個加起來就是80分鐘左右。

    如果碰到點意料之外的情況，兩個小時的時間還算是寬裕的。

    而這個過程中涉及到的一個重要風險點就是備份的傳輸，匯出和傳輸的時間是忽略了的，這樣一來，在網路頻寬郵箱的情況下，很可能出現瓶頸，就在於網路上，這一點上如果過度依賴於一些平臺環境，就很可能出現不可控的情況，說實話整個遷移的過程中大半的時間都在傳輸和匯入的過程中。

   如果把這個過程最佳化一番，能最佳化到多少時間呢，對此一個直接的方案就是把資料預處理的工作提前做好，如果能夠避免重複的資料匯入工作，那麼我們就可以考慮其他的方案，所以我想了如下的一種方案，相對來說對於硬體和平臺的限制會大大降低，那就是透過Data Guard和傳輸資料庫結合的方式來滿足需求。

  注意上面的圖中，兩個備庫都是在10g，他們的唯一差別其實就是在於這個系統表空間的部分，單純說資料字典的資訊，其實匯入資料字典的工作要簡單許多。

   如果簡單估算一下，切換主備庫角色5分鐘，匯入資料字典序列來做，每個大概是10分鐘，資料檔案路徑不變，直接使用傳輸資料庫的方式來做，這樣在遷移的時候就能夠避免複製資料檔案，直接把資料的工作都提前準備好，無論是路徑還是引數配置，在維護的時候就會很平滑的完成。

   整個方案預估是30分鐘內完成，不受網路的限制，不受資料量的直接影響，相對來說提前需要準備的工作量會大一些，但是對於業務的可持續性來說，算是一個福音。