Datapump資料移轉的實踐總結

Datapump資料移轉的實踐總結

雖說實踐了不少的資料移轉項目，但是從我的感觸來說，一些很細小的差別就會造成整個資料移轉方案的大不同。資料是系統的核心命脈，所以對於DBA來說，保證資料的一致性和準確性是一個最基本的要求。對此我的一個基本觀點就是高可用的需求除非特殊需要，一般都還是需要一個維護視窗的，這種方式更為保守，但是更為保證。

而在Datapump遷移中還是遇到了不少的小問題，也算是一些心得或者建議吧。

1）如果是跨平台的資料移轉，在升級前需要得到一個清單，包含哪些失效的對象，是否需要重新編譯，如果不確認，在遷移之後就會更加迷茫，到底是不是遷移之後造成的問題。

2）資料移轉中還是建議直接停掉監聽，保證沒有其它的外來串連，在之前的大型資料移轉中，雖然從口頭上制度上會有一些約束，但是不能完全保證其他人能夠完全遵守，有時候應用的同事需要提前檢查一些資料，可能會想做一些查詢，這個就比較難控制了。而且很可能會觸發一些小問題，尤其是效能問題。

3）如果在資料移轉時條件允許，還是建議直接設定為非歸檔模式，有缺點也有優點，優點是整體的速度會提高差不多1倍，但是缺點是主備庫的架構會需要重建，而且在資料移轉後期，收集統計資訊的階段其實會消耗掉不少的時間，如果是非歸檔模式，必須要等待遷移徹底完成才可以，而如果時間視窗允許，而且需要保證主備庫的架構，只能在歸檔模式下，優點就是保留了主備的架構，無需重新搭建，另外一個有點就是編譯預存程序，收集統計資訊的階段，其實已經可以在內部開始一些基本的驗證和測試了。因為內部的一些流程和步驟本身需要一些時間，所以這個時間段就可以充分結合起來。缺點也很明顯，效率上會差一些，而且需要額外的空間，同步增量的資料需要較高的頻寬。所以這是一把雙刃劍。

4）在源庫中匯出dump，傳輸到目標庫的時候，不要開啟過多的傳輸進程，這個時候會有一種問題就是會嚴重影響其他的用戶端串連進來，這裡也有一些需要注意的地方，有時候還是很值得琢磨琢磨，比如有1000個dump，那麼我們肯定不可能開啟1000個進程同時傳輸，我們只能開啟一小部分，始終保留有資料的傳輸，這個持續的過程就有幾種考量，一種是一批一批，比如一次30個dump，完成之後再開啟30個dump的傳輸。另外一種是按照時間的先後開啟30個，但是始終保證後台運行偶30個dump的傳輸進程。第一種方式可以做成指令碼的模式，但是可控性，靈活性略微差一些，而第二種就是半自動的方式，需要很多時候人工介入。

5）在傳輸dump的時候還是直接使用固定的IP而非綁定的漂移IP，這個效能差異個人感覺還是非常大的，在演練中使用同樣的硬體環境，同樣資料量大概需要傳輸40分鐘，而使用綁定IP,漂移IP這個效能就差了很多，花費的時間多了一倍。

6）如果在遷移後目標伺服器的IP需要變更為原始伺服器的IP，這這個過程中讓人比較糾結的就是DB Link,而隨著相關的就是含有DB Link的預存程序，包體，視圖等。這個過程尤其需要注意，建議還是在遷移前就修改IP，保證防火牆資訊和源庫一致，這樣DB Link的坑就會避免。遷移升級的時間，每一分鐘都是需要盡量去爭取的，對於系統級的網路逾時是一分鐘，如果存在大量的預存程序存在過多依賴，那這個編譯過程就會大打折扣。

 比如我們在遷移中碰到的預存程序編譯。

ALTER PROCEDURE "TEST"."P_TEST"  COMPILE    PLSQL_OPTIMIZE_LEVEL=  0    PLSQL_CODE_TYPE=  INTERPRETED    PLSQL_DEBUG=  TRUPLSCOPE_SETTI

 NGS=  '' REUSE SETTINGS TIMESTAMP '2014-09-18 07:35:33'

其實這種編譯過程能花費什麼時間，時間都在網路的驗證逾時上了。

7）遷移的演練非常重要，儘可能完全模擬整個遷移的過程，如果嫌麻煩跳過了一些步驟，或者認為可能影響不大忽略了一些小的步驟，那麼這些問題就會交給遷移時間，碰到了問題處理起來就非常痛苦了。

8）遷移前的準備越充分，遷移的時候就會越輕鬆，遷移最後有一個檢查清單和步驟，特別是在有時候工作不在狀態的時候，這個就是一個綱要和指導方針。

9）遷移是一件苦活，需要始終保持注意力，細心的對待可能出現的問題環節，對於突發情況還是要冷靜，這個當然多說無益，實踐出真知。