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

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

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

要加载的记录数为60K。 加载前，目标表中的记录数为7亿条。 Oracle版本是11g r2。 数据文件包含日期、字符ascii、无需转换、整数、浮点。没有滴答声。 表按哈希进行分区。散列函数与PK相同。 当服务器有16个CPU时，表的并行设置为4。 索引是局部分区的。所有_索引的索引平行度为1。 目标表上只有1个PK和1个索引。PK约束使用索引构建。 检查索引分区发现分区之间的记录分布相当均匀。 数据文件是分隔的。 使用APPEND选项。 通过SQL选择和删除加载的数据非常快，几乎是即时响应。 使用传统路径，加载大约在6秒钟内完成

对于直接路径加载，加载大约需要20分钟。最差的跑步时间为1.5小时 已完成，但服务器根本不忙

如果启用了跳过索引维护，则直接路径加载将在2-3秒内完成

我尝试了很多选择，但都没有明显的改善。。。不可恢复、排序索引、多线程我正在多CPU服务器上运行SQL*Loader。他们都没有改善这种情况

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

事件：数据库文件顺序读取 P1/2/3：文件、块、块从dba_扩展数据块检查它是否是索引块 等待类：用户I/O

---

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

我想你是对这件事掉以轻心了

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

在直接路径加载期间，当现有索引与新索引键合并时，将复制该索引。如果现有索引非常大，而新键的数量非常少，则索引复制时间可以抵消直接路径加载节省的时间

---

从何时开始在中使用常规路径加载：

您知道这种行为只发生在SQL加载程序中，还是与insert append的行为相同？我做了一个非常快速的测试，当我用append提示插入100行时，它似乎没有复制我现有的92Meg索引。我不知道，我猜如果你尝试插入append 60k行，它将显示相同的行为。当我浏览SQL*Loader的文档时，我完全错过了那个部分。但是，将大量数据加载到具有相对大量记录的非空表中的最佳方法是什么呢？好问题，我认为将数据并行加载到正确的分区中是最快的方法，因此这个问题是相关的。