Paul Zikopoulos
高级专家, DB2 Competitive Technologies Team, IBM Toronto Lab
2005 年 7 月 28 日

了解关于 IBM® DB2® Universal Database™ (DB2 UDB) V8.2.2 如何通过一个自我安装、自我调优和自我配置的数据库来进一步缩短创造价值的时间（time-to-value）。本文是由三部分组成的一个系列中的第 2 部分，该系列深入研究 DB2 V8.2.2 带来的新功能、新特性和优点（以及一些打包更改）。第 1 部分 谈到一些新特性，并总结了 DB2 V8.2.2 在打包和许可方面的变化。第 2 部分深入研究能为所有应用程序提高 DB2 性能的一些增强，并谈到能促进应用程序的并发性的一些特性。

简介
在 2005 年 4 月下旬，IBM 发布了最新版本的 IBM DB2 Universal Database for Linux, UNIX® and Windows® (DB2) 产品，即 DB2 V8.2.2（对于那些习惯于 Fix Pack 命名惯例的人，该产品就是 Fix Pack 9）。

这个最新的版本以 DB2 V8.2 版（之前也称作“Stinger”）为基础，拥有很多好的新特性，这些新特性得益于 SAP 与其客户之间的重要关系。实际上，DB2 V8.2.2 标志着与 SAP 更紧密关系（双方的关系已经保持了 10 多年）的开始，SAP 在 DB2 和 SAP 之间作出大量的承诺，以扩展各方面的业务，包括销售、营销和开发。

您不是 SAP 客户并且疑惑 DB2 V8.2.2 如何可以带来帮助？除了作为 470 亿美元企业应用软件市场中的领头羊，SAP 还拥有 26,000 多位客户，运行着 88700 多个 SAP 软件安装。从用于解决中小型公司需求的不同解决方案到企业级（enterprise-scale）解决方案 —— 即使您不是一位 SAP 客户，也可能会具有相同的兴趣列表（wish-list）。我的意思是，有谁不想要产品更易于使用，具有更少的锁定竞争，最少化存储管理，更易于访问管理数据等呢？十分坦白地说，从来没人问过我 IBM 是否可以使 DB2 更慢一些，或更难于使用，或不那么可用 —— 您应该已经明白了。

现在更是如此，标记 V8 已经逐渐开始代表一种平台，借由该平台，对于您选择用于编程的任何大型机语言，都可以通过引导开发人员的生产力来降低成本，通过自安装、自我调优、自我修复和自我配置数据库来拉平创造价值的时间曲线，而在许多平台上，这一切都是构建在具有卓越性能的高可用、可伸缩的数据库引擎之上的。

在本系列的 第 1 部分，我写到了从数据库管理员（DBA）的角度来看，DB2 V8.2.2 带来的新功能、新特性和优点。

在本系列的第 2 部分，我将深入研究 DB2 V8.2.2 中能提高性能和并发性的一些增强，并说明布丁好不好，吃了才知道这个道理，而 DB2 V8.2.2 的性能结果就是“好吃的布丁”（老实说，这部分真值得自夸一番）。然而，我不会为 DB2 V8.2.2 产品取得的性能结果而欢呼。在本文中，我还将带您考察为锁和多维集群（multi-dimensional clustering，MDC）表实现的一些特定的增强。

第 3 部分是本文的最后一个部分，在这一部分我将谈到用于 Windows 平台的一些特定的增强，并留出一个内容混杂的小节，谈谈我最后想说的一些话。

性能 - 自夸的资本
在谈到那些能提高 DB2 V8.2.2 性能的各种新特性之前，我想和您一起看一下在开放标准基准下 DB2 V8.2.2 取得的性能结果。人们常常关心可以做什么事情，而不是里面有什么东西。如果您不属于那样的人，那么这一节正好适合您（我的意思是，您是否关心牙医在您嘴里使用的钻子是什么类型？）大多数读者阅读这个知识领域是为了获得技术上的细节，所以在本文后面的小节中我首先会给出那样的细节。我只是想让您知道本节中的大概内容 —— 但是我必须说它的确令人印象深刻。

