多套Oracle 10g整合遷移到11g的方案

在數據遷移中，除了跨平台，全量，增量數據遷移之外，還有一類會把已有的難度升級，那就是整合式遷移，比如原來有兩個數據，遷移後是一個，類似這樣的需求，如果再加上平滑升級資料庫版本，那就值得我們好好想想方案了。

如果兩個源庫不大，其實直接使用Datapump不失為一種方法，最大的優點就是操作簡單，可控性強，而瓶頸也很明顯，隨著數據量的增長，這個遷移時長就會線性增長，從邏輯遷移的角度來看，對於版本升級的依賴性不高。

而如果兩個源庫都很大，比如都是5T這樣的級別，整合起來就是10T,這樣的量級，給你一個小時搞定，而且還要做資料庫的平滑升級，難度就相當大了。

我們來簡單理一下時間主要都花在哪裡了。

1.數據導出，我們還需要額外配置的磁碟空間和存儲，基本是200%以上的冗餘空間才可以，我們拍腦袋給個時間，比如30分鐘。

2.數據dump傳輸到目標庫，這個時間依賴於幾個點，比如源庫的網路鏈路配置，帶寬上限等。假設這些都不是問題，還是拍腦袋，至少得60分鐘

3.如果按照預想的計划到了這一步，數據遷移的工作還沒正式開始，時間就用完了。我們硬著頭皮繼續，數據導入，按照目前做PCIE-SSD POC的數據，5T按照最理想的情況，非歸檔導入至少得500分鐘

所以上面的方案就註定了是一個失敗的遷移案例，但是我們可以從中優化出很多東西，直到滿足我們的需求為止。

我們拋開上面的方案來，簡單回憶一下，資料庫遷移的本質，資料庫升級的本質，首先數據可以大體分為系統表空間數據(system,sysaux,undo),應用數據（表數據，索引等），只是表現形式會是表空間，數據文件，如果跨平台，我們考慮的數據的邏輯一致性，而如果不跨平台，考慮的是儘可能按照物理一致性來考量。在整合式遷移中，物理一致性就很難實現，但是我們可以最大程度的實現。

然後是資料庫升級的本質，本質上資料庫升級就是數據字典升級，對於數據文件來說，簡單來說，可以認為沒有差別。

所以資料庫從低版本升級到高版本，比如10g到11g,數據文件本質上是不變的，那麼變化的是數據字典，我們就可以取長補短。我們只關注數據字典的這部分，遷移的時候就會有很明確的方向。

那麼上面失敗的案例如何優化呢。我們可以極大的減少導出的時間，減少數據dump傳輸的時間，說得更加自信一些，我們能不能不導出數據，不傳輸dump。答案顯然是可以的，那就是充分利用Data Guard。

這樣前期的工作在正式遷移前都已經就位了，升級的過程中我們需要做得事情就是關注於數據字典的升級，而遷移的部分怎麼來做呢，就是通過傳輸表空間的方式來實現。

假設我們要遷移的資料庫是peak,extradb,我們計劃整合後的資料庫為peak,那麼在伺服器上應該會有下面的實例，很明顯有兩個名為peak的資料庫，因為ORACLE_HOME的不同，所以不會衝突。

按照目標庫最終的結果，我們的oradata下的目錄結果大體如下：

peak是最終的數據文件，extradb和peak的數據文件統統在peak目錄下面，而extradb的系統表空間在extradb目錄下，源庫peak的數據字典在peak_old下。

如果要遷移數據文件，在備庫上操作很簡單，可以參考如下的動態SQL.

select alter database rename file chr(39)namechr(39) to chr(39)replace(name, /extradb/ , /peak/ ) chr(39) ; from v$datafile;

這個時候peak目錄下的文件就像參加一個聚會一樣，大家都坐在一起，但是彼此之間還缺少聯繫，還沒有連接起來。

遷移前，需要做一個基本的檢查，當然這個工作是提前要做好的。到時候至少驗證一下即可。

然後查看

是否有衝突的信息

遷移的時候，把表空間置為read only狀態，可以使用如下的動態SQL來生成批量的遷移腳本。

導出數據字典的信息：

這個dump其實很小，而且導入的過程時間也很短。

接下來的工作就很瑣碎了，就是初始化基本的用戶信息，準備導入數據字典的信息，這裡需要提到一點的是users表空間的部分，這個表空間整合肯定會衝突，所以如果條件允許，我們可以給表空間改一下名字，避免衝突無法導入。

導入的部分語句如下，這個過程就是最終的映射，其實就跟一次聚會一樣，彼此介紹大家互相認識，產生了連接。

遷移的核心就在此了，行與不行全看這裡了。

而遷移之後，切記需要把表空間置為讀寫狀態，這樣一來大部分的遷移工作就提前準備好了。

如果滿打滿算，準備充分，半個小時搞定全然不成問題。

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