COMMIT/ROLLBACK VS ROLLBACK TO SAVEPOINT 的批处理 DB2 性能

Question

在 COBOL 批处理程序中，性能方面哪个更好？

随着提交：

IF SW-NEW-TRANSACT
  EXEC SQL
      COMMIT
  END-EXEC
END-IF.
PERFORM SOMETHING
   THRU SOMETHING-EXIT.
IF SW-ERROR
  EXEC SQL
      ROLLBACK
  END-EXEC
END-IF.

使用同步点：

IF SW-NEW-TRANSACT
  EXEC SQL
      SAVEPOINT NAMEPOINT ON ROLLBACK RETAIN CURSORS
  END-EXEC
END-IF.
PERFORM SOMETHING
   THRU SOMETHING-EXIT.
IF SW-ERROR
  EXEC SQL
      ROLLBACK TO SAVEPOINT NAMEPOINT
  END-EXEC
END-IF.

Answer 1

SAVEPOINT 和 COMMIT 不可互换。

进程总是必须在某个时刻提交或回滚数据库工作。COMMIT在事务之间（在完整的工作单元之间）进行。COMMIT 可以在每个事务之后执行，或者在批处理中很常见，在多个事务之后执行。永远不应该在事务中间进行提交（这违背了工作单元的概念）。

SAVEPOINT 通常在单个工作单元中获取并可能释放。SAVEPOINT 应始终在完成一个工作单元后释放。它们总是在 COMMIT 时被释放。

SAVEPOINT 的目的是允许从工作单元内部分退出。当一个进程以一系列常见的数据库插入/更新开始，然后是一个进程分支时，这很有用，在该进程分支中可能会执行一些更新，然后才能确定应该执行替代进程分支。SAVEPOINT 允许退出“死胡同”分支，然后继续使用备用分支，同时保留常见的“前期”工作。如果没有 SAVEPOINT，退出“死胡同”可能需要在事务中进行大量数据缓冲（复杂处理）或 ROLLBACK 并从事务开始重新执行，并使用某种标志指示替代流程分支需要被关注。所有这些都会导致复杂的应用程序逻辑。回滚到 SAVEPOINT 有几个优点。它可以保留“前期”工作，节省重新做的成本。它节省了回滚整个事务。回滚可能比原始插入/更新更“昂贵”，并且可能跨越多个事务（取决于提交频率）。最后，当可以通过 ROLLBACK TO SAVEPOINT 有选择地“撤消”数据库工作时，通常会降低流程复杂性。

如何使用 SAVEPOINT 来提高批处理程序的效率？如果您的事务使用自诱导回滚从“盲道”处理中恢复，那么 SAVEPOINT 可能是一个巨大的好处。类似地，如果内部处理逻辑由于需要避免为类似的“回退”要求执行数据库更新而变得复杂，那么可以使用 SAVEPOINT 将过程重构为更简单且可能更高效的内容。除了这些因素之外，SAVEPOINT 不会以积极的方式影响性能。

有些人声称在批处理程序中使用高 COMMIT 频率会降低性能。因此，提交频率越低，性能越好。调整 COMMIT 频率并非易事。提交频率越低，保留的数据库资源越长，因此导致数据库超时的可能性就越大。遭受数据库超时通常会导致进程回滚。回滚是一项非常昂贵的操作。ROLLBACK 对 DBMS 本身来说是一个很大的打击，一旦它重新启动，您的事务就需要第二次重新应用所有更新。降低提交频率最终会使您付出的代价远远超过获得的回报。谨防！

编辑

经验法则：提交是有成本的。回滚成本更高。

不考虑由于坏数据、设备故障和程序异常终止（所有这些都应该很少见）导致的回滚，大多数回滚是由于进程之间的资源争用导致的超时。减少提交会增加数据库争用。减少提交可能会提高性能。诀窍是找出在不提交因争用而导致回滚成本的情况下获得的性能。有很多因素会影响这一点——其中可能是动态的。我的总体建议是寻找其他地方来提高性能 - 调整提交频率（超时不是问题）通常是一种低回报投资。

提高批次性能的其他更有成效的方法通常包括：

• 通过负载拆分和运行同一作业的多个图像来提高并行性
• 分析 db/2 绑定计划并优化访问路径
• 分析批处理程序的行为并重构那些消耗最多资源的部分