在赛马运动中，三冠王（Triple Crown）只授予在一年中惟一赢得三项顶级赛事（Kentucky Derby、Belmont 和 Preakness Stakes）的人。这项技艺难度颇高，在过去 86 年当中，只有 11 次有人获得三冠王的殊荣。

同样令人印象深刻的还有数据库性能三冠王（Database Performance Triple Crown）。这个奖项由最令人关注的三个性能基准组成：

• TPC-C - Industry Standard Transaction Processing 基准
• 10TB TPC-H - Industry Standard Ad Hoc Data Warehousing 基准
• 3-tier SAP SD Standard Application Benchmark - 现实中的 ERP 性能基准

在这些基准的历史中，DB2 是惟一能同时在三项性能结果中领先的数据库（我们多次取得这样的成就）。为什么这是值得关注的成就呢？每项基准都有其惟一的特征，所以一家数据库供应商很难同时在这三项基准中领先，每项基准都要求非常尖端的能够跨所有类型的不同工作负载和需求的数据库管理系统。

TPC-C
TPC-C 是一种 OLTP 基准，要求有效地使用大量内存，大量的随机 read/write I/O，并且有很密集的数据库日志活动。在本文编写之际，DB2 结果（在 $5.19/tpmC 的价格性能比下取得 3,210,540 tpmC）在性能上彻底超出 Oracle 的两倍，而价格性能比方面也同时好于 Oracle 10g 和 Oracle 10g RAC。DB2 V8.2.2 结果几乎超出了 SQL Server 2005（该产品甚至还是不可用的，并且在 DB2 结果出来 7 个月之后才有结果）3 倍以上，在价格性能比上 DB2 V8.2.2 也仍站占优势。老实说，之前没有任何数据库供应商在此基准中能有如此决定性的领先优势。实际上，DB2 结果比 Oracle 10g 和 SLQ Server 2005 加起来产生的结果还要好！更令人吃惊的是，DB2 提供了从 16 路 SMP 服务器到 64 路 SMP 服务器的 99% 的线性可伸缩性。

图 1 展示了在本文编写之际，来自每个数据库供应商的 TPC-C 结果排名：

图 1. 本文发表之际的 TPC-C 结果排名

TPC-H
相反，TPC-H 是一种数据仓库基准，它要求能够有效地执行复杂查询。用于该基准的数据库必须有 10TB 的原始数据，并且有高效的磁盘扫描和表连接算法。Tradata 不再以 TPC-H 为基准，因为我相信我们不会同意，而 SQL Server 在此度量中没有任何结果。Oracle 有结果。

当比较 TPC-H 10 TB 结果时，您将注意到，DB2 V8.2.2（在 8 8-路 p5 575 服务器上）交付了历史上最高的 TPC-H 基准（在本文编写之际）。在 104,100 QphH@10TB 中，即使 DB2 只使用一半数量的 CPU，获得的性能仍然比 Oracle 10g RAC 结果的性能高出 20%。DB2 和 pSeries 不仅在性能方面有压倒性的竞争优势，而且DB2 结果以 $61/QphH@10TB 的成绩在价格性能比的比拼中名列前茅，该成绩比 Oracle RAC 价格性能比结果要好 2.6 倍以上。

图 2 展示了 DB2 和 Oracle 在 TPC-H@10TB 度量上的比较：

图 2. Oracle 和 DB2 在 TPC-H@10TB 度量上的比较

SAP 基准
除了前两节中提到的两个业界标准基准，3-层 SAP SD 标准应用程序基准代表了 ERP 基准事实上的标准。要取得领先的 SAP 性能，必须有突出的可伸缩性，并且在复杂的应用程序逻辑与数据库之间要有紧密的连接。IBM 最近宣布了 DB2 V8.2.2 的交付，该产品特别为 SAP 应用程序进行了优化（这就是您正在阅读本系列的原因）。在该基准上的领先结果进一步证明了 IBM 作出的 SAP 应用程序与 DB2 集成的承诺，DB2 V8.2.2 中的特性对这一结果做出了很大的贡献。

