DB2通用数据库的并发性

DB2通用数据库的并发性

最大限度地访问关系 数据

级别： 初级

Fred Whitlark ( fwhitlar@us.ibm.com), DB2 顾问, IBM

2004 年 8 月 01 日

    并发性是 数据库 管理 系统具有的一种 功能，用以允许多个用户同时访问数据，同时维护数据的完整性和一致性。本文针对在 DB2 for z/OS 环境中提供并发性，提供了一些通用 指南和建议。

序言

本文的目的是为 IBM® 商业合作伙伴提供有关 z/OS® 环境中 DB2® Universal Database™（UDB）的数据并发性的重要信息。本文试图将多个来源中极其大量的材料联合起来，然后尽可能高效地显示该信息。但不打算过于全面或详尽地进行介绍。

我打算讨论那些最常导致检测和解决并发性问题的因素。每种可能的解决 方案和每一项潜在的考虑都是无法预期的，就更不用说涵盖整个计划范围了。我希望本文提供一些通用指南，以帮助 DB2 UDB 客户在自己的环境中取得高度数据并发性。本文将是一个在任何给定装置上处理并发性问题的较好起始点。

我假定您对于 z/OS 环境中的 DB2 UDB 已经有了基本的理解。本文的前部分讨论概念和定义，以便使大家处于同一起跑线上。我的建议本质上有点倾向于通用化，但我也并没有总是详细地叙述 技术描述和语法规范。关于这些问题的更多详细信息，我建议您查看为安装在客户端的 DB2 UDB 版本提供的最新 IBM 文档。

本文的通用设计点是 DB2 UDB V7。 虽然已经发布了 z/OS 上的 DB2 UDB V8，但有可能在数月之后，大多数 IBM 客户才会为其生产系统实现 DB2 UDB V8 新功能模式（New Function Mode，NFM）。这里还要考虑另一个因素。虽然 DB2 UDB 的每个新版本在普遍可用之前，都经过了 IBM 以及客户环境的广泛测试，但与还未被广泛、普遍使用的版本相比较，客户极可能更信赖基于 DB2 UDB 早期版本的通用建议、经验法则等（因为实际经验的深度和广度可以验证结论）。

免责声明：本文档包含的信息是没有经过任何形式的 IBM 测试。该信息的使用或这些技术的实现是用户的责任，要依靠用户的能力进行评估，并将其集成到客户特有的操作环境中。虽然 IBM 已经在特定情况下检查了每一项的准确性，但不保证在其他地方将获得相同或相似的结果。尝试调整这些技术以适应自己环境的用户必须自担风险。

 

数据库设计考虑

取得高度并发性应该是指导 DB2 UDB 数据库初始设计的目标之一。在创建各个表的同时，可能要考虑许多影响并发性的功能。您可以在实现创建之后再添加某些功能（例如通过更改 DB2 UDB 对象），但另一些功能则无法添加，或者至少需要大量重复操作和/或打乱当前实现。因此，最好是一开始就考虑这些问题。

分区

我极力建议您将较大的表创建为分区表。一个分区表空间只包含单个分区表。要基于分区索引的键范围将该表分成多个分区。每个分区都是作为单独的数据集（dataset）来创建的，并且可以作为单独的实体由 DB2 UDB 加以处理。

对于大量的批处理操作（INSERT、UPDATE、DELETE），您可以将大型作业划分成较小的作业，利用该分区表结构。许多这些较小的作业可以并发运行（对不同的分区进行），以便减少整个批处理操作的占用时间，从而使另一应用程序进程可以更早地访问该表。

分区表以类似的方式使实用程序作业只作用于所选择的分区，从而允许其他作业或应用程序进程并发访问表中的其他分区。在许多情况下，DB2 UDB 实用程序本身就具有利用分区表的能力，而在其他情况下，它只为用户提供了设计其工作负载的选项，以便支持 DB2 UDB 数据的更高并发性级别。

锁升级

DB2 UDB 使用升级技术来平衡锁定性能开销的并发性需求。当一个应用程序进程持有单个表或表空间上的大量页面锁、行锁或 LOB 锁时，DB2 UDB 就获取该资源上的表或表空间锁，然后释放该资源上以前的页面锁、行锁或 LOB 锁。该过程称作 锁升级。

