資料遷移中需要考慮的問題

在生産環境中，做資料遷移需要考慮很多的可能性和場景，盡量排除可能發生的問題。我自己總結了下，大體有如下需要注意的地方。

1）充分的測試，評估時間，總結經驗，提升性能

在生産中進行資料的大批量遷移時，充分的測試時必須的。一方面可以根據這些測試積累一些必要的資料作為生産中使用參考，另外一方面可以基于之前的測試，總結經驗，總結不足之處，加入改進，在生産中每一分鐘的改進都是很重要的。

2）完整的備份政策

熱備甚至冷備

    在資料遷移之前進行完整的備份，一定要是全量的。甚至在允許的情況下做冷備都可以。資料的備份越充分，出現問題時就有了可靠的保證。

lob資料類型的備份，做表級的備份（create table nologging....)

    對于lob的資料類型，在使用imp,impdp的過程中，瓶頸都在lob資料類型上了，哪怕表裡的lob資料類型是空的，還是影響很大。

    自己在做測試的時候，使用Imp基本是一秒鐘一千條的資料速度，impdp速度有所提升，但是parallle沒有起作用，速度大概是1秒鐘1萬條的樣子。

    如果在資料的導入過程中出了問題，如果有完整快速的備份，自己也有了一定的資料保證，要知道出問題之後再從備份庫中導入導出，基本上都是很耗費時間的。

3)網絡

   網絡帶寬

    網絡是很重要的一個因素，資料遷移的時候肯定會從别的伺服器中傳輸大量的檔案,dump等，如果網絡太慢，無形中就是潛在的問題。

可以使用scp來進行一個簡單的測試，如果存儲還不錯的話，一般在50M左右/每秒 的速度

   網絡臨時中斷

網絡的問題需要格外重視，可能在運作一些關鍵的腳本時，網絡突然中斷，那對于更新就是災難，是以在準備腳本的時候，需要考慮到這些場景，保留完整的日志記錄。

可以使用nohup來做外背景運作某些關鍵的腳本。這樣網絡斷了以後，還有一線希望。

4）完整的日志

在資料遷移，資料更新的時候，一定要保留完整的日志記錄，這樣如果稍候有問題，也可以及時查驗，也可以避免很多不必要的紛争。如果有争議，可以找出日志來，一目了然。

5）存儲

存儲也是很重要的一個方面。從系統角度來考慮，需要保證io的高效性。可以使用iostat,sar等來評估

還可以使用如下的腳本簡單來測試一下。

time dd if=/dev/zero bs=1M count=204 of=direct_200M

6）歸檔空間

資料遷移的時候會有大量的日志産生，一定需要保證歸檔空間足夠大，及時的轉移歸檔檔案。排除歸檔爆了以後資料的問題，使用sqlloader,impdp等資料遷移政策的時候，如果歸檔出了問題，是很頭疼的問題。

7）表級nologging

如果條件允許，可以考慮對一些相關的表開啟nologging，在資料遷移之後再設定logging.

對速度有一些的提升，如果使用insert /*+append */的時候，那速度就很明顯了。

8）index級nologging

資料的insert操作，如果沒有index速度很有成倍的提高，但是在生産中可能并不能建議這麼做，如果重建索引的時候，也需要一定的時間，還需要一定保證索引和之前一定要沒有任何的差錯。是以一般來說，如果開啟Index的nologging也會有一定的提升。

9）lob級nologging

對于lob資料類型來說，在允許的條件下，可以設定為nologging，速度會有所提升。

10）foreign key

外鍵的影響需要重視，如果外鍵存在對于資料的插入順序無形中對會有一定的限制，是以在大批量的資料并發插入條件下，disable foreign key，可以更加高效，當然在enable foreign key的時候需要花費一些時間，做為資料檢查。

11）trigger的影響

tigger在資料的dml操作中都有這潛移默化的影響，是以對于trigger最好和開發部分做确認，是否需要禁用trigger

12）materialized view log的影響

有些外部系統可能為了資料同步，可能會在系統中建立一些物化視圖日志，可以和他們做一個确認，删除物化視圖日志，減少資料插入的時候物化視圖日志的影響，

還有一個問題就是物化視圖日志會使rename table等操作無法進行。

13）godlengate的影響

goldengate的影響不容小視，需要和部分做一個确認在資料遷移之前停掉goldengate相關的程序。

14）主鍵沖突資料排除

主鍵沖突資料的排查是一個很重要的環節，如果之前的準備工作不到位，到了生産之後，那就是資料災難。大半夜修複資料的痛苦真是不言而喻啊。如果資料前一部分不給力，你就得給力，想想辦法來排查吧。

15）constraint級的資料不一緻

這種問題存在而且很隐蔽，比如如下的錯誤。就是not null constraint在源schema中不存在，在導入目标庫的時候出問題了。

cannot insert NULL into

("xxxx"."test_data"."TOT_OBLIGATION_PCT")

對于這類問題需要和資料遷移組協調，盡可能保證constraint的一緻性。

16）undo的考慮

對于資料遷移來說，對于undo的空間使用來說是極大的挑戰，可能在Impdp的時候出了Undo的問題，那就是極為奔潰的問題了。

還要考慮undo_retention的設定，可以在資料遷移之前可以把retention調低一些，保證undo的使用率足夠用