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

在生產環境中，做資料遷移需要考慮很多的可能性和場景，儘量排除可能發生的問題。我自己總結了下，大體有如下需要注意的地方。
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的使用率足夠用