以直接模式运行的Oracle SQL*加载程序比传统路径加载慢得多

Question

在过去的几天里,我一直在使用Oracle的SQL*Loader来尝试将数据批量加载到Oracle中.在尝试了不同的选项组合后,我惊讶地发现传统的路径负载比直接路径负载运行得快得多.

关于这个问题的一些事实:

• 要加载的记录数为60K.
• 加载前,目标表中的记录数为7亿.
• Oracle版本是11g r2.
• 数据文件包含日期,字符(ascii,无需转换),整数,浮点数.没有blob/clob.
• 表由哈希分区.散列函数与PK相同.
• 表的并行设置为4,而服务器有16个CPU.
• 索引是本地分区的.索引的并行(来自ALL_INDEXES)是1.
• 目标表上只有1个PK和1个索引.使用索引构建PK约束.
• 检查索引分区显示分区之间的记录分布非常均匀.
• 数据文件是分隔的.
• 使用APPEND选项.
• 通过SQL选择和删除加载的数据非常快,几乎是即时响应.

使用传统路径,加载在大约6秒内完成.

对于直接路径负载,加载大约需要20分钟.最糟糕的运行需要1.5小时才能完成,但服务器根本不忙.

如果启用了skip_index_maintenance,则直接路径加载将在2-3秒内完成.

我已经尝试了很多选项,但它们都没有给出明显的改进......难以置信,分类索引,多线程(我在多CPU服务器上运行SQL*Loader).他们都没有改善这种情况.

这是在SQL*Loader以直接模式运行期间我一直看到的等待事件:

• 事件:db文件顺序读取
• P1/2/3:文件#,块#,块(从dba_extents检查它是一个索引块)
• 等待类:用户I/O.

有没有人知道直接路径加载出了什么问题？或者有什么我可以进一步检查,以真正挖掘问题的根本原因？提前致谢.

Answer 1

我猜你是这个的落脚鸡

“将相对较少的行加载到大型索引表中时

在直接路径加载期间，现有索引在与新索引键合并时会被复制。如果现有索引非常大并且新键的数量非常少，那么索引复制时间可以抵消直接路径加载节省的时间。”

从何时使用常规路径加载：http://download.oracle.com/docs/cd/B14117_01/server.101/b10825/ldr_modes.htm