最近根据业务需要加载一批数据，在生产环境中不到半个小时就完了，可是到了测试环境，竟然跑了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 )

查看要加载的数据文件，内容如下，数据信息也没有什么特别的地方。

sqlldr <USER>/<PSW>@<INSTANCE> <uh_ctrl_GD1_XXXX.ctl> DATA=<UH_CRT_GD_XXXX_DDMMYY_HHMISS> DISCARD=GD1_XXXX.dsc SILENT=FEEDBACK ERRORS=499 LOG=log_GDY_XXXX.log BAD=bad_ORA_FULL_GDY_XXXX_<YYMMDD>.<HHMISS>.dat rows=1000有了以上的信息，就可以从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.18test.data 0% 288KB 153.3KB/s 0.0KB/s 22:10 ETA^

test.data1 0% 1232KB 22.4KB/s 32.0KB/s 4:35:24 ETA有了这些信息，之前的纷争一下子就清晰了很多。测试环境在基本类似的情况下，速度那么慢，根源就在于网络。尽管服务端，客户端的cpu,io,缓存等配置都类似，但是速度就卡在了网络了。想象也是，可能有些复杂的问题的原因其实很简单。