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

简介

DB2 9 中的 pureXML 支持为管理 XML 数据提供了有效的、多方面的功能。对于很多 XML 应用程序而言，性能是高度优先考虑的一个方面。DBA 和应用程序设计人员都可以通过他们份内的工作来确保良好的性能。首先，我们有关于 DB2 各个方面的所有传统的性能指南，包括 CPU/内存/磁盘配置的平衡、表空间和缓冲池的调优、锁、日志记录、查询执行计划等。所有这些话题在之前的 DB2 文章里都曾论述过（见 参考资料），并在管理 DB2 中的 XML 数据时仍然适用。

本文将讨论和阐述 15 个 XML 性能提示（排序不分先后）。这 15 个提示涵盖了很多领域，但是经验表明，存在性能问题的应用程序通常只需要应用其中一两个提示就能达到所需的性能。

• 提示 1： 理智选择 XML 文档的粒度。
• 提示 2： 为了取得更好的 XML 性能，使用 DMS 和更大的页。
• 提示 3： 必要时，如何将 XML 数据放入一个单独的表空间中。
• 提示 4： 如何配置 DB2，以便快速地成块插入 XML 数据。
• 提示 5： 使用新的快照监视器元素检查 XML 性能。
• 提示 6： 了解 XML 模式验证的开销。
• 提示 7： 在 XPath 表达式中，尽可能使用全限定路径。
• 提示 8： 定义倾斜的 XML 索引，并避免为任何东西都建索引。
• 提示 9： 将文档过滤谓词放入 XMLEXISTS 中，而不是放入 XMLQUERY 中。
• 提示 10： 使用方括号 [ ] 来避免 XMLEXISTS 中的 Boolean 谓词。
• 提示 11： 使用 RUNSTATS 收集 XML 数据和索引的统计信息。
• 提示 12： 如何使用 SQL/XML 发布视图将关系数据暴露为 XML。
• 提示 13： 如何使用 XMLTABLE 视图以关系格式暴露 XML 数据。
• 提示 14： 对于短小的查询或 OLTP 应用程序，使用带参数占位符的 SQL/XML 语句。
• 提示 15： 避免 XML 插入和检索期间出现代码页转换。

在对这些性能提示的讨论中，我们假设您熟悉基本的 DB2 管理和性能实践，并熟悉基本的 DB2s pureXML 支持。例如，您应该知道 XML 列、XML 索引，以及如何用 SQL/XML 和 XQuery 查询 XML 数据。所有这些先决条件在 developerWorks 上之前发表的文章中都有论述（见 参考资料）。

DB2 XML 性能提示

提示 1: 理智选择 XML 文档的粒度

当设计 XML 应用程序和 XML 文档结构时，您可能面临将哪些业务数据放在一个单独的 XML 文档中的选择。例如，在下面的部门表中，我们为每个部门使用一个 XML 文档（中等粒度）。如果部门是应用程序访问和处理数据所依赖的主要粒度，那么这是合理的选择。或者，我们也可以决定将多个部门组合到一个 XML 文档中，例如，将属于同一个单位的部门放入一个 XML 文档中（粗粒度）。然而，如果通常一次只处理一个部门，那么这种粒度带来的性能就是次优的。

<dept deptID='PR27'>
                        <employee id='901'>
                        <name>Jim Qu</name>
                        <phone>408 555 1212</phone>
                        </employee>
                        <employee id='902'>
                        <name>Peter Pan</name>
                        <office>216</office>
                        </employee>
                        </dept>

<dept deptID='V15'>
                        <employee id='673'>
                        <name>Matt Foreman</name>
                        <phone>416 891 7301</phone>
                        <office>216</office>
                        </employee>
                        <description>This dept supports sales world wide</description>
                        </dept>

我们还可以决定为每个雇员使用一个 XML 文档（细粒度），并使用一个附加的 “dept” 属性，表明他或她属于哪个部门。如果雇员本身使用经常独立于同部门其他雇员被访问和处理的业务对象，那么这会是一个很好的选择。但是，如果应用程序常常一起处理一个部门中的所有雇员，那么每个部门一个文档会更好一些。

尤其是，我们不推荐将很多独立的业务对象成批地放入一个文档中。 DB2 使用 XML 数据上的索引对文档进行过滤。因此，XML 文档的粒度越细，从基于索引的访问中得到的好处就越大。而且，如果应用程序使用 DOM 解析器来摄取从 DB2 检索的 XML，那么小型文档可以带来更好的性能。

与 XML 文档设计相关的一个常见的问题是，何时使用属性，何时使用元素，以及这里做出的选择对性能有怎样的影响。与其说这是一个性能问题，不如说这是一个数据建模问题。这个问题像 XML 的先驱 SGML 一样古老，而且曾经历过热烈的辩论，只是最后也没有广泛地达成一致。然而，与此有关的一个重要事实是，XML 元素比属性更灵活，因为 XML 元素可以重复和嵌套。例如，在我们的部门文档中，我们使用一个 “phone” 元素，如果一个雇员有多个电话号码，那么可以让这个元素出现多次。而且，当以后需要将电话号码拆成数段时，这个元素还是可扩展的。即 “phone” 元素可以有表示国家代码、区代码、分机号等等的子元素。如果 “phone” 是雇员元素的一个属性，那么对于每个雇员，它只能出现一次，我们也不能为之添加子元素，这将妨碍模式随时间而变化。虽然不用属性也可以对所有数据进行建模，但是对于预先知道不会重复（对于每个元素而言），也没有任何子字段的数据项，使用属性仍是最直观的选择。属性有助于使 XML 变得更短，因为属性只需一个标记，而元素则需要一对开始标记和结束标记。在 DB2 中，查询、谓词和索引定义中都可以使用属性，就像使用元素一样容易。由于属性的可扩展性不如元素，DB2 可以应用某些存储和访问优化。这应该看作是额外的性能收益，而不是将属性转换成元素的决定因素，尤其是当数据建模确实倾向于使用元素的时候更是如此。

总而言之，应该根据预期的访问的主要粒度来选择 XML 文档的粒度。如果仍然心存犹豫，那么倾向于较细的粒度和较小的 XML 文档要稳妥些。