DB2通用数据库的并发性

监控锁定

您应知道您的 DB2 UDB 系统所具有的数据并发性水平。应用程序或数据库设计方面的不足、受约束的硬件资源、渐增的事务量、数据库增长和其他因素都可以导致性能和并发性的降低。

首先，要奠定“基线”- 换言之，就是要奠定在您的环境中用于应用程序和数据库的标准。监控量（volume）以及异常或错误条件成为识别和解决并发性问题的关键。

显示实时的锁信息

通过在发出 DISPLAY DATABASE 命令时包含 LOCKS 选项，DB2 UDB 将在特定时刻及时地显示大量关于持有或等待哪些锁的信息。对于显示（DISPLAY）的 DB2 UDB 数据库（或是其中的一部分）来说，该信息包括：

• 用于所有表、表空间、分区和索引空间（indexspace）的事务锁，以及这些锁的模式和持续时间。
• 当前持有、等待或保留锁的应用程序和 DB2 子系统。
• 用于分配给数据库的所有应用程序的授权 ID、相关 ID 和连接 ID 的信息。
• 关于逻辑分区和当前执行的实用程序作业所持有的其他资源的 drain 锁信息。

决定锁模式

如果发出 EXPLAIN 语句，或者如果在 BIND 和 REBIND 命令中包含 EXPLAIN 选项，就可以决定表和表空间锁的模式（Share、eXclusive 等），而这些锁最初是 DB2 UDB 为特定的 SQL 语句指派的。EXPLAIN 的输出存储在 PLAN_TABLE 中，用户然后可以进行查询。表空间的初始锁模式包含在 PLAN_TABLE 的 TSLOCKMODE 列中。

跟踪锁信息

为了最大化环境中的数据并发性，回答下列问题将有助于识别模式、趋势和问题：

• 哪些应用程序竞争资源？
• 对于哪些表和/或表空间来说，存在竞争？
• 竞争的类型和频率是什么？
• 那些竞争有何影响？

您应运行统计（Statistics）、记帐（Accounting）和跟踪（trace）功能来记录关于 DB2 UDB 应用程序性能特点以及整个 DB2 UDB 系统的信息。这些跟踪应该连续运行，这样您就可以定期创建报表来查看和分析数据。这项报表编制功能可以用 IBM 的 DB2 Performance Expert（DB2/PE）或类似的程序来完成。

统计（Statistics）跟踪记录报表时间间隔中发生的锁定和解锁请求、声明和放弃请求、锁暂挂、死锁、超时和锁升级的数目。记帐（Accounting）跟踪记录在应用程序（而非³»统）级别上跟踪相同类型的信息。此外，这些跟踪显示了整个时间间隔期间，以及持有和获取的并发页面锁的最大数目。

从并发性观点来看，您应该查看这些报表来帮助您识别下列状况：

• 锁升级通常视为是不理想的，一般是由持有大量页面锁、行锁和 LOB 锁的应用程序导致的。对于这些情况，通过一开始就使用表锁或表空间锁可以提高并发性和整个系统性能，因此，要避免升级发生。
• 超时可能是由一个对于您的环境来说并非最佳的 RESOURCE TIMEOUT 值导致的。如果存在大量超时，则可能是该值过低。较高的 RESOURCE TIMEOUT 值可以为更多应用程序提供完成其工作的机会。但是，要密切监控您所做的修改，因为通过减小该值（请参阅子标题 RESOURCE TIMEOUT 下面的讨论），可以改善某些状况。
• 死锁可能是性能和并发性的主要障碍。通常应进一步调查这些东西，以便同时确定导致障碍的原因以及可能的解决方案。
• 某些应用程序一贯地持有大量锁。请查看这些应用程序（以及底层的数据库设计），以判断是否可以降低该数字。

理想情况是，装置争取获得死锁和超时的“零”计数，最多具有少量的锁升级。如果在经过有限的少量事件之后，发生了这三种征兆之一，那么可能应该调优您的锁定了。

关于锁升级，一条经验法则主张如果有超过四分之一的锁升级最终导致死锁或超时，那么升级就不适用于您的环境（请参阅上面关于锁升级的讨论）。要考虑增加 LOCKMAX 或 LOCKS PER TABLE(SPACE)。另一种可能的解决方案就是使受影响的应用程序在初始化时发出 LOCK TABLE。

另外，监控锁定/解锁请求、暂挂和声明/放弃请求的总数目。监视那些数量趋势（预期的或其他的）是在 DB2 UDB 环境中维护高水平的数据并发性的关键。

报警极限

特定页面或行被锁定的概率可能有较大变化，这取决于数据库设计、应用程序代码、事务量、可用的系统资源（例如 CPU、内存、I/O 等）和许多其他的因素。作为一般的经验法则，如果一页或一行被锁定的时间超过 10%，就认为它是“热的（hot）”。因此，10% 可视作合理的报警极限。少于 10% 通常视为是可以接受的，而大于 10% 则可能暗示竞争过多，并且可能应进行调查。

