【聆听IT专家讲座，了解如何降低数据管理成本，更有机会获得限量蓝牙耳机！】
【了解更多数据管理产品信息。】
序言:最近看了不少国内、外同行对DB2 9的评论，内容上虽然百家争鸣，但基本上体例都是一样的，依次分别是PureXml、自动内存管理、表分区、数据压缩、基于标签的访问控制(LBAC)……，此外作为开发人员笔者还想就Viper对Visual Studio .NET 2005和Eclipse的Add-ins 的使用情况作些简单的介绍。
此次版本的DB2 V9 正式发布前差点被命名为DB3，虽然最后还是沿用DB2 的名字发布，但是从可以被考虑命名为DB3这件事本身就已经说明了这个版本较之DB2 Ver3 至DB2 Ver8之间非常大的差别，最直接的原因也是因为它进入了双核的时代。
相信读者中很多人也都经历了从桌面的C/S 环境到Web的B/S环境的转变，您在技术中的很多问题也源自或者归咎于数据库的支持能力，那么下面笔者与大家一起评测DB2 9 的表现。
来自业务的呼声——PureXMLXML
数据的保存方式
开启话题之前，简单看看现有关系数据库系统中对XML的3种主要保存方式:
◆ Shredded方式:也就是把XML数据抛弃其层次关系，平铺为关系数据表，这对于一般的单层或者简单的XML数据交换而言可以接受的，但如果需要通过XSLT转换或者交换不同XSD 的数据就只能靠关系数据库的关联操作完成。
◆ 非结构化的BLOB方式:这种方式被“三大”(Oracle、IBM 和SQLServer)的上一代产品使用，虽然提供了XML Extend 但是其实都需要把XML数据从BLOB 中完整串行化后，才可以在内存的树型结构上操作。
◆ 结构化方式: 这个方式是“三大”这一代产品的方式，保存在专门的XML 字段的数据是具有层次结构的，因此可以不用把整个树串行化到内存就可以用XQuery 借助XPath定位到某些层次和属性的信息，是真正的XML 数据方式。
结构化存储的技术意义
那么DB2 9这种纯XML 数据访问方式在技术实现上有什么实际的意义呢，笔者总结如下:
◆ 只有真的结构化存储，才可以提供层次型索引，作为可用性的基本要求——保证效率才可以真正把Native XML数据库大量用于开发。
◆ 现有XML更多的使用位置是在数据交换中，XML数据的转换主要有如下几种：基于XPath规则的部分提取、基于XQuery 的部分更新/ 增加/删减、基于XSD->XSLT->XSD的schema转化、多个相同或者不相同Schema数据的合并。如果不提供这种结构化存储，那么每个操作都至少要把整个XML 数据完整提取到内存中，再进行计算，尤其是涉及多个XML数据的关联与合并操作，那么资源的消耗就很可观了，即使您可以通过分解等价式将一次操作等价的通过多次操作累积完成，那么情况相信也是很糟糕的。但是在层级结构下，每次提取的都是部分子集或者是基于某个层次的个别统计结果，即使进行关联操作内存的消耗较之非结构化也应该是1-3个数量级的。
◆ 只有通过这种结构化存储才可以保证SQL与XQuery 可以混合使用，否则以往的SQL解析器根本不能从没有结构的二进制数据中知道查询的那些层次和属性是否存在，更无法确认是否应该使用那些索引，所以执行计划的建立只能是梦想而已。
结构化存储的业务意义
这些技术层的要求又来源于我们哪些实际业务需要呢？
◆ 就像笔者上文一直强调的，第一个见效益的就是服务器的投资上可以大大降低，因为完成同样的吞吐现在都是数据子集对数据子集操作，而且通过XML数据的索引可以大大提高查询的效率。
◆ 原始数据的价值恐怕经过几个交换和汇总后会有很大的提升，那么在互联网环境下XML 数据作为交换载体就非常方便了，但是其中有几个主要的挑战:
1. 由于业务的快速变化，数据结构也常常需要变化:有了结构化的X M L 存储一方面可以快速的采用XQuery 修改数据Schema，此外更便于套用XSD来验证数据的有效性，这样数据交换的原数据检查和入库前的检查都有了保证。
2. 同一数据往往需要与不同的业务伙伴分享，但是不同业务伙伴需要的schema是不同的:这个就更依赖于结构化存储，通过配置不同的XSLT就可以轻松的“因人而异”准备数据。
3. 便于业务流程的合并和重组:以往的关系化设计更类似于结构化程序设计，要求每一步都“ready thengo”，但是业务流程又常常是在变化的，不断会常常出现新的业务，而且出于效率和人力成本的考虑很多业务也会常常合并，那么体现在XML数据上通过XQuery 快速的拆分、组合XML 树型结构是非常方便的。
4. 各个厂家的业务处理限于历史的原因，技术平台不一，数据交换需要采用可以适应不同平台的“中庸”数据存储方式：这个是XML数据的天然优势。
◆ 可以更为丰富且规格化的描述业务信息。
以往的设计中往往为了开发的方便，也出于效率考虑，可能需要增加一些冗余的字段，例如图1。
采用XML字段后:假设联系人信息的Schema如下（重数和层次关系都已经标出）例如图2。
那么完全可以以更规范化的表示用户信息如下，例如图3。
◆ 此外，DB2 9这种方式也是很好保存各类企业关键历史资源的有效途径，企业中更多的信息价值是保存在Word、Excel、RTF、Powerpoint、Project 之中，以往我们总是把他们作为附件，很多企业知识其实是被浪费了。有了Viper 的PureXML 数据库后，通过Office 到XML文件的导入机制，我们可以把他们保存到数据库中，利用公文格式相对固定的特点，通过XQuery很容易实现基于原有OA系统的统一的公文检索。
与其它产品的对比
Oracle 10g R2 采用的是3 管齐下的办法，同时提供了Shredded、BLOB、结构化三种存储方式，与以往Oracle数据库产品一样，总体上不错，但是如果仅从XML 数据本身来提，有两点不尽人意:
1. 不同的钥匙开不同的锁，不同的存储方式必须明确告知开发人员;
2. XML数据的元信息相对薄弱，关联和转换稍显笨拙。
SQL Server 2005继续采用Blob保存XML数据，增加了对XQuery 和Xpath的优化，而且由于在.NET 平台对于XML 的读取采用了一贯的“Stream”（流）方式，因此相对于应用开发而言效率的损失不够明显，但如果作为混合SQL与Xquery查询时，由于要同时囊括多个XML字段的检索，因此效率较之结构化存储会存在很大的差距。
DB2 9 同时支持Blob（面向整文档操作）和结构化处理，不仅具有Oracle 所支持的索引、原数据的支持外，由于增加了XSR（XML SchemaRepository）这个Schame 知识库，因此对于数据交换过程中的关联和转换等于有了一个可以快速预处理的过程，可以更高效的完成大容量数据的交换，非常适应于服务型程序的使用。此外，由于DB2 9同时支持Blob字段，因此对于仅仅需要把XML文档当作附件使用的系统而言，也可以很容易的通过逻辑结构无关的Stream（流）方式处理。在Shredded的存储方式上，由于DB2 9的双核特性， 使得它可以并行流水化（Streamlined）的进行“关系数据库至XML层次数据库”和“XML层次数据库至关系数据库”的双向转化，拥有双核的DB2 9因此将比Oracle 10g2nd和SQL Server 2005在担当系统集成的工作时，以更高的并行度执行分流、提取、保存数据等操作。
简而言之，DB2 9对于XML数据的处理更为纯粹、更为高效、更利于数据交换。
更便捷、面向更大数据规模的自动内存管理
一直以来，DBA的很大一部分时间被消耗在调整各类数据库及其运行环境的参数上，其中很多经验值、阀值和计算规则被一代代DBA传承，甚至于明显地写在数据库产品的配置文档中，但是由于很多参数的修改都需要重新启动数据库，因此这些本该很早就被自动管理的工作成了伴随DBA 职业生涯的协奏曲。
自从去年，在Oracle 10g发布的Oracle Open World 上首次看到了自动内存管理，随后的SQL Server 2005也把自动内存管理作 为反复宣扬的卖点，甚至于开源数据库MySQL 也开始宣称支持部分的内存自动管理。笔者在一个内存已经枯竭的环境下，对DB2 9 进行大容量长交易提交时，体会到了DB2 9较之其他先行者的一些优势。常规的讲，DB2 9采用了一种新的内存调优功能，它可以自动设置内存配置参数的值以及缓冲区池大小。当启用时，该内存调优工具可以在几个内存消耗者之间动态分布可用的内存资源，包括分类、包缓存、锁列表区域和缓冲区池。
不过DB2 9在自动内存管理方面出彩的地方是如下两个:
◆ 在Windows和AIX平台上，自调优内存特性还可以确定总的数据库内存需求和动态地调整数据库共享内存，也就是根据近期运行情况动态的预计算未来需要的内存容量。
◆ DB2 9根据工作负荷的要求来占用更多的物理内存，并在数据库内存需求较低时将该内存释放给操作系统。尤其在Windows平台，这个特性更为明显，相信读者都有类似的经验，Oracle 10g /2nd 和SQLServer 2005 虽然有自动内存管理，而且在增加和分配内存方面做的与DB2 9不相伯仲，但是内存的释放却一直很慢，常常出现持续居高不下的情况。
当然，上述分析仅仅从业务层面展开，其实这种内存自动管理的运维意义更大，借助它每个DBA可以管理更大规模的数据库Farm，把自己的时间从重复的简单劳动（日常内存参数的修改相对于资深DBA 而言）中解脱出来，将更多的精力关注在企业数据库Farm 布局和整合上。
Do more with less的压缩技术
随着数据库信息的不断膨胀，尤其是近几年新兴的数据仓库技术，数据库的存储似乎渐渐成了问题，在涉及大数据量提取、计算的领域I/O再次成为了制约数据库、数据仓库整体性能的瓶颈。DB2 9把压缩技术引入数据库的存储领域，通过建立压缩数据字典方式，很好的把现代商用数据库中大量使用的Char 和Varchar 类型字段进行压缩，大大节省了用户端查询时的网络延迟。
DB2 9的压缩原理其实非常简单，就是用单个数值代替尽量连续的更多容量的重复数据，例如下表:
压缩后，实际的表和压缩字典的保存结果:
通过压缩，在完成同样数据存储时根据IBM的统计资料往往可以节省50%——80%的空间，而且对于Internet 上的数据查询，普遍也可以减少响应时间。
RDBMS 层次的分区——表分区
DB2提供了新的分区技术——表分区，通过它将提高性能并减低数据仓库的管理时间，它可用于定义每个分区的数据范围并根据数据范围将数据存储为单独的对象，例如可以按照区域和时间段把同一个表分割为不同的存储对象，这些存储对象可以存放在不同的表空间、同一表空间中或两者的结合，如图6。
图6：DB2 Viper 按照时间段划分的表分区
与以往“三大”所支持的数据库分区不同的是，此次DB2 9的表分区提供了更细颗粒度的RDBMS的分区技术，一方面大大提高了OLTP 的分段统计功能的要求，另一方面对于数据仓库而言可以更好的基于某一个轴提取分区的数据并用于聚合计算。
表分区可以单独使用，也可以与其它组织模式结合使用。在建立表分区的CREATE TABLE语句的每个子句都包括一个指示应如何组织数据的算法。以下三个子句说明了数据组织的级别，这些级别可以任何组合形式来使用:
◆ DISTRIBUTE BY:将数据均匀地存储在各个数据库分区中。此子句用于使内部查询平行和平衡每个数据库分区的负荷。此概念称为数据库分区，由DPF激活。
◆ PARTITION BY:依据同一数据分区中单个维的相似值来对行进行分组。此概念称为表格分区。
◆ ORGANIZE BY:依据同一表格范围中多个维的相似值来对行进行分组。此概念称为多维群集 (MDC)。
此外，在建立表分区的时候，如果采用的是DISTRIBUTE BY 或者PARTITION BY的时候，可以把不同的分区对象保存在不同的表空间之中。进一步通过分割I/O获得更好的并行效率。
恰逢其时的安全控制等级—— LBAC
根据公安部发文要求，今年是我国主要信息系统采取等级保护的第一年，其中对于每个重点行业核心及其核心辅助信息系统的按照重要程度一般会划分为3 级保护，刨除其中许多政策性、指导性的要求外，一个明确的目标——“可标识系统安全保护”是个硬性的指标，它意味着如果不满足这个要求的数据库产品很可能根本没有资格参与国内主要行业的集成或者开发项目的竞标。
Oracle 10g 在推出时已经把LBAC 从AdvancedSecurity Option中提出出来，作为Database Engine的安装选项，DB2 9今年发布时提供了LBAC的特性可以说恰逢其时。相形之下，SQL Server 2005似乎落后于我国的信息系统安全保护建设政策了。
DB2 9使用基于标签的访问控制(LBAC) 来解决安全问题，该访问控制在单个行和列级别上提供最精细的读写访问。较之以往基于角色的安全性而言，LBAC需要在初期定义更高层次的安全控制——安全策略，而且将明确的数据安全管理员角色引入到数据库的管理之中，他与数据库管理员相互制约，对于减少以往数据库管理员个人大权独揽之下的审计风险有很大的帮助。
创建安全策略之后，安全管理员可以创建所谓安全标签的对象，它们是该策略的一部分。受安全标签保护的数据称为受保护数据。安全管理员通过向用户授予安全标签来允许用户访问受保护数据。用户尝试访问受保护数据时，系统将对用户的安全标签与保护该数据的安全标签进行比较。如果用户尝试读取LBAC 不允许访问的受保护行，DB2将当作没有存在那些行来处理。那些行不能选择作为您运行的任何SQL语句的一部分，包括SELECT、UPDATE 或DELETE。更为重要的是，这些被忽略的行将不会参与聚合计算，例如:Count、Avg、Sum等。
数据库的生命在于应用—— DB2 9 对开发工具的更好支持
把Developer Workbench 嵌入Eclipse框架:
通过Developer Workbench可以可视化的设计、调试Viper，而且所有的结果也都是可视化的。在Developer Workbench 中包括如下三个主要视图:
◆ Database Explorer view
◆ Data Project Explorer view
◆ Data Output view
三者结合起来就够成对开发人员非常友好的完全可视化的DB2 9开发平台。主要可以完成如下工作:
◆ 显示基于现有DB2 9 数据库的常规开发
◆ 通过向导执其他的常规开发工作
◆ 从外部导入SQL Script 和存储过程
◆ 把包括Java Procedure的内容打包
◆ 打包后结果部署到目的主机
◆ 导出开发对象
◆ 进行回归测试
◆ 调试混合代码的存储过程
◆ 用托拽的方式，从DB2 9 项目中引入一个新的开发项
嵌入Visual Studio .NET 2005的DB2 Add-ins:
比较有趣的是，此次DB2 9对于Visual Studio .NET 2005的支持似乎多过Eclipse。
VS.NET 2005开发环境中的DB2Viper Add-ins 布局:
完全支持Developer Workbench中的Database Explorer、Database ProjectExplorer 和Data Output 的内容，并且允许用户通过DB.NET Connector、OLEDB、ODBC三种方式的任意一种访问DB2 9。
全面的开发向导:
此外，面向不熟悉DB2的VS.NET开发人员还提供了更多的向导:
◆ 存储过程向导
◆ 矢量函数向导
◆ 建表向导
◆ 建视图向导
◆ 触发器向导
◆ SQL 向导
◆ 空白智能向导
Framework SDK 方式的帮助:
完全支持上下文关联的在线帮助系统。
