一種Oracle快速的整合遷移方案

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

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

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

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

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

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

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

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

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

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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！