Prayer

2003 年 1 月 01 日

在只读情况下进行 COMMIT 时释放锁并释放应用程序。

简介

许多正在使用 DB2 for z/OS 或 DB2 for OS/390 的人都认为对只读访问使用 COMMIT 是没有必要的。这些人认为，因为他们没有更改任何数据，所以没有必要使用 COMMIT 。但是 COMMIT 不仅应用更改, 它还释放锁和声明（claim）, 所以 COMMIT 会影响应用程序可用性。

我要解释在将 COMMIT 引入到进行只读访问的应用程序时要注意的可用性考虑事项以及声明和放弃（drain）的概念。我将使用的示例特定于只读环境；这些示例并不旨在讨论有关更新活动的 COMMIT 考虑事项。本文的范围限于在以下环境中对只读应用程序进行 COMMIT 操作：可能在该环境中执行进行更新的实用程序和其它应用程序。本文中，我将使用术语“应用程序可用性”来表示关于允许读访问的可用性。

回页首

获得声明

如果您熟悉 DB2，那么您可能对于对象（例如行、页面、表或表空间）上的不兼容锁（例如 X 和 S）会降低并发性有相当的了解。但如果您将只读程序与 ISOLATION Un COMMIT ted Read（UR）联编在一起，会怎么样呢？这样做意味着您的只读程序可能不会获得任何锁。要牢记的是，如果涉及到大量删除，则与 ISOLATION UR 联编的程序确实会获得针对表或表空间的 MASS DELETE 锁。如果表空间使用工作文件数据库，则还会获得针对它的 IX 锁。但是，本文讨论只读方案。

所以问题是，在以 ISOLATION UR 隔离级别绑定进行只读访问的应用程序中使用 COMMIT 会对整个应用程序的可用性产生任何影响吗？

回答是：会产生影响。

尽管以 ISOLATION UR 隔离级别进行绑定时，进行只读访问的应用程序没有获得锁，但它确实声明了这个对象。而正如我将在本文稍后解释的，声明可能就是导致可用性降低的原因。正如我前面提到的， COMMIT 释放了声明。

现在，在应用程序可用性极其重要的环境中，当更新活动很少时，最好安排数据库维护作业（诸如 REORG 或 IMAGE COPIES ）。这样做增加了 REORG 作业与长时间运行的只读批处理作业并发运行的可能性 — 这就是可用性成为问题的原因所在。

REORG 类似于其它实用程序，（在某个阶段）需要一个针对对象的 drain 锁，它会一直等待，直到能获得一个这样的锁为止。放弃是一种用于接管对象并序列化对它的访问的机制。当释放了对象上的所有声明，而且预先不存在 drain 锁时，就可以获得 drain 锁。Drain 请求器防止实用程序获得已放弃对象上的任何新声明。

从应用程序观点来看，您可能对可用性问题是如何结束的感到疑惑。REORG 作业将一直等待，直到应用程序的作业完成为止吗？如果在 REORG 实用程序可以请求放弃之前，应用程序获取了声明，则它会一直等待。但是如果 REORG 先请求放弃，那么它就不会等待。

当然，在启动 REORG 实用程序之前可以初始化应用程序的作业，以确保 REORG 会等待批处理作业。但是，如果还有另一个批处理作业或在线事务，那么它将会进入等待，因为它不能获取对象的声明。（新作业或事务必需获取声明，但是 Drain 请求器 REORG 会阻止该对象的任何声明。）

作为准备执行的只读程序和 REORG 实用程序（我将解释这两个程序可能会也可能不会同时执行）的结果所产生的应用程序非可用性程度取决于：

• REORG 上指定的 SHRLEVEL OPTION
• 与 REORG 并发执行的批处理作业的 COMMIT 频率。

REORG 实用程序在终止之前，需要放弃所有声明类。如果 REORG 在执行时使用 SHRLEVEL REFERENCE 或 SHRLEVEL CHANGE ，那么会在 SWITCH 阶段发生这个放弃，如果该实用程序执行时使用 SHRLEVEL NONE ，那么会在 RELOAD 阶段发生这个放弃。

长时间运行的进程的 COMMIT 频率也会影响可用性。通过引入 COMMIT 就可以释放对象上的声明。注：如果批处理作业正在使用用 WITH HOLD 定义的游标，那么在经过 COMMIT 点之后仍会保留声明。在所有其它情况下，在 COMMIT 时都释放对象的声明。对象声明的持续时间并不取决于计划或包的 BIND 过程中指定的 RELEASE 参数（ COMMIT 或 DEALLOCATE ）。

表 1 演示了 REORG SHRLEVEL 参数和 COMMIT 频率对应用程序可用性的的影响。为简单起见，我们假设采用一个未分区的表空间。该表还假设批处理作业正在执行，并且在 T1 时间触发 REORG 作业。让我们研究该表中显示的各种情况。

