如果在数据库级别启用了强制日志记录，如何在数据库上使用直接路径插入？

Question

在我们的DWH数据库中，每天在ETL过程中我们尽可能使用直接路径插入来加速加载操作。我们有两种主要方法：

1. 当我们从源表中批量收集到 v_row 100 000 行后将数据插入到整个表中时：

forall i in v_row.First .. v_row.Last
          insert /*+ APPEND_VALUES */ into   ibs.'||i_table_name||'
          values v_row
          (i); 
commit;

2. 当我们有一个大表时，我们将加载过程分为多个作业，这些作业将按分区键列从源表加载数据并插入到目标表分区中：

forall i in v_row.First .. v_row.Last
                insert /*+ APPEND_VALUES */ into   ibs.'||i_table_name||' partition('|| l_part_name || ')
                values v_row
                (i);
commit;

从逻辑上讲，这些操作应该有助于改进 dml 操作。但是，我了解到在我们的数据库中，在数据库级别启用了强制日志记录。所以我的问题是，如果强制日志记录打开，使用直接路径插入有什么意义吗？如果强制日志记录取消了直接插入操作的所有好处，那么还有什么可以替代它们？

Answer 1

强制日志记录仅要求将所有块更改记录到重做日志中以实现可恢复性，如果数据库在内存更改写入磁盘之前崩溃，或者文件已损坏且 DBA 需要恢复到之前的时间点。如果没有强制日志记录，if 暗示绕过日志记录 (

NOLOGGING

)，或者如果正在修改的表本身标有

NOLOGGING

属性，则直接路径 DML 操作的更改不会写入重做日志。由于重做日志会施加惩罚和某些类型的序列化（过去比现代版本更严重），因此这可以显着加快直接路径操作的速度。但更重要的是，它创建的归档日志更少，这些日志必须发送到备份设备并占用（大量）空间。如果主要模式是定期截断并重新加载或删除并 CTAS（其中段不断从头开始重建），则这一点尤其引人注目。但危险在于，如果需要恢复，您将完全丢失表的内容，或者至少会丢失自上次完整备份以来的内容。因此，当数据需要保护时，切勿使用它。将其用于临时工作和摘要/衍生品，可以轻松地从其他权威来源重新创建。

但即使发生日志记录（传统 DML 总是发生），直接路径仍然非常启用和有用。直接路径绕过共享内存中的缓冲区高速缓存以及保护它的所有附带并发机制，并直接私下读取/写入磁盘。直接路径插入还绕过在可用空间位图中查找要重用的空块，并简单地从以前未分配的空间中分配全新的范围，这些空间专用于插入过程而不是共享（直到提交）。这也确实加快了插入速度。所以不，您不会仅仅因为启用了强制日志记录而丢失直接路径。