DB2通用数据库的并发性

参数 ISOLATION 决定 DB2 UDB 为保护一个应用程序所用数据，防备该 DB2 UDB 系统里的其他应用程序，而维护的保护或隔离程度。下面完全从并发性角度出发，按照递增的优先级列出了 4 个选项：

1. ISOLATION(RR)

   通过可重复读（Repeatable Read，RR），要用行锁或页面锁锁定应用程序所访问的所有行（无论是否为限定的），并至少保持到下一提交点。DB2 UDB 确保：

   • 您的应用程序不读取另一应用程序进程修改的那一行，直到该进程释放该行，并且

   • 其他应用程序进程不修改您的应用程序所读取的那一行，直到应用程序进行了提交或终止。

2. ISOLATION(RS)

   通过读稳定性（Read Stability，RS），要用行锁或页面锁锁定所有返回给应用程序的限定行，并至少保持下一提交点。DB2 UDB 确保：

   • 您的应用程序不读取另一应用程序进程修改的那一行，直到该进程释放该行，并且

   • 其他应用程序进程不修改满足您应用程序的搜索规则（由 WHERE 从句决定）的那一行，直到应用程序进行了提交或终止。它允许其他应用程序进程 INSERT 一行或 UPDATE 现有的行，只要该行原来不满足其搜索规则。

3. ISOLATION(CS)

   通过游标稳定性（Cursor Stability，CS），仅仅将行锁或页面锁保留到游标移动到另一行或另一页。因此，DB2 UDB：

   • 确保您的应用程序不读取另一应用程序进程修改的那一行，直到该进程释放该行，但是

   • 允许其他应用程序进程在您的应用程序进行了提交或终止之前，修改您的应用程序所读取的那一行。

4. ISOLATION(UR)

   通过未提交读（Uncommitted Read，UR），DB2 UDB 不获取任何行锁或页面锁（除了对于 LOB 数据），且可以与大多数其他操作并发运行。在 I/T 行业中，这常常称作“脏读”。通过该隔离级别，DB2 UDB 允许：

   • 其他应用程序进程修改您的应用程序在工作单元期间可能读取的行。
   • 您的应用程序读取另一应用程序进程所修改的那一行，即使该修改还未被提交。

CURRENTDATA

该选项仅适用于 ISOLATION(CS)。对于与游标稳定性（Cursor Stability）绑定的应用程序中的只读和歧义游标，该选项决定是否需要数据并发性。换言之，它告诉 DB2 UDB 该游标所定位数据是否必须与基表中的数据保持一样（或“相容”）。进一步需要阐明的是，对于歧义游标，DB2 UDB 无法确定是将它用于更新还是将它用于只读目的。

CURRENTDATA(YES) 指定需要数据并发性，以致 DB2 UDB 将获取页面锁或行锁来确保这一点。CURRENTDATA(NO) 指定不需要数据并发性，因此，DB2 UDB 不会获取那些锁。

重写隔离（WITH 从句）

DB2 UDB 允许应用程序里的 SQL 语句指定所绑定计划或包的隔离级别。这将有效地重写用于计划或包的隔离级别，但仅仅是在它出现的语句中。WITH 从句可以用于下列类型的 SQL DML 语句：

• SELECT
• “搜索的”UPDATE 和 DELETE
• 子查询中的 INSERT

ISOLATION 建议

合适的 ISOLATION 选项需要通过应用程序的业务逻辑和数据完整性需求来决定。该决定需要对应用程序需求和相关的业务规则具有基本理解。

通常，您应该使用最少的限制隔离，它仍将维护应用程序的数据完整性需求。隔离的限制越少，数据的并发性就越高，因而访问 DB2 UDB 数据的性能就越好。通常，ISOLATION(CS) 与 CURRENTDATA(NO) 将是一个较好的起始点。ISOLATION(CS) 允许 DB2 UDB 尽快释所获取的锁，而 CURRENTDATA(NO) 允许 DB2 UDB 避免过于频繁地获取锁。

未提交读（Uncommitted Read，UR）极其高效，仅导致少量竞争或不导致竞争，但是，它的使用应极为谨慎，因为它使 DB2 UDB 能够读未提交的数据。一般不推荐使用 ISOLATION(UR)，除非已经确定应用程序和终端用户可以接受 UR 所允许的逻辑数据不一致性。

锁避免和隔离

锁避免是在 DB2 V3 中引入的并发性提高。它使 DB2 UDB 在确定某页中的数据已经提交之后，就能够读取该页面，而无需获得锁。是否可以使用锁避免取决于应用程序在其 SQL 调用中使用的隔离程度。

ISOLATION(RR) 和 ISOLATION(RS) 不允许任何锁避免。带有 ISOLATION(CS) 的游标对非限定的页面或行使用锁避免。带有 ISOLATION(CS) 和 CURRENTDATA(NO) 的歧义游标和只读游标对限定的和非限定的页面或行均使用锁避免。

限制表空间上的锁

LOCKMAX 是一个可以在 CREATE 或 ALTER 表空间时指定的选项。这指定在进行锁升级之前，单个应用程序可以持有的 DB2 UDB 表空间上的页面锁或行锁的最大数目。该选项可以同时对用户数据和 DB2 UDB 编目生效。

如果 n表示发生锁升级之前页面锁或行锁的最大数目，那么就指定 LOCKMAX n。通过指定 LOCKMAX 0 可禁止锁升级。指定 LOCKMAX SYSTEM 是将最大数目设置为系统默认值，而系统默认值是由安装面板的 DSNTIPJ 上的选项 LOCKS PER TABLE(SPACE) 设置的。

限制应用程序获取的锁

DB2 UDB 还允许设置单个应用程序持有的页面锁或行锁的最大数目。该选项 LOCKS PER USER 也位于安装面板 DSNTIPJ 上。如果一个应用程序进程已经持有所指定的最大数目，但又向 IRLM 请求一个页面锁或行锁，那么 DB2 UDB 就会向该应用程序的 SQLCA 发送一条错误消息。直到释放某些现有的锁之后，才可以获取所请求的锁。

默认的 LOCKS PER USER 为 10,000。当使用页面锁时，该数字对于大多数装置的多数工作负载来说通常已经足够了。对于极其大型的表上的行级锁或 LOB 来说，可能有必要指定一个更大的值。或者，您可能需要查看需要更大值的应用程序类型，并分析它们是否可以使用表空间锁来代替页面锁、行锁或 LOB 锁。

系统和安装考虑

除了上述关于数据库和应用程序设计的建议之外，这里还有一些关于安装选项和系统环境的建议和考虑：

DB2 UDB 编目竞争

某些 SQL DDL（数据定义语言）、SQL DML（数据操作语言）和 SQL DCL（数据控制语言）语句获取 DB2 UDB 编目上的锁。如果多个应用程序进程都发出这些语句，就可能真正发生编目竞争。

我建议您尝试最低限度地并发使用更新同一 DB2 UDB 编目表空间的语句。通常，需要设置关于何时应提交这种 SQL 的标准，并且/或者限制可以更新该 DB2 UDB 编目的授权用户 ID 数目。关于可能导致编目竞争的 DDL、DML 和 DCL 的详细描述，请参阅 DB2 UDB Administration Guide。

IRLM 优先权

应该给予 IRLM 极高的 MVS 调度优先权，以便它可以尽快为锁请求提供服务。IBM 通常建议 IRLM 的优先权仅次于 VTAM 的，但要高于其他 DB2 相关的地址空间。