重写隔离（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 相关的地址空间。

    IRLM 存储

    面板 DSNTIPJ 上的 CROSS MEMORY 条目决定了 IRLM 是否在 ECSA（扩展的控制存储区）或它自己的私有地址空间里存储其锁控制块。

    指定 NO（PC =NO，这意味着不使用跨地址空间的程序调用）会将锁结构置于 ECSA 中，而且只需要较少的 CPU 时间，但是，却可能减少使用 ECSA 的其他 MVS 地址空间可用的存储器数量。通过该选项，另一参数 MAXIMUM ECSA 也将起作用。这将决定 IRLM 可用于其锁结构的 ECSA 的最大数量。重要的是，要将该值设置得足够高，以防止 IRLM 到达极限。IRLM 仅仅按需获取存储器，因此，较好的是设置一个比估计需要值要大的值。

    通过指定 YES，锁控制块结构将存储于 IRLM 私有地址空间中，而程序调用指令（PC=YES）则用于处理该结构。如果有 PC=YES，则会忽略 MAXIMUM ECSA 选项。

    目前，DB2 UDB V7 的经验显示 PC=YES 为推荐设置，因为虚拟地址空间约束的影响被认为比通过选择该选项而消费的附加 CPU 周期产生的影响更大。从 DB2 UDB V8 开始，就不再使用 PC 和 MAXIMUM ECSA 键（V8 自动实现 PC=YES）。

    MVS 系统负载和交换

    如果您的 MVS 系统资源由于工作负载过重而较为紧张，那么 CPU 周期、I/O 处理和存储器上增加的竞争则可能导致任务陷入等待状态，直到可以获得所需的资源。

    同样明智的是，在您的 MVS 系统中根据实际情况减少“交换”量。当 MVS 分页率变得过高时，某一地址空间就可能被“换出”，即将地址空间中的所有虚拟存储器移至磁盘中。每当一个任务被换出，或等待其他系统资源，而该工作单元还未提交，那么该任务就继续持有 DB2 UDB 对象上的锁，这将影响并发性。

    DEADLOCK TIME

    参数 DEADLOCK TIME 指定 DB2 UDB 在系统中扫描死锁的应用程序进程的时间间隔长度。该参数是在安装面板 DSNTIPJ 上指定的，其默认值为 5 秒。

    正如所期望的，死锁检测的非常好的值的确定取决于您 DB2 UDB 应用程序工作负载的特点和大小。因为死锁检测可以导致锁存器暂挂，所以如果您的系统未经历死锁，那么可以考虑使用默认值。死锁检测的检测不那么频繁则意味着 DB2 和 IRLM 所花的处理时间将会少一点。但是，如果您经历了一定程度的死锁，则应该将该值减小至 1 秒（您需要尽快发现死锁情况）。

    RESOURCE TIMEOUT

    参数 RESOURCE TIMEOUT 是在安装面板 DSNTIPI 上指定的，它规定了在发生超时之前 DB2 UDB 的最小秒数。默认值为 60 秒，这可能是新的 DB2 UDB 安装的较好起始点。因为您应用程序的性能特点会随时间发展并改变，所以您需要评估该参数值是否有效地维护较好的并发性。较小的值可能导致更多的超时。通过设置一个较大的值，暂挂的应用程序通常会更为频繁地重新开始，但是在更长的期间内，它们仍然是非活动的。

    此外，这里有一个虚拟场景，演示了如何可以减小该值来真正减少超时，即使该思想与开始的直觉相反。假设 RESOURCE TIMEOUT 为 60 秒。

    事务 A 得到页面 1 上的锁，但是随后陷入等待状态，因为它请求页面 2，而页面 2 当前正被事务 X 锁定。
    事务 B 在 1 秒钟之后启动，得到页面 3 上的锁，但是随后陷入等待状态，因为它请求页面 1。
    事务 C 在 1 秒钟之后启动，得到页面 4 上的锁，但是随后陷入等待状态，因为它也请求页面 1。
    1 秒钟之后，事务 D 和 E 分别请求页面 3 和 4，并且陷入等待状态。
    事务 A 等待了 59 秒，然后最终获得了对页面 2 的访问，但是它在结束处理之前，还要继续持有页面 1 上的锁 5 秒钟。
    因此，其他所有 4 个事务 B-E 都超时了。
    如果 RESOURCE TIMEOUT 为 30 秒，那么事务 A 在获得页面 2 之前就会超时，但这样可以释放页面 1，以致事务 B 到 E 都可以执行。因此，超时的事务将不是 4 个，而是只有 1 个。

    禁止非活动的应用程序

    安装面板 DSNTIPR 上有一个 IDLE THREAD TIMEOUT 选项。该选项指定不进行任何处理时，活动 DB2 UDB 分布式线程可以持有锁的时间期。在该时期之后，DB2 UDB 扫描进程就检测出该线程已经空闲了一段指定的时间，因此，DB2 UDB 就取消该线程。

    RELEASE LOCKS

    参数 RELEASE LOCKS 位于安装面板 DSNTIP4 上，控制在进行提交时，是否释放被定义为 WITH HOLD 的游标使用的页面锁或行锁。默认值为 YES，这意味着 DB2 UDB 在发出 COMMIT 之后，释放页面锁或行锁。您应尽可能多地使用该默认值，因为这将提高并发性。

    如果用户指定 NO，那么 DB2 UDB 将在发出 COMMIT 之后，为 WITH HOLD 游标保留该页面锁或行锁。该选项允许当前依靠该锁的应用程序可以像之前一样继续工作。

    操作考虑

    除了上面提及的关于数据库和应用程序设计考虑的众多事项之外，还有一些与 DB2 UDB 日常操作有关的事情，这些操作可以影响数据并发性水平，特别是在 DB2 UDB 实用程序区域中。