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

提示 2：为了取得更好的 XML 性能，使用 DMS 和更大的页

数据库管理的表空间（DMS）可以比系统管理的表空间（SMS）提供更高的性能。对于关系数据是如此，对于 XML 的读和写访问更是如此。在 DB2 9 中，缺省情况下，新创建的表空间是 DMS。还建议将 DMS 表空间与自治存储一起使用，使 DMS 容器可以随需增长，而不需要人为干预。如果 XML 文档太大，一个表空间中的一个页面容纳不下，那么 DB2 就将该文档划分成多个区域，然后将它们分开存储到多个页面上。这一点对于应用程序而言是透明的，这也使得 DB2 可以处理 2 GB 的 XML 文档。

通常，每个文档划分成的区域越少，性能就越好，对于插入和全文搜索更是如此。如果一个文档大小超出了一个页面，每个文档分成的子块的数量取决于页宽（4KB、8KB、16KB 或 32KB）。表空间的页宽越大，每个文档划分成的子块数量就越小。例如，假设一个给定的文档要划分到 40 个 4KB 的页面上。那么，同样是这个文档，可以存储在 20 个 8KB 的页面上，或者存储在 10 个 16KB 的页面或 5 个 32KB 的页面上。如果 XML 文档远小于所选择的页宽，那么就不会浪费空间，因为多个小的文档可以存储在一个页面上。

经验法则是，为 XML 数据选择一个不小于平均预期文档大小的两倍而且不超过 32 KB 最大值的页宽。如果为关系数据和 XML 数据，或者为数据和索引使用单一的页宽，那么 32KB 的页宽对于 XML 数据而言可能有利，但是不利于关系数据和索引的访问。在这种情况下，16KB 或 8KB 的页宽对于两者而言都是较好的选择。

提示 3：必要时，如何将 XML 数据放入一个单独的表空间中

如果您做了性能分析，发现对于 XML 数据需要大的页宽，而对于关系数据或索引则需要小的页宽，那么可以使用不同的表空间来实现这一点。当定义一个表时，可以将 “long” 数据定向到一个具有不同页宽的单独的表空间中。long 数据包括 LOB 和 XML 数据。
下面的例子定义了两个缓冲池和两个表空间，一个表空间的页宽为 4KB，另一个表空间的页宽为 32KB。（注意，一个表空间总是要有一个缓冲池，且缓冲池要有一个匹配的页宽。）表 product 被分配到具有 4KB 页面的表空间 "relData"。它的所有列被存储在那个表空间中，只有 XML 列 "description" 存储在表空间 "xmldata" 中的 32KB 的页面上。

            create bufferpool bp4k pagesize 4k;
            create bufferpool bp32k pagesize 32k;
            

            create tablespace relData
            pagesize 4K
            managed by automatic storage
            bufferpool bp4k;
            

            create tablespace xmlData
            pagesize 32K
            managed by automatic storage
            bufferpool bp32k;
            

            create table product(pid bigint, name varchar(20), brand varchar(35),
            category integer, price decimal, description XML)
            in relData
            long in xmlData;

DB2 9 中的缺省表空间有所变化。除非显式指定，否则新创建的表空间都是具有较大行 ID 的 DMS。这意味着，一个具有 4KB 页面的表空间可以增长到 2TB，而不是 DB2 8 中的 64GB，具有 32KB 页面的表空间可以增长到 16TB，而不是 512GB。而且，每个页面 255 行的限制也去掉了，32KB 的页面上允许至多 2335 行。因此，每页的行数限制本身不再是为关系数据使用小型页面的理由。

总而言之，在为 XML 数据选择不同的表空间时，仍应按常理来考虑。更少的缓冲池和表空间，以及更少的页宽种类，可以导致更简单的物理数据库设计，从而更容易管理、维护和调优。因此，要避免引入多种页宽，除非您知道这样做确实可以带来性能好处。

提示 4：如何配置 DB2，以便快速地成块插入 XML 数据

DB2 9 支持两种将 XML 数据从文件系统转移到 DB2 表中的选项：插入和导入。从性能和调优的角度来看，这两种选项具有类似的特征，因为导入实用程序实际上是执行一系列的插入。不管是应用程序执行批量插入（可能通过并发插入线程），还是使用导入，下面的性能指南都适用：

• 务必使用具有较大页宽的 DMS 表空间（见 提示 2），这是一个关键的先决条件。
• 即使没有在要成批插入数据的表上定义任何索引，DB2 pureXML 存储机制仍然会透明地维护所谓的区域和路径索引，以便于进行高效的 XML 存储访问。因此，应提供足够的缓冲池空间来支持索引读操作。
• 如果表上需要多个用户定义的 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 子句添加到每个导入命令中，则可以运行并行导入会话。