DB2 UDB V8.2.2 在这里同样显示了其性能优势。在 2005 年 5 月 15 日，在一个 32 路 p5 595 上运行的 DB2 在 3-tier SAP SD Standard Application Benchmark 方面的结果超出了 Oracle 一大截。DB2 只使用一半数量的 CPU，取得的结果仍然比 Oracle 结果要好 68%。不要忘了，客户是根据 CPU 数量来为软件付费的，所以每个 CPU 交付比 Oracle 好 3.3 倍以上的性能意味着 DB2 客户可以节省大量的金钱，并取得更高水平的可伸缩性。我甚至不必提到这样一个事实：DB2 比 Oracle 几乎领先了两年时间（这是基准测试的一个周期），而 Oracle 要赶上旧的 DB2 领先结果，只有等待两年（这是硬件换代速度）和加倍系统上的资源。至于 SQL Server，我们已经很久没有看到它有什么动静了。

图 3 总结了 DB2 之类适用于SAP数据库交付的在不同 SAP 基准下的领先结果：

图 3. DB2 和 SAP 性能基准领袖

注意，在 2-层领域，Oracle 领先 5% 左右，Oracle 比 DB2 多使用了一倍的 CPU 才获得 5% 的性能优势。记住，您要为所有那些 CPU 付费！

性能增强
在 V8.2.2 中，有很多工作都是围绕着提高 DB2 上的性能。其中很多东西是您无需考虑的 —— DB2 将替您打点。

不需要关心的新特性 - 尽管享受性能提升
最棒的一点是，您无需了解如何使用 V8.2.2 中很多有助于取得上一节中提到的基准结果的特性 —— 它们是透明的。例如，DB2 V8.2.2 提供了一些增强，以便在运行 AIX 或 Linux 操作系统时更好地利用 Power 5 架构。DB2 V8.2.2 还包括：

• 对 logger 的微调，以使得它更高效，并提高 OLTP 应用程序的性能。
• 减少锁管理器的 hash 表中对行和表锁的虚假锁竞争。
• 更高效的日志记录生成过程。
• 在访问计划的编译和优化阶段提供更好的 UNION 处理。

但是有很多特性是您的确可以控制的，在本节的后续部分我将谈到这些特性。

Range Clustered Table
DB2 V8.2.2 enhances Range Clustered Table (RCT) 最先是在 V8.1.4 中引入的，带有一个 percent-free 选项，该选项可用于常规的 DB2 表。

RCT 是一种采用特定方法组织表中各行的表，通过一个带有连续数字键值或者由多个有连续数字键值的列组成的主键，可以快速地直接访问任何给定的一个行或一组行。连续数字在 OLTP 类应用程序中常常用于生成关系模型所需的主键。这恰好是该特性的目标市场。由于大大降低了 I/O，减少了所需的缓冲池内存，与常规的 B-树索引相比其代码路径也更少，因此这种方法在查询处理期间可以获得显著的性能优势。该技术的另一个好处是节省磁盘空间，因为其索引结构更小。

最后，数据的集群受到保障，数据不会又变成非集群状态，在 OLTP 系统中就常常会出现这种情况。这样一来，当键值不是很稀疏的时候，就可以获得非常高效的范围搜索。为实现一定百分比的预留空间，和常规表一样使用相同的语法，即在创建表时使用 PCTFREE 选项。通过使用该选项，可以在表中引入空闲空间，以减少页面争用，从而减少单页上的行数。您可以在 0-99% 之间设置 PCTFREE（它被存储在 SYSIBM.SYSTABLES 表的 PCTFREE 字段中）。用于 PCTFREE 和 RCT 的默认值是 0，之前创建的所有 RCT 的 PCTFREE 值自动为 0。当为一个表设置了这个值后，就不能再改动了。

图 4 展示了分别使用 DB2 V8.2.2 之前版本以及使用 DB2 V8.2.2 的情况下，数据库引擎在用 PCTFREE 选项创建一个 RCT 表时的行为：

图 4. DB2 V8.2.2 中的 RCT 支持 PCTFREE 选项

MDC rollout
在下一个版本的 SAP BW 产品中，Fact 表将使用多维集群（multidimensional clustering，MDC）表来存储数据。（在 Oracle 和 Informix 上，SAP BW 为这种表使用范围分区。）当与包 ID 相关的行不需要时，SAP 需要一种快速而有效的机制来从表中删除该数据。对于范围分区，简单地从一个表中删除该数据不属于 logged 操作，因此非常快速而有效。

