在生產環境的資料遷移中，發生誤操作真是很不願意看到，今天自己總結了一下，從個人的經驗來看有以下的幾種操作或者是失誤導致的問題。有一些錯誤自己已經犯過。
外來鍵觸發器
觸發器在資料匯入前最好和開發組確認，如果忽略了這個潛在問題，很可能在資料匯入之後，會多出來一部分的資料，而且從日誌中沒有任何錯誤。
密碼的設定
為了杜絕在多個環境中切換帶來的問題，最好在一些登入密碼的設定上進行嚴格控制，如果你一邊連著測試環境，一邊開著生產環境的視窗，不小心把環境混淆的情況下，那就是資料災難了，而且個人的建議都是通過一些工具，都不要儲存密碼，這樣會提醒你到底連入的是什麼環境。
建立臨時賬戶
在資料遷移的時候，如果表的資料都在某乙個schema下，個人建議最好建立乙個臨時的schema，給這個臨時的schema賦予指定的許可權，比如資料抽取的臨時schema只賦予select許可權，對於資料載入的臨時schema，則只賦予insert的許可權。如果你不管三七二十一，在源schema裡面做所有的操作，很容易犯低階錯誤。一旦發生問題，那也是不可挽回的。
關於命令的歷史
如果你已經習慣使用ctrl+p，或者上下箭頭來執行歷史命令，自己不想敲命令的話，一定要小心，
可能上乙個命令是nohup命令，那麼你一旦操作過快，急急忙忙敲回車的話，也是很嚴重的問題。
vi可能導致的問題
vi本身不是問題，但是個人建議vi的改動最好還是盡量在另外乙個目錄下備份乙份，改動完成之後從另外的目錄copy過來。這樣一旦發生問題也能知道是不是改動導致的。
回車和空格
如果你接入乙個環境，呈現在你面前的是乙個空螢幕，這個時候不要隨意按回車鍵，保守的方式就是空格鍵，看看是否是游標顯示不夠完整，有很多時候都是顯示的不夠完整，但是可能命令已經通過歷史記錄給調出來了。隨意按了回車，就是可能的災難。
資料備份
資料的備份，這個從系統級，資料庫級，表級都可以做一些工作。我在這所說的資料備份，可能更側重於說表級的備份，如果有足夠的空間，可以考慮對很關鍵資料量大的表做表級備份，如果只是做了exp/expdp的備份，那麼一旦出現問題，你還需要大量的時間和系統資源去匯入到乙個臨時的schema或者其他的地方，這個就耗時費力了。可以使用create table *** nologging的方式，如果表很大，加個並行還是比較快的。
遷移方式
這裡想說說大家常用的遷移方式，可能資料量小的時候，使用imp/impdp就可以，資料量稍大一些，impdp或者sqlldr就可以，如果資料量更大，就可以考慮sqlldr或者外部表了。
個人的感覺來說imp/impdp/sqlldr都屬於物理級的資料載入，外部表的資料載入才是邏輯級別的。
舉幾個場景，
如果表很大的情況下，impdp的匯入會耗費很多的資源，直到資料完全匯入，才是釋放undo資源，一旦發生問題，比如undo資源不足，就會直接報錯，這個時候可能會耗費很多的時間和資源。
在資料匯入之前，你不可能從imp/impdp的dump檔案中檢視到表的資料，如果發生資料衝突，也是在資料匯入的時候才可能發現,sqlldr可能還可以檢視一部分資料，但是不夠直觀，資料都是行列形式的檔案，你不能通過sql語句等形式來檢查資料。如果有資料問題，也是在資料匯入的過程中才可能發現。
即使你想對資料進行預檢查，那麼你可能得用impdp或者sqlldr的形式把資料先載入到乙個臨時的使用者下，那麼問題就來了，你得準備足夠多的空間資源，而且匯入的過程中隊系統負載也是很大挑戰。在這一點是外部表要更勝一籌，無須準備額外的空間，外部表就更建立乙個同義詞的感覺一樣，載入解除安裝都是很快的，秒級別的操作。
唯一性約束和主鍵
如果你在考慮效能的時候，在資料匯入前刪除了主鍵和唯一性約束，那麼如果存在資料衝突，或者誤操作導致資料載入了多次的時候，你就給自己挖了乙個坑，到時候出現問題，很難從頭查起。個人建議還是保留唯一性約束和主鍵，儘管效能會打折扣但是也是值得的付出。
網路中斷
這個問題自己碰到過幾次，如果指令碼在執行的過程中發生網路中斷，你就會馬上崩潰了。這個時候還是保守一些，一些指令碼的執行還是考慮使用nohup的形式來。
要不中途發生問題，你都不知道該從哪開始繼續。
磁碟空間不足
如果資料匯入的過程中發生空間的問題，使用sqlldr的時候你就得仔細的檢視日誌檔案，慢慢乙個乙個修復吧。最好還是給30%左右的buffer,別自己為難自己。
如果使用外部表的話，可能會有大批的外部表匯入失敗，那麼你就得檢視日誌，慢慢的手動修復。如果問題比較多，那工作量可想而知。
SQL SERVER 資料誤操作的恢復
事務日誌忠實地記錄了資料庫的活動,所以基於這些記錄的活動就可以隨心所欲地將資料庫的狀態恢復到特定的即時點或故障點。事務日誌備份只能與完整恢復和大容量日誌記錄恢復模型一起使用。在簡單模型下，事務日誌可能被破壞，所以事務日誌可能不連續，不連續的事務日誌備份沒有意義，因為基於日誌的恢復要求日誌是連續的。因...
kafka訊息系統 海量資料遷移方案
由於本人主要從事大資料視覺化的工作，就少不了對海量資料的分析，但是我們並不是資料的生產 資料來自有大資料視覺化分析需求的使用者，所以實際業務中往往會遇到大量資料從傳統儲存方式 關係型資料庫 檔案儲存等 到資料倉儲的遷移，本次就以實現如何基於kafka從oracle到hive倉庫做資料的遷移工作。本次...
海量資料的操作
待續。海量資料查詢某個數 海量資料查詢中位數 同樣用二進位制數表示數字，將最高位為0的和最高位為1的數字放到兩個檔案中，假設10億個數字儲存在乙個大檔案中，依次讀一部分檔案到記憶體 不超過記憶體的限制 1gb 將每個數字用二進位制表示，比較二進位制的最高位 第32位 如果數字的最高位為0，則將這個數...