提交和回滚的时间会影响性能吗?

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

2. 在批量加载过程中没有重新启动功能,这实际上使它成为第1项的特例。如果批量加载过程中止,则需要一种跳过成功应用的ID的方法。

tomkyte的建议是提交每个逻辑工作单元-事务。

这与其说是一个性能决策,不如说是一个流程设计决策。当您必须回滚错误的ID时,是否希望其他ID保留在数据库中?

由于显而易见的原因,当必须回滚更多行时,回滚需要更长的时间。回滚通常需要更长的时间(有时需要更长的时间!)而不是必须回滚的操作。在Oracle中,Commit总是很快的,所以在这方面你多久提交一次可能并不重要。

不要把交易时间拖得太长。尽量简短。因为根据你的查询,已经创建了一些锁。此锁可能会导致性能问题。。。所以一个接一个。。。

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

1. 锁定 在打开的事务期间,oracle会对更改的行进行锁定。 每当另一个事务需要更新任何锁定的行时, 它必须等待。 在最坏的情况下,甚至可以构建死锁。

2. 同步写入 每次提交都执行同步写入。 同步写入可能比常规写入(可以缓冲)花费更长的时间。 不要忘记,提交通常会涉及额外的网络往返。

还有一些其他问题需要考虑,例如最大事务大小。每个未限制的事务都需要一些临时空间。交易越大,你需要的就越多。您还可以运行ORA-01555“snapshot too old”。

如果有任何建议可以给出,那么就是实现一个可配置的“提交频率”,以便您可以根据需要轻松地更改它。

如果您需要控制单个集合,但保留提交或回滚整个事务的能力,则可以使用保存点。您可以在最外层循环的开始处设置保存点,然后在发生错误时回滚到该保存点。你可能会得到这样的结果:

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;