Rollout 是指将一组相关的数据作为一个单元一起删除，涉及很少的日志记录，并且不必逐行删除。对于 MDC 表，数据根据维值被组织到块中。这种组织便于沿着维线非常有效地 rollout 数据。特别地，当删除与表中一个或多个切片相符的一定范围的值时，可以使用 rollout。

DB2 V8.2.2 引入了一种新的 DELETE 算法（称为 MDC rollout），在这种算法中，对 MDC 表的 DELETE 操作需要很少的日志记录，因此像范围分区一样非常快速。DB2 V8.2.2 中这种新的 DELETE 算法可以显著减少与 MDC 表中行及其相应的块索引的删除相关的日志记录和处理。当启用了该算法时，对于相同工作单元中随后的 INSERT 操作，删除块不能被相同的事务重用。

DB2 优化器根据表的某些特征来决定使用 rollout 算法还是使用常规的逐行（以下称作传统）算法来执行 DELETE。例如，新算法可用于涉及带有 SQL 复制（支持表上的数据捕获变化）的 MDC 表的 DELETE 操作，但是不能用于要求用于行移动的‘内部’ MDC DELETE 的操作。DB2 文档中包含了完整的细节，但底线是 DB2 将为您选择最佳的可用方法。

如前所述，当应用程序需要一个 DELETE 操作时，DB2 优化器将决定该操作适用于传统 DELETE 操作还是 rollout DELETE 操作。如果 DELETE 涉及表中所有的行（没有 WHERE 子句：DELETE FROM T1），或者 WHERE 子句中的所有谓词都在 MDC 表的一个维列上，则可以使用 rollout 算法。

当 DELETE 适用于 rollout DELETE 时，DB2 执行以下操作：

1. 获得块上的一个独占（X）锁。
2. 更新块中的每个页，使之看上去为空（物理数据仍然在，但是它们的 slot 目录项被设为已删除）。
3. 将该块标记为 ROLLEDOUT。
4. 记录并删除 MDC 表的块索引中的块索引（BID）索引项。

用于 MDC 表的这种增强提供了以下好处：

• 更快的数据块删除 - 如果没有行级的处理要做（没有 RID 索引，也没有 LONG/LOB 字段数据），那么这种删除可以很快。
• 减少日志记录（在页级执行，而不是在行级执行） - 不过对于 RID 索引键或 LONG/LOB 字段的删除不是这样。
• 多维 - 现在可以转出 MDC 表中任何维上的数据。例如，您可以转出切片或切片的任意交点。
• 自治 - DBA 不需要显式地执行 rollout，每当 DB2 优化器确定整个单元中的内容都将被删除，并且这个表适用于这种算法时，DB2 会自动为 SQL DELETE 语句执行 rollout。

DB2 Explain 工具将指出 rollout 算法何时被用于按照术语 Cell Delete 而不是 Delete 来执行一个 DELETE。在 EXPLAIN_OPERATOR 表中，OPERATOR_TYPE —— 类型为 CHAR(6) —— 将为 CELDEL，如下面的图 5 所示：

图 5. 在 DB2 V8.2.2 中识别 MDC rollout 操作

如果请求一个 DELETE 的事务如期发生回滚，那么索引项将被重插，所有其他的变化被恢复到之前的值（换句话说，您将不需要重新将数据插入到表中，因为数据仍在表中）。

为了避免由于被删除页上缓存的 RID 而导致一个事务中被推迟的 fetch 操作未能返回在另一个事务中被删除的行，rollout 事务清除每个页上的 slot 目录，只为每个页保留一个日志记录，用以记录 slot 目录的内容。

为了进一步减少日志记录，我们建议应用程序在 rollout 和 rollin 操作时间提交（COMMIT）事务，以便充分利用空间并减少日志记录。当 DB2 碰到对 MDC 表的 INSERT 操作时，它寻找一个空闲的块。然而，如果一个特定的块计划要被删除，那么它被标记一个 ROLLOUT 位，在那个位被清除之前不能重用（即使是相同的事务也不行 —— 这是为了确保可恢复性）。当事务提交之后，被删除的 MDC 块便可以被重用，因为在回滚事件中那个块不需要保持（DELETE 操作不作日志记录，所以必须从某个地方获得 undo 信息）。

