减少与 DB2 for z/OS 的会话：第 3 部分：以不同的思路思考普通事务

核心提示：在前面两个专栏中，谈到不必要的 SQL，减少与 DB2 for z/OS 的会话：第 3 部分：以不同的思路思考普通事务，并给出了执行次数过多的SQL 例子，以及应当由更新的、性能更优的 SQL 来替代的例子，将用户维护的、最后更新的时间戳与其初始值对比（并在 SET 子句中重置该时间戳），来确定从该行取得图像后，在本

在前面两个专栏中，谈到不必要的 SQL，并给出了执行次数过多的SQL 例子，以及应当由更新的、性能更优的 SQL 来替代的例子。在本专栏中，将讲述更多 SQL 应当被推迟、结合、或者完全避免的情况，最终目的都是减少与DB2 的对话。

通过三步移除不必要的重复读取（re-reads）

Screen-display 应用因其大量不必要的重复读取而出名。我们读取一个图像并显示；用户变更屏幕上的值并点击功能键来更新；程序获得控制权并重新读取该行（通常此时利用使用 FOR UPDATE OF 的 CURSOR ）。FETCH 之后，程序进行 “前后” 检查，来查看在进行屏幕显示时，是否有不同用户对该行做了改动。

如果该行与最开始时一致，则用户的 UPDATE 操作完成。如果行中的任何列改变了，相应的信息/错误将返回给用户。

解决这一不必要 SQL 问题的方法是，采用 “乐观锁定（optimistic locking）” 技术。我们确信大多数情况下，行不会在屏幕显示时改变。我们的 UPDATE 杯子是半满，而不是半空。因此，将不必重新读取该行而直接进行 UPDATE 操作。但是，我们并不笨；我们将使用试错（tried-and-true）技术来确保针对未变更行的 UPDATE 操作已经完成：我们在子句 WHERE 中增加了一个或多个谓词，来测试变更。有很多选项可用于测试变更，其中一些允许比其他有更多的流量。例如，我们可以：

设计表来包含 DB2 维护的 ROW UPDATE TIMESTAMP（DB2 9 中的新特性），并在 WHERE 子句中包含一个谓词，来检查该列，从而确定该值是否与从列中读取的初始值相同。

将用户维护的、最后更新的时间戳与其初始值对比（并在 SET 子句中重置该时间戳），来确定从该行取得图像后，该行没有任何变化。