海量資料遷移之sqlldr和datapump的缺點分析

在資料遷移中，sql*loader和datapump總是作為一些常用的資料遷移方案，自己在經歷了一些專案之後，優點就不說了，說點這些方案的缺點，批評不自由，則讚美無意義，所以我在提出了一些失敗錯誤的經驗後，會在下一篇中給出這些缺點的解決方案。畢竟解決問題才是最重要的。
使用sql*loader的缺點
    可能存在潛在的亂碼問題，尤其是對於特定字符集的資料，因為sqlldr可以從客戶端匯出，如果客戶端的語言設定不當，匯出的檔案會有亂碼的隱患。
   資料問題，這個是sql*loader使用比較頭疼的地方，因為這種載入方式老是感覺比insert的方式差一點，一旦出現錯誤，可以使用sql*loader提供的特定的介面來對檔案修改後，重新部署。       
    對於lob資料的使用不夠方便
        如果表中含有clob,blob列，那麼使用sql*loader時比較麻煩的，儘管官方說是可以支援的，我看了下繁瑣的文件就準備放棄了。
    主鍵衝突 
    ORA-00001: unique constraint (PRDAPPO.AR1_MEMO_PK) violated 
    這種錯誤很明顯是由於存在主鍵衝突的資料導致的。可能表中已經含有一部分資料，再插入一部分資料的時候，結果出現了主鍵衝突。
    外來鍵資料問題/表插入資料的順序
    ORA-02291: integrity constraint (PRDAPPO.CH_OBJECT_ATTRIBUTES_1FK) violated 
   這種問題比較糾結，主要是由於匯入表的順序不當導致的。
    非空約束問題
    ERROR at line 3: ORA-29913: error in executing ODCIEXTTABLEFETCH callout ORA-01400: cannot insert NULL into ("PRDAPPO"."CL9_CRD_MNTR_TREAT"."ACT_RSN_CODE")
    這種問題比較少見，但是確實存在，如果某些欄位的約束不一致，很可能會出現這種問題。
使用Datapump的缺點
    約束導致的匯入回退
    ORA-31693: Table data object "PRDAPPO"."MO1_MEMO":"PMAX_AMAX_EMAX" failed to load/unload and is being skipped due to error: ORA-00001: unique constraint (PRDAPPO.MO1_MEMO_PK) violated Job "PRDAPPO"."SYS_IMPORT_FULL_01" completed with 1     error(s) at 02:34:33
   使用datapump比較最怕的就是等待了個把小時，最後dump檔案報錯回退了，對於約束的問題，可以使用impdp的選項  DATA_OPTIONS=SKIP_CONSTRAINT_ERRORS來匯入沒有問題的資料。
    undo的困擾
     ORA-31693: Table data object "MIG_TEST"."MO1_MEMO":"P2_A1000_E3" failed to load/unload and is being skipped due to error: ORA-29913: error in executing ODCIEXTTABLEFETCH callout ORA-30036: unable to extend segment by 8 in undo tablespace     'UNDOTBS1'
     如果表足夠大，幾十G，上百G，恰好你的undo大小也在幾十G，那麼很有可能會出現undo資源不足。這個時候你都不知道該怎麼繼續了。
資源的相互制約
   有些專案中，可能同時使用sql*loader和datapump，一旦這種情況發生，sqlldr和datapump就會互相制約，儘可能多的佔用資源，對效能還是有一定的影響。