通过将 DB2_MDC_ROLLOUTM 注册表变量设置为 YES（虽然 1、Y 或 ON 都可以，但我们建议使用文档中给出的设置），可以启用该特性。DB2 在编译时而不是运行时检查该变量。因此，如果您想在一条语句被编译之后禁用或启用 MDC rollout，那么必须重新编译该语句，才能使更改生效。然而，这个注册表变量只能在实例启动时生效，所以，如果您想修改 DB2 在 MDC 表上的删除操作方面的行为，必须重新启动实例。

MDC rollin
新版本的 SAP BW 产品为所有 Fact 表使用 MDC 表。在 SAP BW 中，F-Fact 表包含按包 ID 组织和插入的行。DB2 V8.2.2 为 MDC 表提供了对 INSERT 算法的增强，通过添加为需要新块的 INSERT 操作的 MDC 表使用块锁、而不是行锁的能力，取得了更好的性能。由于被插入到 MDC 表中的所有新行在表中都是新的单元，因此这种能力是可能的。

您可以通过设置一个 MDC 表的 LOCKSIZE=BLOCKINSERT 来为 MDC 表启用该特性。这将导致在 INSERT 操作期间发生块级的锁，行级的锁则被用于所有其他操作。由于增强的 MDC INSERT 性能特性是通过指定它作为一个表的 LOCKSIZE 参数上的一个选项来实现的，这意味着它可以在每个表上启用。

一个表的 LOCKSIZE 属性（只在 ALTER TABLE 语句 上可用，所以为了启用该特性，必须先创建表，然后修改表）指定当表被访问时使用的锁的粒度。您可以将一个表的 LOCKSIZE 设为以下三个值之一：ROW （行级锁）、TABLE （表级锁）或BLOCKINSERT （只用于 MDC 表，这就是为一个表启用该特性的方法）。当在一个 MDC 表上指定 LOCKSIZE=BLOCKINSERT 时，对于除了 INSERT 之外的所有操作，将执行行级锁，对于 INSERT 操作 DB2 将执行块级锁。例如，为了启用该特性，可以使用 ALTER TABLE ... LOCKSIZE=BLOCKINSERT 命令。

特别地，设置 LOCKSIZE=BLOCKINSERT 表明，在 INSERT 操作期间，DB2 应该为 MDC 表使用块锁而不是行锁。如果您尝试修改一个表，以便使用这种锁粒度选项，而那个表又不是 MDC 表，那么您将收到一个 SQLSTATE 628N 错误。

这种新的锁机制对于插入大型数据到单元中的事务很有用，这些事务将数据插入到它们各自的单元中，而不同于一次插入到相同的表中的其他事务。对于 MDC 表，选择 BLOCKINSERT 可以提高 INSERT 操作的性能，因为使用的是块级的锁，避免了为 INSERT 操作使用行锁。与此同时，将数据插入到相同单元（而不是插入到拥有相同维特征的不同单元）的事务仍可以并发地插入到单元中。由于该特性提高了 INSERT 的性能，所以它还有利于执行这种操作的实用程序，例如使用 IMPORT 实用程序来填充 MDC 表。

当事务将大型数字插入到只读表上拆开的单元中时，我们建议为 MDC 表启用该特性，因为它可以减少数据库活动所需的锁的数量。此外，即使没有该特性，我们建议经常执行 COMMIT 操作，以释放被持有的锁。对于含有多个执行到不同单元的 INSERT 的事务的应用程序，它们最能从这些新特性中获益。除了 INSERT 外的所有其他操作将使用表、块和/或行锁。

实际上，当该特性被启用，并且 INSERT 操作要求一个新的或重用的块时，DB2 将在块上采用一个独占的（X）锁，以便将它添加到目标单元。在此情况下，DB2 不会降低 X 锁的级别，从而可以在 INSERT 操作期间消除行级锁。在事务期间，X 锁一直保持。实际上，在 INSERT 期间惟一保持的行级锁是 next-key 锁，这个锁用于使 INSERT 不会添加键到可重复的读扫描器。这些 next key 锁只有在 key INSERT 发现带有 Repeatable Read (RR) 隔离级别的扫描器在索引中的 next-higher 键上有一个行锁时才能获得。

