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 秒。

1. 事务 A 得到页面 1 上的锁，但是随后陷入等待状态，因为它请求页面 2，而页面 2 当前正被事务 X 锁定。
2. 事务 B 在 1 秒钟之后启动，得到页面 3 上的锁，但是随后陷入等待状态，因为它请求页面 1。
3. 事务 C 在 1 秒钟之后启动，得到页面 4 上的锁，但是随后陷入等待状态，因为它也请求页面 1。
4. 1 秒钟之后，事务 D 和 E 分别请求页面 3 和 4，并且陷入等待状态。
5. 事务 A 等待了 59 秒，然后最终获得了对页面 2 的访问，但是它在结束处理之前，还要继续持有页面 1 上的锁 5 秒钟。
6. 因此，其他所有 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 实用程序区域中。

为实用程序提高并发性

许多 DB2 UDB 实用程序都由于 NPI（非分区索引），受益于分区之间所提高的数据并发性。为了实现这一提高，您需要通过分区并行地运行实用程序，由于并发地执行实用程序，这可能需要新的操作和组织考虑。

LOAD 和 REORG 实用程序都可以极大地从使用该技术中受益。但是，分区依赖性并不有益于 COPY 和 MODIFY 实用程序，因为它们均工作于数据级。

联机 REORG

在 DB2 UDB Version 5 之前，由 REORG 实用程序处理的数据访问要遭受多得多的限制。在 REORG 的卸载阶段，其他应用程序受到限制，只能对该表空间进行只读访问，而在再装入阶段，根本不能对该表空间进行访问。在 DB2 UDB V5 中获得 REORG 实用程序增强之后，通过指定 SHRLEVEL 选项，极大地提高了数据的可用性。这称作“联机”REORG。

通过在 REORG 实用程序作业中指定 SHRLEVEL REFERENCE，其他应用程序几乎在整个作业时期中都可以只读访问该数据。在 REORG 中指定 SHRLEVEL CHANGE 将允许其他应用程序几乎在整个重组过程中读/写访问该数据。

就在该实用程序完成之前，有一段极短的时期将拒绝数据访问。多数客户经常利用联机 REORG 来使得其他应用程序可并发地使用关键的业务数据，并且同时执行必要的数据维护。通过联机 REORG 实用程序，DB2 UDB 为用户提供了虚拟连续可用性方面的极大进展。

减少 REORG 期间的死锁

在调用联机 REORG 时，您可能会经历死锁。如果真的发生了，那么您应该运行带有 DRAIN ALL 选项的 REORG 实用程序。DRAIN WRITERS 是默认的选项，在日志记录阶段执行。DRAIN ALL 选项指示 DB2 UDB 一到达 MAXRO 阈值，就同时放弃（drain）写入者和读取者。在日志记录阶段经历过较大更新活动的环境中，应特别考虑该方法。若指定了 DRAIN ALL，那么在联机 REORG 的切换阶段，就无需要进行放弃（drain）。