DB2 Viper的混合型XML/关系数据服务器在实际中是如何工作的呢？本文带你切身体验一下DB2 Viper的实际性能和处理，让你了解在实际测试DB2 Viper时应着眼于哪些方面。
IBM正在把数据服务器推向下一个发展阶段：推出了可以管理纯 XML 和纯关系数据的单一混合型引擎。DB2 Viper所用的新技术让许多公司可以了解非关系业务数据，譬如Excel电子表格里面的财务信息，或者通常存在于纸上或者文字处理文档中的重要合同。使用DB2 Viper，单单一个联接语句就可以将这些丰富的业务数据与传统的关系数据合并在完整视图中。针对电子表格、合同、传真图像或者收据的人工搜索可以由一个简单的语句加以替代。访问这种XML数据的标准机制可确保：现有的报告工具和接口可以将这些新数据直接提供到桌面。纯XML技术提供了对业务成功而言至关重要的敏捷性。
新的混合型XML/关系功能并不是面向Linux、Unix和Windows的DB2 Viper所具有的惟一新特性。本文将讨论DB2 Viper具有的主要特性。读者可以通过Viper的公开测试程序（http://www-306.ibm.com/software/data/db2/9/），亲自尝试一番这些特性。
XML 驱动业务
除了可以存储关系数据外，DB2 Viper的混合型引擎还能使用纯XML结构来存储XML文档。因而，日益求助于XML的公司可以使用高性能的XML存储引擎，还可以利用员工现有的数据库技能来管理及保护这些XML数据（见图 1）。
XML对如今的公司而言很重要，这有许多原因。在面向服务的架构（SOA）环境中，如果使用独立的通用服务，就不需要为每个应用程序开发各自的访问方法，并且有助于应用程序的集成。XML常常是应用程序和通用服务之间进行联系所用的消息传递语言。譬如在股票交易中，顾客通过Web界面购买一定份额的股票。这个Web过程向经纪人系统发送XML消息，表示要执行交易。这个XML消息是临时的，只是为了触发经纪人系统而存在。DB2 Viper可以保存这个XML消息，同时让数字签名保留原状。因而，这些XML消息现在可用于法规遵从方面的审计。
如今，大多数公司无法轻松地访问现有的业务数据，就是因为使用的数据库技术、平台和数据格式数量众多。通过创建统一的数据格式，SOA通用服务就可以从原始数据源获取数据，将数据格式化成标准格式，并且存储在 XML中，从而有助于灵活、标准地访问关键业务数据。
能够存储关键业务型文档（如Excel电子表格或者法律合同），并将该数据与相关的关系数据联系起来，这是 Viper的主要优点之一。微软Office、Adobe程序和大多数前台产品都提供了将文档存储为XML格式的功能。企业用户现在可以轻松地访问电子表格数据，因为微软Excel电子表格（常常用于存储决策所需的重要财务统计数据）现在可以作为XML格式存储在DB2 Viper数据服务器里面，而不是存储在容易损坏的文件服务器或者硬盘上面。
纯 XML
现有的关系数据服务器将XML文档存储为字符或者二进制大对象（CLOB或者BLOB）。不过在CLOB或者 BLOB中，数据存储为单一单元或者连续字节串。如果查询XML文档里面的某个值，或者仅仅更新XML文档的一部分，这种存储格式会给性能带来难题。必须读取及解析整个记录，之后才可以进行谓词评估（predicate evaluation）。建立索引可以降低搜索成本；但是，对XML文档进行更新需要对XML索引进行更新。另外，更新XML文档还需要改写整个文档。
对 XML 文档进行分解是关系数据库管理系统（RDBMS）的另一种存储方法。通过将XML文档的每个元素映射到关系列，XML文档可以存储在多个表和列中。一旦文档被分解，结构和任何相关的条目（如数字签名）就会丢失；然而，如果整个XML文档用不着保留，分解也许是切实可行的解决办法。
DB2 Viper将最纯粹形式的XML保存为经过预先解析的带注解的树。如今市面上已有纯XML数据库，但不是混合型数据库（这意味着它们没有同时存储XML数据和关系数据的优点）。有了DB2 Viper，XML就可以存储为基于节点的层次模型。在这种模型中，每个节点不但与其父节点相连接，还与其子节点相连接。这种纯XML存储是访问及存储整个XML文档的最有效方法，提供了极大的性能优势。
纯XML存储可以原封不动地存储XML文档，从而提供了BLOB和CLOB的优点，还解决了性能问题，因为文档存储没有被虚拟化成单一、连续的字节范围。整组文档的存储被虚拟化成连续的字节范围，但各个节点可以安置到这个范围中，对其他节点和索引的影响极小。
DB2 Viper既支持分解的XML，又支持纯XML。支持分解功能很重要，因为XML可用来提供现有的关系模式。因为文档会变大，在许多情况下还可以更新，所以XML文档的非BLOB存储（包括在节点层面而不是在文档层面进行存储）具有的优势很显著。
大多数公司内部已经有关系数据服务器，而且有负责支持的员工。虽然Viper代表着新颖、先进的XML技术，但并不要求公司雇用新的精通XML的开发人员。为了创建DB2混合表（该表同时含有关系数据和XML数据），只需要一个简单的CREATE TABLE语句及新的XML数据类型：
create table clients(
id int primary key not null,
name varchar(50),
status varchar(10),
contactinfo xml
)
为了访问混合表，IBM支持 SQL基于行业标准的扩展：SQL/XML。这些扩展可以使用简单的SELECT语句来检索 XML文档或者XML文档的一部分。除了SQL/XML外，DB2还支持新的XML Query（即XQuery）语言。XQuery是由万维网联盟（W3C）推动的一项标准，旨在可以查询XML的层次化结构，正如SQL旨在可以查询表格数据结构那样。XQuery不同于SQL的一个地方就在于，它能够提供路径表达式，从而使程序员能够轻松浏览XML的层次化结构。以下示例就是返回客户联系人数据的简单XQuery：
xquery db2-fn:xmlcolumn('CLIENTS.CONTACTINFO')
假设希望检索所有客户的传真号码。以下是可以编写查询的一个方法：
xquery
for $y in db2-fn:xmlcolumn
('CLIENTS.CONTACTINFO')/Client/fax
return $y
第一行指令DB2调用其XQuery解析器。下一行指令 DB2遍历CLIENTS.CONTACTINFO列中 Client元素的fax子元素。每个fax元素进而被绑定到变量$y。第三行表明：每次迭代返回$y的值。结果就是下面的XML元素序列：
< fax>4081112222< /fax>
< fax>5559998888< /fax>
DB2支持 XQuery，这意味着它根本不必把XQuery转换为SQL（转换会带来不必要的开销，并且造成语义不一致）。它也不需要客户将XQuery语句封装在SQL语句里面。相反，DB2客户可以在需要时充分利用XQuery和SQL；甚至可望利用“双语”查询，从而利用每种语言具有的独特功能。新的、先进的XML索引技术补充了Viper对SQL/XML和XQuery的支持，能够提供良好的运行性能。
应用程序支持
DB2 Viper简化了在自己开发或者套装的应用程序中实现DB2。新设计的开发工作台（Developer Workbench）基于Eclipse平台，能够同基于Eclipse的工具如Rational Application Developer实现兼容。开发工作台、支持的所有开发界面和API以及新工具（如XQuery构建器）都包括了支持新的XML技术这一功能。易于使用的XQuery构建器提供了语法彩色显示、代码自动完成，以及加快创建XQuery和 XML文档的其他许多实用程序。
为了解决数据质量问题，DB2 Viper允许在本地DB2存储库中创建及注册XML模式（这是可选操作）。然后，应用程序试图将文档插入或者导入表中时，DB2就可以对照这些模式来验证XML数据。为了获得最大的灵活性，DB2允许在表的同一列中存储与不同 XML模式相关的XML文档。这样一来可以支持模式演化，并且使DB2能够满足不断变化的业务需求，又用不着破坏现有的应用程序，或者被迫对数据库模式进行成本高昂的修改。
除了XML方面的改进外，DB2 Viper还对.NET环境做了更深入的分析。DB2新的.NET数据提供程序有助于对.NET Framework 2.0类库进行访问。它还可以通过编程人员选择的语言编写而成的存储过程来扩展 DB2数据源访问功能，这些语言包括与通用语言运行时（CLR）兼容的任何语言（如C#或者Visual Basic .NET）。DB2 Viper还引入了支持 Visual Studio 2005的增强型数据库插件。这些特性可以共同帮助开发人员缩短为DB2服务器系列开发.Net应用程序的时间。
自我管理内存
对负责确保应用程序和数据库性能及可用性的数据库管理员（DBA）而言，他们很难抽出时间去研究 XML和SOA这些新技术。近期的每个DB2版本都添加了可缩短管理数据库所需时间的特性，从而提高了DBA的工作效率。
图1 既能管理关系存储又能管理纯XML存储的DB2混合型数据服务器
DB2 Viper采用了新的内存调整特性，它可以自动设置内存配置参数和缓冲池大小的值。一旦被启用，内存调整器就会在几个内存使用者之间动态分配可用内存资源，内存使用者包括排序、包缓存、锁列表区域和缓冲池。在Windows和AIX平台上，自我调整内存特性还可以确定总的数据库内存需求，并动态调整数据库共享的内存。这项特性让DB2在工作负载需要时可以使用更多的物理内存；数据库内存需求很低时，可以将内存释放给操作系统。
除了简化内存配置外，这项新颖、自适应、自我调整的特性还可以通过提供最佳配置——这种配置具有动态性，还可以应对工作负载的特点出现的重大变化，从而提高性能。
范围分区
面向Linux、Unix和Windows的DB2引入了一项新的分区技术，可以提高数据仓库的性能，并缩短管理时间。新的表分区方法通常称为范围分区（range partitioning），可以为每个分区定义数据范围，并根据数据范围将数据存储为独立对象。譬如说，可以根据表中的日期列，按照年和月对表进行分区。这些存储对象可以位于不同的表空间、同一表空间，或者两种情况的组合（见图2）。
不要将这种分区技术与数据库分区功能（DPF）相混淆，DPF 允许根据分布键和散列函数跨多个数据库分区对数据进行分布，往往用于提高可扩展性，从而支持非常大的数据库。
表分区让存储对象的行为就像单个的表那样，通过使用ALTER TABLE...ATTACH语句将现有的表与分区的表进行合并，从而轻松实现快速转入（roll-in）。同样，用ALTER TABLE...DETACH 语句很容易实现转出（roll-out）。查询处理可以利用分隔来避免扫描无关的数据，从而为许多数据仓库风格的查询提供更好的查询性能。
表分区往往用来存储供分析的历史数据。譬如说，典型的保险数据仓库可能保存了三年的索赔数据。将每个月的数据载入仓库后，最早那个月的数据就被存档，并从活动表中删除。新的转入和转出特性有助于这种数据移动，从而缩短了管理时间。只扫描适用分区中的数据可以加快查询速度，从而提高性能。范围在CREATE TABLE语句的PARTITION BY子句中加以指定。这个定义使用的列被称为表分区键列。
表分区可以单独使用，也可以结合其他组织方案使用。CREATE TABLE语句的每个子句都含有算法来表明应如何组织数据。以下三个子句表明了数据组织级别，这些级别可以以任何组合形式来使用：
● DISTRIBUTE BY跨数据库分区均匀地分布数据。使用这个子句可实现查询间并行机制，并且跨每个数据库分区进行负载平衡。这个概念称为数据库分区，得到了DPF的支持。
● PARTITION BY把一个维中具有相似值的行分组在同一数据分区中。这个概念称为表分区。
● ORGANIZE BY 把多个维中具有相似值的行分组在同一表区间中。这个概念称为多维群集（MDC）。
这个语法提供了子句之间的一致性，还为将来的数据组织算法提供了支持。结合使用CREATE TABLE语句的DISTRIBUTE BY和PARTITION BY子句使数据能够跨数据库分区（分区本身横跨多个表空间）进行分布。
DB2 Viper将是第一个同时支持所有三种常见的数据库分区方法的数据服务器——这是加强数据管理、提高信息可用性方面的重大创新。
数据行压缩
早期的测试结果表明，DB2 Viper压缩技术最多可以节省80%的存储空间。由于行的大小减小——这会尽量减少I/O操作、提高缓冲池的命中率，物理I/O操作的数量和缓冲池需求也随之减少。最终结果是，用于存储方面的预算减少了；在某些情况下，还提高了性能。
DB2 Viper压缩解决方案类似面向z/OS的DB2所用的解决方案。压缩方法就是把数据行里面的重复数据模式映射成比较小的符号，从而减小表数据的总大小。这种解决方案使用基于词典的静态压缩算法，逐行进行压缩。与面向z/OS的DB2一样，所用的是Lempel-Ziv压缩算法的一种变体。
这项新特性除了适用于可利用上述新的分区特性的表外，还适用于现有的DB2表。
CREATE TABLE和ALTER TABLE语法包含一个新的COMPRESS NO/YES子句，用于设置及取消表的行压缩属性。设置COMPRESS YES，之后执行离线的表REORG，就可以对表中所有符合条件的行进行压缩。一旦词典已经存在、COMPRESS YES已被设置好，插入或者装入到表中的所有新行就可以使用这个词典进行压缩。
压缩词典是通过扫描整个表，然后根据表值建立而成的。这种方法有别于为每个页建立压缩词典的其他数据库压缩技术。通过在表层面而不是在页层面建立压缩词典，就可以分析整个表，从而识别模式，而不是局限于分析单个页。
基于标签的控制
数据库面临的内外威胁在与日俱增。公司企业和政府监管部门都承认需要加强对数据库的保护，并且要求这样做。DB2 Viper利用基于标签的访问控制（LBAC）来解决这些安全问题。LBAC在单个行和单个列层面上提供了细化的读写访问控制。
可调整LBAC的功能从而满足每家公司特定的安全需求。IBM建议：所有LBAC配置应由公司安全管理员来执行。DB2 Viper创建了新的DB2安全管理员角色（SECADM），它具有特定的安全特权。
安全管理员通过创建安全策略来配置LBAC系统。安全策略描述了将用来决定谁可以访问哪些数据的标准。创建了安全策略之后，安全管理员创建名为安全标签的对象，它们是策略的一部分。受安全标签保护的数据称为受保护数据。安全管理员通过向用户授予安全标签来允许用户访问受保护数据。如果用户试图访问受保护数据，该用户的安全标签和保护数据的安全标签需要进行对比。如果用户试图读取他们的LBAC证书不允许读取的受保护行，DB2 就会表现成这些行不存在一样。不能选择这些行作为任何 SQL语句的一部分，包括SELECT、UPDATE或者DELETE语句。连聚合函数也会忽略用户的LBAC证书不允许的行。譬如说，COUNT(*) 函数只会返回用户拥有读取访问权的行的数量。（编译自www.db2mag.com）
（计算机世界报 2006年09月18日 第36期 B28、B29）