DB2 9中15个pureXML性能最佳实践

如果表上需要多个用户定义的XML 索引，那么通常更好的做法是在批量插入之前定义它们，而不是事后才创建它们。在插入期间，每个 XML 文档只被处理一次，便可以为所有 XML索引生成索引条目。然而，如果发出多条 “create index”语句，那么 XML 列中的所有文档将被访问多次。

“ALTER TABLE <tablename> APPEND ON” 为表启用追加（append）模式。新的数据被追加到表的末尾，而不是在已有的页面上搜索空闲空间。这可以提高批量插入的运行时性能。

增加日志缓冲池大小（LOGBUFSZ）和日志文件大小（LOGFILSIZ）有助于提高插入性能。这一点对于XML 插入尤其重要，因为每一行的数据量都比关系数据大得多。建议为日志使用快速的I/O 设备。

如果使用“ALTER TABLE <tablename> ACTIVATE NOT LOGGED INITIALLY” （NLI），可以避免日志记录。然而要注意，如果有语句遭到失败，那么表将被标记为不可访问，而且必须被删除。这一点将妨碍生产系统中进行NLI的增量批量插入，但是对于空表的初始填充比较有用。

在使用导入的情况下，如果为COMMITCOUNT参数采用一个较小的值，那么会不利于性能。每次提交 100 行或更多行比每次提交一行在性能上更好。也可以忽略 COMMITCOUNT参数，让DB2 按适当的频率进行提交。

为了更好地利用多个 CPU和磁盘，可以并发运行多个导入命令。但是应确保每个导入命令都是在它自己的数据库连接上运行的，并使用“ALLOW WRITE ACCESS” 子句以避免表被锁定。为运行并发导入，不需要分割输入文件（DEL 文件）。每个导入命令可以读取一个输入文件的不同片段，因为导入命令允许指定 “SKIPCOUNT m ROWCOUNT n”来读取输入文件中的m+1 到 m+n 行。

如果需要将非常多的小型 XML 文件从文件系统转移到一个 DB2 表中，那么将它们放在一个专用的、文件系统缓存被禁用的文件系统中有助于提高性能。由于每个文件只被读取和插入一次，因此缓存完全没有必要。在AIX 上，用-o cio 选项挂载这种文件系统被证明是有益的。

要获得更多关于插入性能的指南，请参阅文章 “Tips for improving INSERT performance in DB2 Universal Database”（见参考资料）。

总而言之，传统的插入和日志记录性能调优对于XML 插入和导入仍然适用。如果将ALLOW WRITE ACCESS 子句添加到每个导入命令中，则可以运行并行导入会话。

提示5：使用新的快照监视器元素检查XML性能

无论您是正在调查不同页宽的优点还是XML性能的其他方面，很可能都要像对于关系数据一样使用DB2 快照监视器。您将发现，与用于数据和索引的已有的计数器相对应，DB2 9 为XML数据提供了新的缓冲池快照监视器元素。由于关系数据和索引存储在表空间内不同的存储对象中，因此它们具有不同的读和写计数器。DDB2 9中的pureXML 存储为XML数据引入了一种新的存储对象，即 XDA，它也有自己的缓冲池计数器。

下面的例子是快照监视器输出的一个片段。可以看到用于三种不同存储对象（即数据、索引和 XDA）各自的快照监视器元素。这样便于单独针对 XML 监视和分析缓冲和 I/O 活动，而与关系数据互不影响。与 XML 索引有关的任何活动都被包括在已有的索引计数器中。新的XDA 计数器的解释与对应的关系计数器的解释相同。例如，如果XDA 物理读与 XDA 逻辑读的比率较低，则表明 XML数据的缓冲池命中率较高，这正符合期望。要了解关于缓冲池快照监视器元素的更多详细信息，请参阅 DB2 文档。

清单 2.数据、索引和 XDA 存储对象的监视器输出

Buffer pool data logical reads　　　　　　 = 221759
Buffer pool data physical reads　　　　　　= 48580
Buffer pool temporary data logical reads　 = 10730
Buffer pool temporary data physical reads　= 0
Buffer pool data writes　　　　　　　　　　= 6
Asynchronous pool data page reads　　　　　= 0
Asynchronous pool data page writes　　　　 = 6
Buffer pool index logical reads　　　　　　= 8340915
Buffer pool index physical reads　　　　　 = 54517
Buffer pool temporary index logical reads　= 0
Buffer pool temporary index physical reads = 0
Buffer pool index writes　　　　　　　　　 = 0
Asynchronous pool index page reads　　　　 = 0
Asynchronous pool index page writes　　　　= 0
Buffer pool xda logical reads　　　　　　　= 2533633
Buffer pool xda physical reads　　　　　　 = 189056
Buffer pool temporary xda logical reads　　= 374243
Buffer pool temporary xda physical reads　 = 0
Buffer pool xda writes
　　　　　　　　　 = 0
Asynchronous pool xda page reads　　　　　 = 97728
Asynchronous pool xda page writes　　　　　= 0
Asynchronous data read requests　　　　　　= 0
Asynchronous index read requests　　　　　 = 0
Asynchronous xda read requests　　　　　　 = 83528

总而言之， 快照监视器中新的XDA 计数器反映了 XML 活动。它们对于了解 XML数据的缓冲池、I/O和临时空间的使用情况很有用。

提示6：了解 XML 模式验证的开销

XML 模式可以定义一组 XML 文档所允许的结构、元素和属性、它们的数据类型、取值范围等。DB2 允许（可选地）根据 XML 模式验证 XML 文档。如果选择验证文档，那么通常是在插入时进行验证。这是为了达到两个目的。首先，通过验证可以确保插入到数据库中的数据符合模式定义，也就是说可以防止将“垃圾数据（junk data）” 输入到表中。其次，模式验证将来自模式的类型注释添加到每个 XML 元素和属性，这些类型在DB2 XML 存储中得到持久化。例如，如果一个 XML 模式定义 dept 表中的雇员 ID（如提示1 所示）为整数，并根据该模式对文档进行验证，那么 DB2 会记得，在每个文档中雇员 ID 具有类型 xs:integer。在查询运行时，尝试在雇员 ID 上执行字符串比较将遭到失败，并产生一个类型错误。

在XML解析期间，XML 模式验证是一个可选的活动。性能研究表明，如果启用模式验证，那么 XML解析通常要更密集地使用CPU。根据 XML 文档的结构和大小，尤其是根据使用的XML 模式的大小和复杂性的不同，这一开销相差很大。例如，您可以发现，由于采用中等复杂程度的模式进行模式验证，对 CPU的消耗增加了 50%。除非 XML 插入中 I/O 占极大一部分，否则增加的CPU 消耗通常会导致插入的吞吐量下降。

判断应用程序是否需要更严格地对 XML 查询进行类型检查，以及检查XML 模式的遵从性。例如，如果在将XML 文档存储到数据库之前，使用一个应用服务器来接收、验证和处理 XML 文档，那么可能不需要在DB2中对文档进行验证。此时，您已经知道它们是有效的。在这种情况下，应避免进行模式验证，以提高插入性能。但是，如果DB2数据库从不信任的地方接收XML数据，而又需要在DB2 上确保模式遵从性，那么就需要在这方面花费一些额外的CPU 周期。

总而言之，为提高插入性能，如果没有必要，应避免在DB2中执行模式验证。