海量數據遷移之誤操作和防範建議

在生產環境的數據遷移中，發生誤操作真是很不願意看到，今天自己總結了一下，從個人的經驗來看有以下的幾種操作或者是失誤導致的問題。有一些錯誤自己已經犯過。

外鍵
不管是使用imp/impdp,sqlldr還是使用Insert append的方式導入數據，如果存在外鍵的約束，在數據導入前最好都設置爲disable,要不數據導入的時候很可能發生衝突，因爲批量的數據導入很可能開啓多個併發進程，如果你不能完全控制導入的先後順序，最好還是disable掉。

觸發器
觸發器在數據導入前最好和開發組確認，如果忽略了這個潛在問題，很可能在數據導入之後，會多出來一部分的數據，而且從日誌中沒有任何錯誤。

密碼的設置
爲了杜絕在多個環境中切換帶來的問題，最好在一些登錄密碼的設置上進行嚴格控制，如果你一邊連着測試環境，一邊開着生產環境的窗口，不小心把環境混淆的情況下，那就是數據災難了，而且個人的建議都是通過一些工具，都不要保存密碼，這樣會提醒你到底連入的是什麼環境。

創建臨時賬戶
在數據遷移的時候，如果表的數據都在某一個schema下，個人建議最好創建一個臨時的schema，給這個臨時的schema賦予指定的權限，比如數據抽取的臨時schema只賦予select權限，對於數據加載的臨時schema，則只賦予insert的權限。如果你不管三七二十一，在源schema裏面做所有的操作，很容易犯低級錯誤。一旦發生問題，那也是不可挽回的。

關於命令的歷史
如果你已經習慣使用ctrl+p，或者上下箭頭來運行歷史命令，自己不想敲命令的話，一定要小心，
可能上一個命令是nohup命令，那麼你一旦操作過快，急急忙忙敲回車的話，也是很嚴重的問題。


vi可能導致的問題
vi本身不是問題，但是個人建議vi的改動最好還是儘量在另外一個目錄下備份一份，改動完成之後從另外的目錄copy過來。這樣一旦發生問題也能知道是不是改動導致的。

回車和空格
如果你接入一個環境，呈現在你面前的是一個空屏幕，這個時候不要隨意按回車鍵，保守的方式就是空格鍵，看看是否是光標顯示不夠完整，有很多時候都是顯示的不夠完整，但是可能命令已經通過歷史記錄給調出來了。隨意按了回車，就是可能的災難。

數據備份
數據的備份，這個從系統級，數據庫級，表級都可以做一些工作。我在這所說的數據備份，可能更側重於說表級的備份，如果有足夠的空間，可以考慮對很關鍵數據量大的表做表級備份，如果只是做了exp/expdp的備份，那麼一旦出現問題，你還需要大量的時間和系統資源去導入到一個臨時的schema或者其他的地方，這個就耗時費力了。可以使用create table xxx nologging的方式，如果表很大，加個並行還是比較快的。

遷移方式
這裏想說說大家常用的遷移方式，可能數據量小的時候，使用imp/impdp就可以，數據量稍大一些，impdp或者sqlldr就可以，如果數據量更大，就可以考慮sqlldr或者外部表了。
個人的感覺來說imp/impdp/sqlldr都屬於物理級的數據加載，外部表的數據加載纔是邏輯級別的。
舉幾個場景，
如果表很大的情況下，impdp的導入會耗費很多的資源，直到數據完全導入，纔是釋放Undo資源，一旦發生問題，比如undo資源不足，就會直接報錯，這個時候可能會耗費很多的時間和資源。
在數據導入之前，你不可能從imp/impdp的dump文件中查看到表的數據，如果發生數據衝突，也是在數據導入的時候纔可能發現,sqlldr可能還可以查看一部分數據，但是不夠直觀，數據都是行列形式的文件，你不能通過sql語句等形式來檢查數據。如果有數據問題，也是在數據導入的過程中才可能發現。
即使你想對數據進行預檢查，那麼你可能得用Impdp或者sqlldr的形式把數據先加載到一個臨時的用戶下，那麼問題就來了，你得準備足夠多的空間資源，而且導入的過程中隊系統負載也是很大挑戰。在這一點是外部表要更勝一籌，無須準備額外的空間，外部表就更創建一個同義詞的感覺一樣，加載卸載都是很快的，秒級別的操作。

唯一性約束和主鍵
如果你在考慮性能的時候，在數據導入前刪除了主鍵和唯一性約束，那麼如果存在數據衝突，或者誤操作導致數據加載了多次的時候，你就給自己挖了一個坑，到時候出現問題，很難從頭查起。個人建議還是保留唯一性約束和主鍵，儘管性能會打折扣但是也是值得的付出。

網絡中斷
這個問題自己碰到過幾次，如果腳本在運行的過程中發生網絡中斷，你就會馬上崩潰了。這個時候還是保守一些，一些腳本的運行還是考慮使用nohup的形式來。
要不中途發生問題，你都不知道該從哪開始繼續。

磁盤空間不足
如果數據導入的過程中發生空間的問題，使用sqlldr的時候你就得仔細的查看日誌文件，慢慢一個一個修復吧。最好還是給30%左右的buffer,別自己爲難自己。
如果使用外部表的話，可能會有大批的外部表導入失敗，那麼你就得查看日誌，慢慢的手動修復。如果問題比較多，那工作量可想而知。