表 1：比较使用 COMMIT 和不使用 COMMIT 时的进程

情况 1. 进程执行时不使用任何中间 COMMIT 。使用 SHRLEVEL NONE 的 REORG 作业在 T1 时间启动。

情况 2. 进程执行时不使用任何中间 COMMIT 。使用 SHRLEVEL REFERENCE 或 CHANGE 的 REORG 作业在 T1 时间启动。

情况 3. 进程执行时，在 T3 时间进行中间 COMMIT 。使用 SHRLEVEL NONE 的 REORG 作业在 T1 时间启动。

情况 4. 进程执行时，在 T3 时间进行中间 COMMIT 。使用 SHRLEVEL REFERENCE 或 CHANGE 的 REORG 作业在 T1 时间启动。

情况 5. 进程执行时，不包含任何中间 COMMIT ，但与情况 2 相比，执行完成所花的时间比较长。

情况 6. 进程执行时，在 T3 时间进行中间 COMMIT ，但与情况 4 相比，执行完成所花的时间比较长。

从表 1 您可以得出如下结论：

• 不进行中间 COMMIT 的批处理作业在与 REORG （ SHRLEVEL NONE ）作业并发执行时所产生的非可用性持续的时间最长。非可用性程度取决于进程（最可能的是批处理作业）的持续时间和正在被重组的表空间大小。
• 从情况 2 和情况 4 中可以看出，当 REORG 与不考虑 COMMIT 频率的批处理作业并发执行时，非可用性时间看起来相同；但是事实并非如此。如果情况 2 中的进程执行的时间更长，它会导致 REORG 等待的时间更长，从而增加应用程序非可用性时间。如果情况 4 中也出现类似的情况，它导致很少的进程等待时间（ T5 时间），而 REORG 实用程序在切换（switch）阶段执行并在该阶段终止。但是，不会增加非可用性时间（请参阅情况 5 和情况 6）。
• 如果进程的等待时间超过了 DSNZPARM 中的 IRLMRWT 值，那么进程将以 -911 （超时）终止。如果应用程序中这种情况很常见，那么请考虑提高 IRLMRWT 值，或将重试逻辑合并到程序中。
• 如果实用程序的等待时间超过了实用程序的超时时间，那么实用程序就超时。通过使 UTIMOUT 与 IRLMRWT 相乘可以确定实用程序超时时间。您可能有兴趣通过提高这两个参数中任一个或同时提高这两个参数来提高该实用程序的超时时间。但请谨慎使用这个方法。注：在所有情况中，每当 REORG 作业转至等待状态（等待获得 drain 锁），它会导致应用程序的非可用性。因此，当您在提高实用程序超时值时应该小心，因为它将对可用性产生直接影响。

 

回页首

解决方案

用 SHRLEVEL REFERENCE （允许并发的读操作）或用 SHRLEVEL CHANGE （允许并发的更改操作）方式执行 REORG 实用程序以及使长时间运行的进程发出中间 COMMIT 是解决可用性问题的优秀方案。决定 COMMIT 频率的关键因素是非可用性最大容许量以及 DSNZPARM 中定义的实用程序超时值。 COMMIT 频率应该小于非可用性最大容许度。如果大于或等于的话，从本文中您已经了解到，它会导致可能的非可用性（当 REORG 在等待放弃所有声明时，禁止任何新的声明）。

即使 COMMIT 频率低于非可用性最大容许度，但使用 DB2 V6（或更低版本）时，已分区表空间的 SWITCH 阶段也可能会花相当一段时间（以便 IDCAMS 进行重命名），从而导致非可用性。使用 DB2 V7，通过使用 FASTSWITCH YES （缺省值）会缓解该问题。如果 COMMIT 频率大于实用程序超时值，那么它就可能使 REORG 实用程序未完成任何工作就超时了。DB2 V7 引入了两个新选项： DRAIN WAIT （指定覆盖实用程序超时值的时间）和 RETRY （在发出超时之前进行重试的次数），以防止 REORG 超时。

回页首

做就是了

虽然在引入中间 COMMIT 时会产生与之相关的额外开销（至少需要一个额外的数据库调用），但是通过仔细规划，用相当低的投资（CPU 开销）获得相当好的回报（应用程序可用性）是可能的。

回页首

参考资料

DB2 for z/OS and OS/390
ibm.com/software/ db2zos

关于作者

		Pranav Sampat 是 Cognizant Technology Solutions 的顾问。他是数据库设计、性能、恢复和可用性方面的 IBM 认证的 DB2 DBA。可以通过 spranav@email.cognizant.com与他联系。