在多数环境中，锁的平均持续时间少于 1 秒钟。如果您装置的锁平均持续时间大于 1 秒，可能就必须进一步进行分析了。

数据共享考虑

以下几段强调了运行 DB2 UDB 数据共享（Data Sharing）环境时，应该查看的信息。某些讨论仅仅与数据共享有关，而某些材料则可能适用于通常状况下的 DB2 UDB（甚至在前面可能已经提及），但对于数据共享环境中的考虑特别重要。

顺序批插入计划

任何按顺序执行 INSERT 的批处理应用程序都可能导致表空间的空间映射页面上的严重竞争。对于这样的应用程序，在创建用于它们的表空间时要考虑使用参数 MEMBER CLUSTER。通过该选项，DB2 UDB 在为 SQL INSERT 语句指派空间时，就不考虑群集索引。因此，DB2 UDB 将基于可用空间，将插入置于数据库中，这意味着不只是一次或几次访问不同的空间映射页面。这将极大地减少对于空间映射页面的竞争。

选择性的分区锁定

DB2 UDB V5 引入了选择性的分区锁定，这意味着仅仅锁定要访问的分区。这是通过在 CREATE 或 ALTER TABLESPACE 语句中指定 LOCKPART YES 选项来完成的。

该功能主要使用在数据共享的环境中，允许 DB2 在分区级别上支持显式的层次结构锁定。选择性的分区锁定为 L 锁提供了真正的分区独立性，因而当数据共享组中的每个成员处理不同的分区时，避免了 IDRWI（DB2 内部读/写兴趣）。在 DB2 UDB V5 之前，表空间的父 L 锁定是在表空间级别上的，甚至对于分区的表空间也是如此。

锁避免

在 DB2 数据共享组中，建议进行下列实践，用以最大化锁避免，并因此提高并发性：

• 在运行于分组里任何成员中的所有应用程序进程中进行频繁提交。
• 停止（Quiesce）分组中非活动的成员。
• 快速地重新启动失败的成员，以便解决处于质疑中的事务。
• 在可能时对计划和包使用 CURRENTDATA(NO)。

LOCKSIZE

对于数据共享系统，我们极力建议使用 LOCKSIZE PAGE。在使用 LOCKSIZE ROW 之前，用户应仔细分析数据库设计和将访问该数据的应用程序进程的本质。数据共享的 DB2 UDB 系统由于页面物理锁（P-lock）竞争和协商，招致了行锁定的附加开销。通过较高的事务速率，应用程序在页面 P 锁之后，趋向于串行化。因此，要按照设计默认值使用页面锁定。

减少竞争

DB2 数据共享环境中有 3 种不同类型的竞争：

1. 假（False）竞争- 单个 DB2 UDB 成员计算一个哈希（hash）值，用于确定将资源指派给哪个锁表条目。锁表存储在耦合设备中。此哈希值是通过使用资源名称，以及惟一地定义将要锁定资源的相关信息来计算的。虽然特定的资源总是产生一个（且只有一个）值来确定它在锁表中的位置，但极其可能有不止一个资源将散列到相同的锁表条目，该状况称作假（false）竞争。

2. XES 竞争- 耦合设备中的锁管理器和 XES 只承认两类锁模式 - 共享（S）模式和排他（X）模式。但是，IRLM 支持许多其他的模式，例如意图共享（intent-share，IS）、意图排他（intent-exclusive，IX）和意图排他的共享（share with intent-exclusive，SIX）。该情况导致从 ERLM 传递到 XES 时，将缩减锁模式。如果 XES 接着试图注册一个与现有锁不兼容的锁，XES 就必须检查 IRLM，以便更精确地确定所需的锁类型，以及这一锁请求是否真的兼容。如果该调查确定那些锁实际上是兼容的，那么就仅仅为 XES 竞争。如果那些锁实际不兼容，那么该竞争就是真的。

3. 真（Real）竞争- 这是一种“传统的”竞争，通常由两个应用程序之间 IRLM 不兼容性导致，这在非数据共享的环境也会发生。

通常建议的经验法则显示所有锁请求会导致竞争（真的或假的）应低于 2%。应对导致多于 2% 竞争的应用程序进程进行进一步的调查，用以确定这些竞争是真的还是假的。

锁结构的大小可以影响数据共享环境中遭受的 false 竞争的数量。如果有更多锁表条目，那么两个不同资源“散列”到同一条目的机会就更少。因此，通常可以通过增加耦合设备中锁结构的大小来减少假竞争。如果所有竞争中超过一半为假竞争，我们就建议您扩展锁结构。

如果大多数竞争是“真的”，那么应评估所熟知的数据库和应用程序设计原则，看是否适用于该情况。下列动作通常有助于减少实际竞争：

• 对表访问和更新使用一致次序。
• 优化事务以减少整个经过时间。
• 频繁地增加 PCTFREE 和运行 REORG 实用程序。
• 将跟新推迟到就正提交之前进行。
• 评估是否使用 LOCKSIZE ROW。(完)