sqlldr和oracle_datapump效能比較

針對之前在生產環境中使用sql*loader的效能問題，最近一直在想使用外部表的oracle_datapump來替代它。
昨天下午做了大量資料的測試，比較了這兩種方案。最後發現在一定的限定條件下，從很多細節來看 oracle_datapump要更勝一籌。
首先使用sql*loader對於clob,blob的資料相比普通表的處理要一些額外的工作，但是這些限制或者額外工作再oracle_datapump中就可以很方便的使用，oracle_datapump支援的資料型別要更豐富。

在生產環境中，遷移資料的時候，只是對於foreign key做了disable的操作，對於其他的constraint都做了保留，沒有任何其他的操作，所以使用sql*loader 的direct選項就有很多的限制和無法實現的苦衷。在表級都設定了nologging。
--》資料抽取
以下是使用sql*loader和oracle_datapump的一些效能比較。資料量在120-150G左右。
使用sql*loader的時候因為有2張表含有clob欄位，所以就先沒有處理，以此來對比oracle_datapump的速度。
可以看到sqlldr的速度做資料抽取大概耗費了14分鐘，而且不包括2張含有clob的表，生成的dump檔案有150G
           oracle_datapump的速度要更快一些。只耗費了大概3分鐘左右,生成的dump檔案要更加精簡。
當然了sqlldr可以使用客戶端來抽取資料,而oracle_datapump只能基於服務端，靈活性上sqlldr要好一些。

	extract  start time	extract  end time	Duration	Dump_generated
sqlldr(exclude 2 tables)_68 tables	Tue Jul 15 13:28:15 ICT 2014	Tue Jul 15 13:42:32 ICT 2014	14 mins	150G
EXT_DATAPUMP   70 tables	Tue Jul 15 14:03:11 ICT 2014	Tue Jul 15 14:06:20 ICT 2014	3 mins	59G

--》資料載入
資料抽取的速度其實不是關鍵，很多工作可以在升級之前完成，對於系統的影響倒不是很重要，關鍵在於資料的載入速度。
可以看到採用sqlldr載入資料的時候，啟用了150個並行執行緒，sqlldr開啟了並行。耗費了大約80分鐘，產生的日誌資料量也不少有，230G左右。
而oracle_datapump的表現在這方便確實更勝一籌，啟用了4個session，每個session啟用並行度為8來做資料的載入，載入速度要快一倍以上。而且產生的日誌資料量也少了將近一半。

	data loading  start time	data loading   end time	Duration	archive_logs_generated
sqlldr(exclude 2 tables)_68 tables	Tue Jul 15 14:24:24 ICT 2014	Tue Jul 15 15:44:04 ICT 2014	80 mins	230G
EXT_DATAPUMP   70 tables	Tue Jul 15 17:06:51 ICT 2014	Tue Jul 15 17:50:04 ICT 2014	44 mins	139G

--》資料校驗
在資料校驗方面，sqlldr就沒有任何可行的方法來比較冗餘資料了，在這方面，oracle_datapump可以根據生成的dump檔案建立外部表，不耗費額外的表儲存空間，在這個基礎上，直接可以對外部表和目標表進行比較。在資料載入之前找到可能出現的潛在問題。

--》資料糾錯
在資料糾錯方面，sqlldr提供了完整的處理機制，如果資料不符合要求被reject，可以生成對應的錯誤檔案，裡面包含所有被拒的資料，可以再次使用sqlldr來載入。
但是對於oracle_datapump來說，只能到這裡了。不過在資料庫層面還有其他可行的方式，比如採用error log就可以得到出錯的資料進行排錯。