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

核心提示： （一个 CONNECT ，以及 100 个以上针对第 26 行返回的 SQLCODE）Closecsr-select-and-delete-old-rows（一个 CONNECT）新的最佳情况是，减少与 DB2 for z/OS 的会话：第 3 部分：以不同的思路思考普通事务(4)，您将：为 O

（一个 CONNECT ，以及 100 个以上针对第 26 行返回的 SQLCODE）

Close　csr-select-and-delete-old-rows

（一个 CONNECT）

新的最佳情况是，您将：

为 OPEN 进行 CURSOR 设置，CONNECT 到 DB2

为 FETCH，CONNECT 到 DB2，并且：
a. 对索引树中的页发出 GET PAGE 请求
b. 读取 25 索引项，在读取表之前，完全限定该行
c. 对 25 个 RID 中的每一项，向表发起 GET PAGE 请求（如果我们很幸运，并且有些行共享一些页，可能会少做点 GET PAGEs 操作）
d. 对于每个 GET PAGE，需要做 READ I/O 操作
e. 当发现每行时，DELETE 它
f. 将每行中已 SELECT 的列插入 final_table
g. 向程序返回 25 行

写入报告：

Close　csr-select-and-delete-old-rows　

（一个 CONNECT）

利用前面的 4 项技术，将对话从 528 次减少到 3 次，同时，将表 GET PAGE 请求的数量从 3,000 次降低到至多 25 次。

消除 Stage 3

我想详细阐述上述第 4 个建议改进（去除 STAGE 3 取消资格）。作为咨询人员，我发现主要的公共编码失误之一是在程序中，而不是 DB2 中验证并拒绝行。

这些 STAGE 3 谓词，特别是拒绝大部分行的那些，通常是不使用 WHERE 子句的旧有 VSAM 逻辑的结果。我们采用键控读取，然后向记录应用程序编码的 IF/THEN/ELSE 逻辑。IF/THEN/ELSE 逻辑是搞清楚如何使用 WHERE 子句谓词的良好基础，因此在 DB2 地址空间中行能够被快速拒绝。

结束语

我编写这个三部分系列文章，来强调完全消除或者延迟 —— 直到最后一刻 —— 与 DB2 对话的重要性。今后，在为每个 SQL 语句编码时，我希望会有一个小 Bonnie 坐在您身边，问道：“这有必要么？能否一次对多个行进行读/维护？能否推迟这一 SQL，直到确保需要这样做？”