Question

假设我有一组ID。对于每个ID，我将根据ID在许多不同的表中插入许多记录。在插入差异表之间，将调用不同的业务检查。如果任何检查失败，则基于此ID插入的所有记录都将是ROLLBACK。此批量插入操作是通过使用PL / SQL完成的。 COMMIT和ROLLBACK的时间是否影响性能以及它如何影响？例如，在完成所有ID后，我应该在完成一个ID或COMMIT的过程后进行COMMIT吗？

Answer 1

这不仅仅是一个绩效决策，而是一个流程设计决策。当您必须回滚有故障的ID时，是否希望其他ID保留在数据库中？

由于显而易见的原因，当必须回滚更多行时，回滚需要更长时间。回滚通常需要比必须回滚的操作更长（有时更长！）。在Oracle中提交总是很快，因此在这方面提交的频率可能并不重要。

Answer 2

您的问题描述表明您有一大组较小的逻辑事务（每个新ID都是一个事务）。您应该提交每个逻辑事务。等待提交整组交易的两个原因是：

如果整个事务集实际上是事务本身 - 所有插入都必须成功才能提交任何行。在这种情况下，您较小的“交易”不是真正的交易。
批量加载过程中没有重新启动功能，这实际上使这成为第1项的特殊情况。如果批量加载过程中止，则需要一种方法来跳过成功应用的ID。

Tom Kyte的建议是提交每个逻辑工作单元 - 交易。

Answer 3

不要延长交易时间。尽可能缩短它。因为根据您的查询，已经创建了一些锁。这种锁定可能会导致性能问题...... ID ID也是如此......

Answer 4

有两种“力量”在起作用......

锁定在打开事务期间，oracle会对更改的行进行锁定。每当另一个事务需要更新任何锁定的行时，它必须等待。在最坏的情况下，你甚至可以建立一个僵局。
同步写入每次提交都执行同步写入。（有一些方法可以禁用它，但通常是每个人都想要的东西：完整性）。同步写入可以比常规写入（可以缓冲）花费更长时间。不要忘记，提交通常会涉及额外的网络往返。

所以，一支部队说“尽快提交（考虑到你的诚信要求）”另一部队说“尽可能少地提交”。

还有一些其他问题需要考虑，例如最大交易规模。每个未通信的交易都需要一些临时空间。交易越大，您需要的就越多。你也可以遇到ORA-01555“快照太旧”。

如果有任何建议，那就是实现可配置的“提交频率”，以便您可以根据需要轻松更改。

Answer 5

如果您需要控制各个集但保留提交或回滚整个事务的能力，则可以使用保存点。您可以在最外层循环的开头设置一个保存点，然后在发生错误时回滚到它。你最终会得到这样的东西：

begin
   --Initial batch logging
   for r_record in cur_cursor loop
      savepoint s_cursor loop;
      begin
         --Process rows
      exception
         when others then
            rollback to s_cursor;
      end;
   end loop;
   --Final batch logging
exception
   when others then
      rollback;
      raise;
end;

COMMIT和ROLLBACK的时间会影响性能吗？

5 个答案: