分类: Oracle
2008-04-21 18:53:56
使用 XQuery,可以基于 XML 数据以及可以用 XML 表示的非 XML 数据生成 XML 文档,无论其位置如何:无论是存储在数据库中、置于网站上、即时创建还是存储在文件系统中。但要注意,Oracle XML DB 为针对数据库中存储的数据进行的 XML 操作提供了非常高的性能和可伸缩性。因此,如果您能够完全控制所处理的数据,则最好将它移动到数据库中。
正如您从前面的示例中了解到的,在 Oracle XQuery 实施中,doc 和 collection XQuery 函数用于访问 Oracle XML DB 信息库中存储的 XML 文档。可以通过 XMLTable 和 XMLQuery SQL 函数中的 PASSING 子句动态绑定外部数据源。考虑以下示例。假设您的公司要为那些致力于 XQ 项目的员工支付奖金。因此,财务部发布了 empsbonus.xml 文件,其中包含有资格获得奖金的员工列表以及该列表中输入的每个员工的奖金数额。empsbonus.xml 文件可能如下所示:
|
在实际情况中,以上的 XML 文件可能置于网站上(因此可以通过互联网获得)、以文件形式存储在本地文件系统中,或以文件资源形式存储在 Oracle XML DB 信息库中。就本示例而言,该文件位于网站上。为简单起见,可以在目录(Web 服务器在其中存储可从 Web 看到的文档)中创建一个员工文件夹,然后在该文件夹中插入 empsbonus.xml 文件,以便可以通过以下 URL 访问 empsbonus.xml 文件:
接下来,假设您需要基于 empsbonus.xml 文档中存储的数据创建一个报表。在该报表中,您可能不但要包含列表中显示的奖金数额以及每个员工的员工 ID,还要包含他/她的全名。因此,可以首先使用以下查询生成一个新的 XML 文档(假设您以 HR/HR 的身份连接):
SELECT XMLQuery( |
以上查询是一个有关如何使用 XQuery 基于 XML 和非 XML 数据(以不同的方式从不同的数据源中检索)生成 XML 文档的示例。具体而言,使用 ora:view() 函数访问 HR 演示模式中的默认 employees 关系表,并使用 PASSING 子句中的 httpuritype() 函数借助于 HTTP 访问 empsbonus.xml 文档。然后,在 FLWOR 表达式的 return 子句中构建新的 XML 文档。最后,将获得以下 XML 文档:
|
解决性能问题
正如您从前面的部分中了解到的,XQuery 是一种用于查询 Oracle 数据库存储的 XML 内容的高效方法 - 无论您是处理本地存储的 XMLType 数据还是查询基于关系数据构建的 XML 视图。但根据对数据使用的存储类型的不同,XQuery 表达式的执行性能可能迥然不同。尤其是,Oracle XML DB 可以优化基于由 ora:view 函数创建的 SQL/XML 视图而构建的 XQuery 表达式。对于 XMLType 表或列中存储的 XML 数据,只能对使用结构化(对象-关系)存储技术存储的基于 XML 模式的 XMLType 数据进行 XQuery 优化。
所选择的存储模型并非是影响 XQuery 表达式执行性能的唯一因素。在某些情况下,XQuery 表达式本身的结构也可能导致性能问题。要监控 XQuery 表达式的性能,可以打印并检查关联的 EXPLAIN PLAN。在 SQL*Plus 中,只需设置 AUTOTRACE 系统变量,即可打印 SQL 优化程序使用的执行路径。但要执行该操作,请确保创建 PLUSTRACE 角色,然后将其授予连接到数据库所使用的用户。有关如何执行此操作的信息,请参阅 Oracle 数据库 10g 第 2 版 (10.2) 文档中《SQL*Plus 用户指南和参考》一书中的“调整 SQL*Plus”一章。以下示例演示了如何通过检查 EXPLAIN PLAN 生成的执行计划来获得好处。假设您已经将 PLUSTRACE 角色授予默认用户 OE,以 OE/OE 的身份登录并运行以下查询:
SET AUTOTRACE ON EXPLAIN
|
这将生成以下输出:
COUNT(*) Execution Plan -------------------------------------------------------------- | 1 | SORT AGGREGATE | | 1 | 226 | | | | 2 | NESTED LOOPS | | 10782 | 2379K | 29 (0) | 00:00:01 | |* 3 | TABLE ACCESS FULL | PURCHASEORDER | 1 | 226 | 5 (0) | 00:00:01 | | 4 | COLLECTION ITERATOR P| XMLSEQUENCEFROMX| | | | |
3 - filter(SYS_CHECKACL("ACLOID","OWNERID",xmltype(' |
您可能对为以上查询生成的执行计划并不满意。尤其是,所处理的行数可能非常大。由于 SQL 调整的主要目标是避免访问对结果没有任何影响的行,因此可能要继续调整查询以优化性能。对查询中包含的 XPath 表达式进行重新建模后,可以再次重试它,如下所示:
SELECT count(*) 这次,输出应如下所示:
--------------------------------------------------------------- | 1 | SORT AGGREGATE | | 1 | 29 | | | | 2 | NESTED LOOPS | | 1 | 29 | 7 (0) | 00:00:01 | | 3 | FAST DUAL | | 1 | | 2 (0) | 00:00:01 | |* 4 | TABLE ACCESS FULL | PURCHASEORDER | 1 | 29 | 5 (0) | 00:00:01 | Predicate Information (identified by operation id): 4 - filter("PURCHASEORDER"."SYS_NC00022$"='CJOHNSON' AND |
您可以看到,以上显示的查询生成相同的最终结果,但它们的执行计划并不相同。查看最后一个示例中的 XQuery 表达式,您可能会注意到它迭代顶层 PurchaseOrder 元素,其中的每个 PurchaseOrder 元素都表示基于 PurchaseOrder XMLType 模式的表中的一行。这意味着实际上重写 XQuery 表达式,以迭带基础对象表(用于存储分解的 PurchaseOrder 文档)中的行。与查询要迭代不表示基础表中的单个行的 XML 元素相比,该方法的性能更好一些。
但在某些情况下,很难发现 XQuery 表达式的哪个构造将使某些查询的性能更好。这就是为什么最好在开发阶段使用调整工具的原因。