用于分区数据库环境的服务器辅助客户机重路由
和目标数据源于同一个分区的一个分区 DB2 数据库上的事务，与那些连接到正确分区的事务相比，需要更长的执行时间（在中断 SQL 语句并将其发送到数据所在的分区，然后将结果集返回到协调节点时，有一定的开销）。对于某些应用程序，尤其是事务性的应用程序，这种开销会成为获得最佳性能的障碍。

对于与 IBM WebSphere® Application Server 交互、由后者处理对一个分区 DB2 数据库的请求的应用程序，连接到数据所在的数据库分区的能力是获得良好性能的关键。为获得最佳性能，客户机应用程序需要被路由到存放目标数据的分区。

DB2 UDB V8.2.2 能够在将事务重路由到适当分区的过程中获得服务器的辅助（该特性在 WebSphere Application Server 到数据库的连接上被启用），从而可以限制地提高那些通过 WebSphere Application Server 路由到分区 DB2 数据库的应用程序的性能。当该特性被启用时，DB2 将通过确认用于执行的目标数据在当前分区上，而为在任何工作单元中执行的第一个请求提供服务器帮助。如果当前分区没有数据，那么就会有错误（SQL-55555E，包括最佳分区的一个主机名标记）返回到应用程序，表明应该使用哪个分区（最佳分区）。从这里，WebSphere Application Server 将把对数据的请求（以及在 UOW 中所有随后的请求）重新分发到 DB2 发现的存放数据的分区。

这种功能依赖于 JCC 客户机，并通过连接语句上的一个属性来启用。

在 DB2 服务器端，只有当它收到第一个非 XA、EXEC SQLSET、PREPARE 或 DESCRIBE 操作并且目标分区不是最佳的时候，才发出一个重定向错误。当发出 SQL-55555E 错误时，DB2 服务器将把关于最佳分区的信息放在 SQLCA 中（如前所述），并撤销自己在 XA 事务中的注册（如果它是其中一部分的话）。

在客户端，SQL-55555E 被拦截，并建立到包含数据的最佳服务器的连接 —— 客户机不需要多任何事情来处理错误。

对于逻辑分区，自动客户机重定向是不可行的。在使用逻辑分区的环境中，事务被重定向到物理分区上发现的第一个逻辑分区。这意味着当该特性用于一个大规模并行处理环境（MPP）时，事务将被路由到适当的物理节点，但是不一定是适当的逻辑节点。最终的结果是节省了与错误物理分区通信的开销，但是仍存在分区间通信的成本（不过仍然比不使用该特性要获得更好的性能）。

只有 UOW 中的第一条语句被用于判断是否应该将语句重路由到另一个分区。如果第一条语句是“可路由的”，那么那条语句和 UOW 中所有随后的语句都将路由到发现的“最佳”分区。如果第一条语句由客户机首先连接到的分区上的协调器执行，那么即使 UOW 中随后的语句是可路由的，客户机重路由都不会发生，UOW 中的这条语句（以及所有随后的语句）由客户机首先连接到的分区上的协调器执行 —— DB2 V8.2.2 之前的行为。在 DB2 文档中可以了解更多关于哪些类型的事务是可路由的、哪些类型的事务是不可路由的方面的信息。

并发性的增强
在 DB2 V8.2.2 中，DB2 对数据库管理器的并发性和锁属性有一些新的控制，并且对已有的一些控制有所增强。在这一节中，我将谈到可以用来修改 DB2 V8.2.2 为某些隔离级别而使用的 ANSI 标准锁机制的一些主要控制。这里警告一句，如果您打算使用这些控制的话，那么应该确信您了解自己的应用程序，并且这些控制的确适用（如果您不知道那是什么意思，那么就不要用）。

读扫描器可以忽略非提交的 INSERT
DB2 遵从用于以下隔离级别的带表锁及行锁的并发控制的 ANSI 标准：

• Uncommitted Read (UR)
• Cursor Stability (CS)
• Read Stability (RS)
• Repeatable Read (RR)

