生產環境資料遷移問題彙總

kingsql發表於2014-09-11
在測試環境中做了3輪資料遷移的演練，最終到了生產環境中，還是出現了不少問題，經過大半夜的奮戰，終於是資料都遷移成功了。
1）共享儲存的配置問題
共享儲存使用NFS來共享儲存，但是在實際操作中發現配置出了問題，原因是因為兩臺伺服器上的使用者不同在，目標機器上沒有任何寫許可權。
-rw-r--r-- 1 3160 dba      6608 Jun 26 23:35 tmp_gunzip.sh        
-rw-r--r-- 1 3160 dba       624 Jun 26 23:30 tmp_gzip.sh          
oraccbs1@ccbdbpr3:/ccbs/migration/ext_datapump/DUMP> ksh gunzip.sh
gunzip.sh[1]: tmp_gunzip.sh: cannot create [Permission denied]    
最終還是採取了保守的方式，使用scp來傳輸檔案。壓縮檔案後，檔案的大小還是可以接受的。而且可以在資料遷移之前完成，雖然在稍後更正了nfs的配置，還是保守的使用了本地檔案。

2）人為失誤，遺漏了指令碼
在資料遷移之前執行了一些指令碼來設定table nologging,index nologging,disable trigger..結果把最重要的foreign key的指令碼給遺漏了，結果在使用sqlldr載入資料的時候reject了部分的資料。
幸虧及時發現。趕緊執行disable的指令碼，報瞭如下的錯誤，好吧，對於已經收影響的資料來說，只能透過.bad檔案來逐一恢復資料了。
不過個人總結還是覺得對於異常情況的考慮需要需要比較充分，在出問題的時候才不會亂了陣腳。

ALTER TABLE xxxx DISABLE  CONSTRAINT xxxxx_ACCOUNT_1FK
            *
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

ALTER TABLE xxxx_ACCOUNT disable  CONSTRAINT xxxx_ACCOUNT_1FK
            *
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired
最後使用如下的指令碼來修復，收到影響的檔案有70多個，大半夜修復資料真是壓力和痛苦啊。不過還好，資料都最後成功載入了。
 #sqlldr xxxx/xxxx@xxxxcontrol=./TEST_LOG/TEST_BEN_sqlldr.ctl log=./TEST_LOG/Imp_sqlldr_TEST_BEN_10.log  direct=false parallel=true errors=10000000 bindsize=7500000 readsize=7500000 streamsize=7500000 rows=50000 data=./TEST_DUMP/TEST_BEN_10.dat  discard=./TEST_LOG/TEST_BEN_10.di                                                                                                                                                                                                                            
3)記憶體導致的問題
在資料載入的過程中，cpu使用率一直上不去，開啟了150個並行的insert程式，但是cpu使用率還是在90%左右，速度上不去。這和之前在測試環境的測試結果又很大的出入。
180G的記憶體，但是剩餘記憶體卻只有400多M
 top - 03:48:47 up 413 days, 57 min, 11 users,  load average: 7.22, 8.40, 8.79
Tasks: 1906 total,   1 running, 1905 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.4%us,  0.6%sy,  0.0%ni, 98.9%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:  189675188k total, 189233496k used,   441692k free,    30368k buffers
Swap: 377487328k total,    25844k used, 377461484k free, 117830432k cached
根據我的監控，發現對於大的分割槽表來說，剩餘記憶體就耗盡了。並行插入資料的時候遇到了瓶頸，可能和生產庫沒有開啟非同步io有關,資料庫引數為filesystem_io,當前設定為none,而在測試環境中則為setall.
而且根據我的觀察Undo的使用率極高，按照之前的統計資料來說不會這麼異常。

4）升級的過程中環境非法訪問
按照約定，在升級的過程中，環境是不允許開發訪問的，但是在這次資料遷移中，發現有一些資源消耗比較的sql語句都是從客戶端發過來的。經過確認是客戶的卡發人員想查驗數據遷移的情況，這個會對資料的遷移造成一定的影響。可以透過修改資料庫listener的埠號來進行遮蔽，在資料遷移完成之後，在修改埠重啟監聽即可，對於外部來說，就可以排除不必要的影響

5)統計資訊的收集
資料遷移之後，統計資訊的收集也是一個很關鍵的步驟，如果不進行統計資訊收集，會導致執行計劃有較大的誤差。可能導致嚴重的效能問題。
但是生產系統中時間是最高貴的資源。收集統計資訊會耗費不少的時間，這個時候可以根據表的大小來進行統計資訊比例的調整。對於比較大的表來說，比例可以在40%左右，開啟並行，速度會有一定的提升。

6）外部表載入的效能問題
在之前的測試中，外部表載入的效能還是不錯的，但是在生產中發現速度一下子打了折扣，本來一分鐘150萬的資料載入速度。結果在生產中大概在4，5分鐘的樣子（150萬條資料）
對於這個問題，可能還需要考慮並行的情況。因為cpu的使用率一直沒有上去。需要考慮稍後抓取ash報告來查驗當時倒底有哪些瓶頸。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28389881/viewspace-1267550/，如需轉載，請註明出處，否則將追究法律責任。

相關文章