DB2通用数据库的并发功能

数据共享考虑
以下几段强调了运行 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。