UR 隔离级别指示 DB2 处理记录并基于未提交的数据返回被请求的结果集 —— 这里将执行行锁。被读取、计算和处理的行可以提交，也可以不提交 —— 但更重要的是防止新的行被插入到语句可以考虑的行范围之中。扫描器使用 RR 隔离级别读取的所有行都被上锁，直到工作单元（UOW）结束，现在可以将新的行插入（通过其他事务）到被读取的行的范围。

目前，很多应用程序必须只考虑和处理提交的数据 —— 这消除了使用 UR 隔离级别的可能性。例如，银行事务不能使用 UR 隔离级别，否则帐户可能很快就会透支。RR 隔离级别非常严格，通常不是必需的，尤其是对于很多 ISV 应用程序，例如 SAP 和 PeopleSoft。这样就剩下 CS 和 RS 这两种隔离级别 —— 当处理只需要提交的数据时，这两个级别是使用最广泛的。

DB2 在执行索引或表扫描时，如果遇到一个被另一个事务独占 (X) 锁定的未提交行，那么 DB2 将阻塞在行锁上。如果这个行锁在保护一个未提交的 UPDATE 或 DELETE 动作，那么 DB2 不能处理或忽略该行，直到变化的结果已知。因此，CS 和 RS 隔离级别必须只处理提交的数据，而不允许忽略未提交的数据（除非一些注册表变量允许它们这么做，例如 DB2_SKIPDELETED 或 DB2_EVALUNCOMMITTED：未提交 DELETE 的提交版本是在它的预删除状态中的行，而未提交 UPDATE 的提交版本是行的预更新版本，除非发生回滚，否则这两样都是未知的。）

虽然当一个行由于一个未提交的 INSERT 而被锁的时候，这种行为是正确的 —— 但是有些情况下应用程序的所有者希望 DB2 忽略正在等待提交的被插入的行，就好像它不在一样（由于未提交 INSERT 的提交版本现在根本没有行，所以这是可能的）。例如，随着 Business Activity Monitoring 或 FOSH 记分卡的出现，C-级管理人员正在寻找越来越时新的信息。虽然 FOSH 记分卡的 Sales 部分将基于它的总值返回一个 红/黄/绿灯，但是在宏观级别上查看销售活动（例如全球销售）时，遗漏一份订单是可以接受的。

DB2 V8.2.2 为使用 CR 和 RS 隔离级别的应用程序引入了只读扫描器的能力，以便忽略还没有被其他事务提交的插入记录。这种新功能为并发添加了更多的灵活性，从而有助于一些应用程序的可伸缩性。为了在 DB2 V8.2.2 中启用这项新特性，可以使用 DB2_SKIPINSERTED 注册表变量。虽然 DB2 可以逐条语句地更新语句上的隔离级别，但没有提供在每条语句的级别上忽略未提交 INSERT 的能力，该设置是在编译/绑定时考虑的。

在 DB2 V8.2.2 中，DB2_SKIPINSERTED=OFF 是默认设置。这使得 DB2 的行为和预期的一样：扫描器一直等到 INSERT 事务提交或回滚，然后返回数据 —— 这和平常一样。取决于您的应用程序以及和业务函数相关的数据完整性的特征，这样可能合适，也可能不合适。例如，考虑一个涉及两个应用程序的业务流程，这两个应用程序使用相同的一个表来交换业务信息 —— 例如，一个信任应用程序和 credit vulnerability scoring 引擎。应用程序 A 基于一个 Web 表单将数据插入数据库，应用程序 B 读这些数据。为了加快信任审批的速度，由于候选者通过信任应用程序表单转移，信息块通过表单中的 'Steps' 被发送到应用程序 B（通过公共的表）。当候选者完成应用程序流程中的每个步骤时，信息被发送。在这个环境中，数据必须由第二个应用程序按照表中给出的顺序来处理，以便当接下来要读的行要被应用程序 A 插入时，应用程序 B 必须等待，知道 INSERT 被提交。

如果设置 DB2_SKIPINSERTED=ON，DB2 将把未提交的 INSERT（只对于 CS 和 RS 隔离级别）看作它们还没有被插入。该特性增加了并发性，同时又不牺牲隔离语义。DB2 为扫描器实现了这种能力，通过锁属性和锁请求的反馈，使其忽略未提交的插入行，而不是等待。您可以在快照输出中查看 INSERT 锁属性。

