海量資料遷移之一個誤操作的問題總結

在生產環境中的資料遷移還是很驚心動魄的，畢竟生產的資料不容許有任何潛在的問題，很小的問題也可能導致業務的終端，這個時候dba的角色是很重要的，如果dba犯了一個很細小的問題，在海量資料遷移中可能會導致災難性的結果，所以今天和大家討論一下關於由vi誤操作導致的問題及總結。
結合今天早上的例子來說明。
目前生產環境已經有大量的使用者資料了，需要從老系統遷移一批使用者資料過來，一切都在安裝好計劃進行準備和操作。我是採用了外部表的方式，把一個很大的表分為了幾十上百個外部表，採用insert方式載入的。
資料的準備工作很快就完成了，一切都在等待最後的客戶確認就準備開始執行指令碼做資料批次載入了。結果當時檢視系統資源，覺得可以把原本的10個併發程式該為12個。就簡單的改了一下指令碼。
這個時候就用vi很快的改完了，但是在資料載入的時候報了很多的錯誤，最開始以為是資料的問題，就發給資料遷移組去檢查了。自己也在同時做一些檢查，我採用了錯誤日誌的方式來忽略主鍵衝突，唯一性衝突的資料。
關於錯誤日誌的部分，可以參考資料緊急修復之啟用錯誤日誌  http://blog.itpub.net/23718752/viewspace-1192887/
但是奇怪的是，一共有5個表有資料問題，結果檢查了3個，最後都是0 rows inserted.我就懷疑是什麼地方出現問題了，資料已經載入進去了。應該是在載入第二次的時候全都失敗了。
我就開始檢查指令碼的執行歷史，沒有發現問題，最後在一個小細節上發現了問題。

在使用ls -l檢視檔案的時候，有一個很特別的檔案引起了我的注意。根據我的印象，這個檔案時在用vi編輯的時候，本來退出vi應該為:q ，結果打錯了，達成了;q 然後一不留神生成了一個;q的檔案。
-rw-r--r-- 1 produser dba    201 Oct  9 23:44 par7_tab_parall.lst
-rw-r--r-- 1 produser dba    208 Oct  9 23:44 par8_tab_parall.lst
-rw-r--r-- 1 produser dba    198 Oct  9 23:44 par9_tab_parall.lst
-rw-r--r-- 1 produser dba    341 Oct  9 23:46 ;q
-rw-r--r-- 1 produser dba 135337 Oct 10 00:34 split_par_10_appendata.log
-rw-r--r-- 1 produser dba 116826 Oct 10 00:26 split_par_11_appendata.log
-rw-r--r-- 1 produser dba 113885 Oct 10 00:56 split_par_12_appendata.log
-rw-r--r-- 1 produser dba 169947 Oct 10 00:39 split_par_1_appendata.log
-rw-r--r-- 1 produser dba 143857 Oct 10 00:09 split_par_2_appendata.log
-rw-r--r-- 1 produser dba 124105 Oct  9 23:59 split_par_3_appendata.log
-rw-r--r-- 1 produser dba 114643 Oct 10 00:49 split_par_4_appendata.log
-rw-r--r-- 1 produser dba 143102 Oct 10 00:18 split_par_5_appendata.log
-rw-r--r-- 1 produser dba 141416 Oct 10 00:32 split_par_6_appendata.log

最後在不經意中檢視這個檔案的時候卻執行了檔案的內容。

檢視命令歷史的時候發現這個命令觸發了兩次。
  281  nohup ksh  tmp_split_par_6_appendata.sh   > split_par_6_appendata.log    &
  282  nohup ksh  tmp_split_par_7_appendata.sh   > split_par_7_appendata.log    &
  283  ksh check.sh|grep process
...
  295  ksh check.sh|grep process
  296  nohup ksh  tmp_split_par_7_appendata.sh   > split_par_7_appendata.log    &
  297  ksh check.sh|grep process
  298  ksh check.sh|grep process

找到問題的來源了，就可以確定問題的影響範圍了，透過錯誤日誌對資料進一步進行了檢查，發現資料沒有問題了。
對於這個問題的總結由以下幾點：
首先儘量不要在生產環境進行指令碼的修改，不要在生產環境中隨意測試指令碼，以免不必要的麻煩。這個需要準備工作要更加的充分。
對於資料的匯入中，個人建議還是保留主鍵和唯一性約束，這樣可以避免很多資料的誤操作帶來的大問題。如果資料匯入出現問題，要麼是約束無法enable，要麼主鍵無法建立，而且越是大的表在建立索引的時候也是需要一定的時間的，如果涉及的表有上百個，不能保證你的操作完全沒有問題。可能幾個表出現問題就需要花費較多的時間來修復。
對於日誌的記錄還是建議能夠儘量的全面和完整，有些系統升級甚至有截圖之類的，都可以參考，在發生問題之後，能夠很快的定位和總結，避免之後再犯。
在資料的遷移之前，對資料的條數進行一個完整的統計，在資料遷移完成之後再進行一個統計，保證沒有資料條數不一致的情況。
不管怎麼樣，誤操作是系統升級成敗的關鍵，在發生誤操作之後需要冷靜，認真的分析問題的原因。可能有些問題還真不是問題，儘量不要著急開始做決定，以免問題雪上加霜。
最後經過確認，這個問題沒有造成影響，資料的條數都是完全匹配的。下次注意。