如果一个使用分区锁定（带有 LOCKPART YES 的 CREATE 或 ALTER）的表上发生锁升级，那么，就只升级当前被锁定的分区，未锁定的分区仍旧未锁定。一旦表空间中发生了锁升级，那么就要用表空间锁来锁定随后访问的未锁定分区。

在执行应用程序时，DB2 UDB 首先使用页面锁或行锁，并且只要该进程访问相对较少的页面或行，还会继续这样做。当该应用程序访问许多页面或行时，DB2 UDB 将变为使用表锁、表空间锁或分区锁。调用锁升级的准确时间是由 LOCKSIZE 和 LOCKMAX.的值决定的。

LOCKSIZE

LOCKSIZE 是 CREATE/ALTER TABLESPACE 语句的选项，在应用程序进程访问表空间中的表时，控制 DB2 UDB 获取的何种类型的锁（即，它决定该锁的“大小”，这有时也称作锁粒度）。该选项的可以是 LOB、TABLESPACE、TABLE、PAGE、ROW 和 ANY。

CREATE TABLESPACE 语句的 LOCKSIZE 参数默认为 ANY。LOCKSIZE ANY 允许 DB2 UDB 选择锁大小。DB2 UDB 通常将 LOCKSIZE PAGE 用于非 LOB 的表，而将 LOCKSIZE TABLESPACE 用于 LOB 表。

我建议在创建表空间时使用该默认值，除非您有理由进行其他选择。如果您选择修改 LOCKSIZE，那么就要根据使用该表空间的应用程序的性能监控结果和并发性特点来做决定。

使用何种大小的锁

在 DB2 V4 中才开始可以使用行级锁。之前，数据页是最小的锁定单元。I/T 行业中的许多人都假定行锁是并发性问题的灵丹妙药，但实际上，它并不能解决所有的并发性问题。在经历许多锁等待、死锁和超时的环境中，它也许提供了较大的改进。但在其他情形下，DB2 UDB 可能在获取更多锁上消耗资源，同时无法成比例地提高并发性。

因为 IRLM 获取、维护和释放行锁所需的处理与页面锁需要的大致相同，所以关于指定锁大小的决定其实就是在较高的锁定开销与并发性的潜在提高之间进行权衡。

因此，至于是使用页面锁还是使用行锁，这取决于您的数据和应用程序的特点。如果您觉察到使用页面锁定级别的表空间的数据页上存在大量竞争，那么就请考虑使用行锁。通过在行级别而非页面级别上进行锁定，可以极大地减少与其他应用程序进程的竞争，特别在访问是在随机的情况下。

但是，如果多个应用程序正以不同的顺序更新某一页上的相同行，那么行锁导致的竞争甚至可能比页面的还要多。这是因为，通过页面锁，第二个以及随后的应用程序在访问该页面之前，都必须等待第一个应用程序完成，而它们就可能超时。通过行锁，多个应用程序可以同时访问同一页上的行，但如果它们试图访问相同的行集，就可能死锁。

使用 LOCKSIZE TABLESPACE 或 LOCKSIZE TABLE 之前，用户必须相当确定没有其他重要的应用程序进程需要并发访问该对象。在任何表上指定 LOCKSIZE ROW 之前，极为明智的做法就是先对增加锁开销来提高并发性是否值得进行估计。

小型表

如果一个 DB2 UDB 表兼具尺寸小和高使用率的特点，那么就考虑使用 LOCKSIZE ROW，特别是每个页面中有许多行的时候。此外，因为表十分小，锁粒度将不会给锁开销带来较大的性能影响。

DB2 UDB 对象和授权的分组

通常总是将与同一应用程序逻辑相关的表分组到一个数据库中。理想情况是，每一个应用程序进程都引用尽可能少的 DB2 UDB 数据库。而且，要设法给用户不同的授权 ID 来使用不同的 DB2 UDB 数据库。实际上，这将增加可能应用程序进程的数目，同时可能减少每个应用程序进程可以访问的数据库数目。因此一般说来，“组合相似的事物”和“分开不同的事物”。

 

应用程序设计考虑

正如初始数据库设计一样，早在开发新的 DB2 UDB 应用程序之时就开始考虑并发性问题也很重要。更好的做法是，在实现之前，就将并发性原则包含到生产中去。然而，有时候并发性的提高可能取决于较新的 DB2 UDB 版本中的新功能以及与之接合的其他系