增强的 evaluate uncommitted
DB2 V8.1.4 引入了 DB2_EVALUNCOMMITTED DB2 注册表变量。当它被启用（=TRUE | ON | YES | 1）时，它将修改 DB2 中只读查询的行为，使之允许在索引扫描（必须是 Type 2 索引，对于 Type 1 索引该特性不受支持）或表访问（该特性在 Range Clustered Tables 上不受支持）时推迟锁，直到限定语句的所有谓词都是已知的。引入这个新的注册表变量是为了可选地提高一些应用程序的并发性，其实质是允许读扫描推迟或避免行锁，直到适合特定查询的一个数据记录成为已知。特别地，该特性是由 SAP 应用程序驱动的，但是通常也适用于更多客户的锁避免机制。

在 DB2 V8.1.4 之前（并且没有设置这个注册表变量），DB2 将执行保守式的锁：在验证行是否满足查询的排除谓词之前，它将锁定每个被访问的行。不管数据行是否被提交，以及根据语句的谓词它是否被排除，对于索引扫描和表访问都执行这样的锁定操作。考虑一个简单的例子，例子中有两个以 表 T1 为目标的语句 —— CREATE TABLE T1 (C1 INT) 。第一个语句 DB2 +C INSERT INTO TABLE T1 VALUES (1) 阻塞所有其他的扫描器，因为它持有行上的锁，而第二个语句 DB2 SELECT * FROM T1 将被阻塞，直到事务 1 提交或回滚。但是我们假设第二个语句是 DB2 SELECT * FROM T1 WHERE C1=2。在此情况下，即使事务 2 与列 C1=1 中的任何值（还没有被提交）都没有关系，它也仍将被阻塞。在 DB2 中，默认情况下将发生这一系列的事件，因为默认的隔离级别是 Cursor Stability (CS)，这种隔离级别表明，一个查询访问的任何一行在游标定位到该行时都必须被锁定。在语句 1 释放它用于更新表 T1 的锁之前，语句 2 不能包含表 T1 第一行上的锁。如果 DB2 知道值 C1=1 不是语句 2 的数据请求的一部分（换句话说，它在锁行之前计算了谓词），就可以避免阻塞，这是合情合理的，因为语句 2 将不会尝试锁定表中的第一行。

当您的 DB2 环境中启用了 evaluate uncommitted 行为时，您应该清楚，谓词计算可能发生在为提交的数据上。而且，在表扫描访问中，被删除行被无条件忽略，而对于 type-2 索引扫描，被删除的键不会被忽略（除非您还设置 DB2_SKIPDELETED 注册表变量）。如果您要在环境中单独设置 DB2_SKIPDELETED 注册表变量，DB2 将允许在表扫描访问时无条件地忽略被删除行，并忽略 type-2 索引扫描访问的伪删除索引键。

DB2 V8.1.4 中的实现是完整的。当 evaluate uncommitted 第一次在 DB2 V8.1.4 中引入时，它带有以下限制：

• 该特性只能用于 CS 和 RS 隔离级别。
• Sargable 谓词必须存在，以便计算。
• 锁避免不适用于编目表上的扫描。
• 当扫描一个 MDC 表时，对于索引扫描，块锁可以推迟。然而，对于表扫描，块锁不会推迟。
• 被推迟的锁不会发生在正在执行在线表重组的表上。
• Index Manager 不可能在没有锁行的情况下回调 Data Manager 来取数据记录。这意味着 ISCAN-Fetch 计划不能在 Data Manager 中推迟锁（惟一的例外是对一个 MDC 表的块索引，它的 Index Evaluation 谓词是一个 ISCAN 计划。）

DB2 V8.2.2 通过去掉 DB2 V8.1.4 中第一阶段的 Evaluate Uncommitted，改进了这些缺点。DB2 V8.2.2 引入了名为 DEFERISCANFETCH 的注册表变量，作为 DB2_EVALUNCOMMITTED 的新设置。启用该变量时，由该特性承担的锁避免将使用 ISCAN-FETCH 数据计划。

结束语
DB2 V8.2.2 有很多增强，现在我们真正开始研究这些新特性。在本系列的第 3 部分中，我们将关注 Windows 平台、一些开发方面的增强，并通过一个小节谈一些零散的东西，例如服务工具等。