登录
无论您是正在调查不同页宽的优点还是 XML 性能的其他方面，很可能都要像对于关系数据一样使用 DB2 快照监视器。您将发现，与用于数据和索引的已有的计数器相对应，DB2 9 为 XML 数据提供了新的缓冲池快照监视器元素。由于关系数据和索引存储在表空间内不同的存储对象中，因此它们具有不同的读和写计数器。DDB2 9 中的 pureXML 存储为 XML 数据引入了一种新的存储对象，即 XDA，它也有自己的缓冲池计数器。
下面的例子是快照监视器输出的一个片段。可以看到用于三种不同存储对象（即数据、索引和 XDA）各自的快照监视器元素。这样便于单独针对 XML 监视和分析缓冲和 I/O 活动，而与关系数据互不影响。与 XML 索引有关的任何活动都被包括在已有的索引计数器中。新的 XDA 计数器的解释与对应的关系计数器的解释相同。例如，如果 XDA 物理读与 XDA 逻辑读的比率较低，则表明 XML 数据的缓冲池命中率较高，这正符合期望。要了解关于缓冲池快照监视器元素的更多详细信息，请参阅 DB2 文档。
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 和临时空间的使用情况很有用。
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 中执行模式验证。
假设有一个包含 XML 列的表
create table customer(info XML);
|
<customerinfo Cid="1004">
<name>Matt Foreman</name>
<addr country="Canada">
<street>1596 Baseline</street>
<city>Toronto</city>
<state>Ontario</state>
<pcode>M3Z-5H9</pcode>
</addr>
<phone type="work">905-555-4789</phone>
<phone type="home">416-555-3376</phone>
</customerinfo>
|
如果要检索客户的电话号码或他们所居住的城市，无论使用 XQuery 还是 SQL/XML，都有多种可能的路径表达式可获得该数据。通过 /customerinfo/phone 和 //phone 都可以获得电话号码。同样，/customerinfo/addr/city 和 /customerinfo/*/city 都返回城市。为了得到最佳的性能，使用全限定路径比使用 * 或 // 更可取，因为使用全限定路径可以使 DB2 直接导航到所需的元素，而忽略文档中不相关的部分。
换句话说，如果您知道所需的元素位于文档中的什么位置，那么以全限定路径的形式提供位置信息会比较有帮助。如果请求 //phone 而不是 /customerinfo/phone，那么就是在请求文档中任何地方的 phone 元素。这需要 DB2 向下导航到文档的 "addr" 子树中，在文档的任何级别上查找 phone 元素，而这本是可以避免的开销。
注意，* 和 // 还可能导致不需要的或期望之外的查询结果。例如，如果有些 “customerinfo” 文档还包含 “assistant” 信息，就像下面的文档一样。那么路径 //phone 将返回客户的电话号码和助手的电话号码，而没有将它们区分开。从查询结果中无法知道是客户的电话号码还是助手的电话号码，甚至会把助手的电话号码当作客户的电话号码来处理。
<customerinfo Cid="1004">
<name>Matt Foreman</name>
<addr country="Canada">
<street>1596 Baseline</street>
<city>Toronto</city>
<state>Ontario</state>
<pcode>M3Z-5H9</pcode>
</addr>
<phone type="work">905-555-4789</phone>
<phone type="home">416-555-3376</phone>
<assistant>
<name>Peter Smith</name>
<phone type="home">416-555-3426</phone>
</assistant>
</customerinfo>
|
总而言之，在路径表达式中避免使用 * 和 //，尽量使用全限定路径。
提示 8：定义倾斜的 XML 索引，并避免为任何东西都建索引
假设我们的查询常常根据客户姓名搜索 “customerinfo” 文档。客户姓名元素上的索引可以大大提高那些查询的性能。让我们来看看下面的例子：
create table customer(info XML);
create index custname1 on customer(info)
generate key using xmlpattern '/customerinfo/name' as sql varchar(20);
create index custname2 on customer(info)
generate key using xmlpattern '//name' as sql varchar(20);
select * from customer
where xmlexists('$i/customerinfo[name = "Matt Foreman"]' passing info as $i);
|
上面定义的两个索引都适合用于客户姓名上的 XMLEXISTS 谓词的计算。但是实际上，索引 custname2 比索引 custname1 更大一些，因为它不仅包含客户姓名的索引条目，而且包括助手姓名的索引条目。只是因为 XML 模式 //name 与文档中任何地方的 name 元素相匹配。但是，如果我们永远不需要根据助手姓名来进行搜索，那么就不需要为它们编索引。
对于读操作，索引 custname1 更小一些，因此可能带来更好的性能。对于插入、更新和删除操作，索引 custname1 只会引起用于客户姓名的维护开销，而索引 custname2 则需要用于客户和助手姓名的索引维护。如果想得到最佳的插入/更新/删除性能，并且不需要根据助手姓名进行基于索引的访问，那么当然不想花费额外的代价。
另外，请考虑下面的 heavyIndex 索引，它 “为任何东西编索引”。它包含每个文本节点（即 XML 列中的每个 XML 文档中的每个叶子元素值）的索引条目。在插入/更新/删除操作期间，那样的索引维护起来非常消耗成本，因而通常不推荐使用这样的索引。惟一的例外是，具有较少写活动和不可预测的查询工作负载的应用程序，这种应用程序难于定义更明确的索引。
create index heavyIndex on customer(info)
generate key using xmlpattern '//text()' as sql varchar(20);
|
总而言之，在定义 XML 索引时，应该尽可能精确一点，尽量避免使用 * 和 //。
| 第1页： 理智选择 XML 文档的粒度 | 第2页： 使用 DMS 和更大的页 |
| 第3页： 使用新的快照监视器元素检查 XML 性能 | 第4页： 将文档过滤谓词放入 XMLEXISTS 中 |
| 第5页： 使用带参数占位符的 SQL/XML 语句 |
