sqlldr載入效能問題的排查

最近根據業務需要載入一批資料，在生產環境中不到半個小時就完了，可是到了測試環境，竟然跑了6個多小時，另外測試環境和生產環境的資料情況都基本差不多，主機配置也基本類似。
大家的注意力都集中到了sqlldr的載入效能上。等到他們找到我時，已經討論了不少關於direct,convention載入的各種情況了，看似工作也做了不少了。

然後我透過郵件歷史記錄看到大家還討論了可能是index導致的結果。
等到郵件轉到我這的時候，已經問題算升了一個等級了。我首先要確定的就是具體的環境，在那臺伺服器上跑sqlldr,要把資料載入到哪個庫。如果在生產上半個小時，可能在環境的某些地方還是有一些差別。
首先和開發協調了下，要到了他們使用的control file和sqlldr的命令。

首先檢視control file，可以看到欄位並不多，結構也不復雜。

load data
 discardmax 999
 into table GD1_SUBSCR_KEY
 fields terminated by "!"
 TRAILING NULLCOLS
 ( RESOURCE_VALUE ,RESOURCE_TYPE,EFFECTIVE_DATE DATE(19) "YYYY-MM-DD HH24:MI:SS",EXPIRATION_DATE  DATE(19) "YYYY-MM-DD HH24:MI:SS" ,SUBSCRIBER_NO,SUB_STATUS,CUSTOMER_ID,ACTV_CODE_IND,BE,LANGUAGE CHAR TERMINATED BY '!!',ROUTING_POLICY_ID, L9_PORT_IND,L9_SPLIT_PERIOD ) 

檢視要載入的資料檔案，內容如下，資料資訊也沒有什麼特別的地方。
520002055869828!I!2014-05-06 12:19:42!4700-12-31 00:00:00!1003500!A!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-05-02 14:46:11!2014-05-06 12:19:42!1003500!A!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-05-02 12:46:07!2014-05-02 14:46:11!1003500!U!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-05-02 08:41:12!2014-05-02 12:46:07!1003500!U!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-05-02 08:31:28!2014-05-02 08:41:12!1003500!A!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-02-08 19:39:55!2014-05-02 08:31:28!1003500!A!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-02-08 19:39:52!2014-02-08 19:39:55!1003500!A!493053!!0!TH!!0!!NONE!
520002055869828!I!2014-02-08 19:35:49!2014-02-08 19:39:52!1003500!A!493053!!0!TH!!0!!NONE!

有了以上的資訊，就可以從cpu,io等方面來排查了。
首先是cpu，在目標的伺服器上面有10臺db instances,其中大部分都是在特定的應用中才用到，所以伺服器上的cpu消耗並不高。
在生產系統中，只有4臺db instances,把其它的庫都分離到別的伺服器上了。檢視cpu的負載情況，沒有太大的出入。當然了，我檢視的時候資料已經載入完成了，也不能確定當時的cpu負載情況，這個時候可以從sqlldr日誌中得到印證。載入了6個小時，cpu時間其實就是半個小時左右。這樣來說cpu導致的可能性很小。

4096786 Rows successfully loaded.

Run began on Wed Jun 11 08:52:55 2014

Run ended on Wed Jun 11 14:57:40 2014

Elapsed time was:     06:04:44.05

CPU time was:         00:00:38.18


其次從io的角度來看。可能測試環境的Io負載要略微大一些，因為有兩套環境在上面，都是使用，但是資料庫這邊來說測試環境的使用也不是很頻繁，只是例行做一些測試而已。而在生產上可能要很多線上業務需要跑一些比較大的查詢，從某種角度來說，儘管測試環境的資料庫例項多一些，但是負載還要比生產環境小一些。

關於這個可以使用sar,iostat等命令來檢視。

cpu,io都沒有問題。

看看快取，有個做效能的哥們檢視了一下快取的情況，說測試環境的paging情況比較多，建議停掉一些其他的庫來釋放掉一些快取，提高資料載入的速度，我馬上就表示反對，因為這臺伺服器有180G記憶體，每個庫的sga都基本在8G左右，所以10個庫，總共佔用的快取也在100G左右，加上一些額外的paging，因為測試環境的使用頻率不是很高。所以在快取上可能會相比生產環境要差一些，但是快取還是相對ijiao充足的。


以上的情況都排除，我來看看網路情況，因為個人也對網路不是很在手。不過可以做一些簡單的測試來印證。
首先在生產環境中做了一個scp的操作。把一個100m的檔案傳送到另一個客戶端。每秒傳送速度在50M左右，很快就完了。
然後我在測試環境做了類似的操作，把檔案從客戶端傳送到測試資料庫端。發現網路相比而言，慢了很多。
測試2個檔案，開始在150KB/秒的樣子，過了一會速度就降下來了。最低的時候再20kb左右的樣子。

test.data                                                                                                                 0%  288KB 153.3KB/s   0.0KB/s   22:10 ETA^

有了這些資訊，之前的紛爭一下子就清晰了很多。測試環境在基本類似的情況下，速度那麼慢，根源就在於網路。
儘管服務端，客戶端的cpu,io,快取等配置都類似，但是速度就卡在了網路了。想想也是，可能有些複雜的問題的原因其實很簡單。