IBM DB2 9特性概览
简介
在信息管理行业庆祝数据库管理系统的第 40 个生日时，IBM 邀请了顾客和合作伙伴来测试 DB2 “Viper”，这是一种混合型的数据服务器，它标志着信息管理技术的又一次进化。
信息管理技术始于 20 世纪 60 年代早期，也就是美国总统肯尼迪制订 10 年内实现人类登月目标的时候。1966 年，IBM 与 North American Rockwell（它赢得了发射第一艘登月飞船的合同）合作创建了一个自动化系统来管理建造飞船所需的大量资料。层次化的 Information Management System（IMS）和数据库管理技术本身由此诞生了。
下一个重要的里程碑也是在 IBM 出现的，即 20 世纪 70 年代关系模型和结构化查询语言（Structured Query Language，SQL）的发明。1982 年，IBM 在大型机上引入了 DB2，直到现在这仍然是世界各地的大银行和金融机构选用的数据库。随着市场开始在非大型机平台上实现应用程序，IBM 于 1987 年在 OS/2 上引入了 DB2，90 年代又在 AIX、AS/400、HP-UX、Solaris、Windows 和 Linux 上引入了 DB2。DB2 在这么多平台上的实现使得顾客可以选择最适合自己应用程序需要的版本。
目前，IBM 正在将数据服务器的进化推进到下一层次，引入了一种可以管理纯 XML 和纯关系数据的混合型引擎，即 DB2 Viper。DB2 Viper 中的新技术使公司能够充分利用非关系业务数据（比如 Excel 电子表格中的金融信息或通常存在于纸上或字处理文档中的重要合同）。利用 DB2 Viper，一个联结语句就可以将这些业务数据与传统的关系数据合并在一个完整的视图中。对电子表格、合同、传真图像或收据的手工搜索可以由一个简单的语句替代。对 XML 数据的标准化访问机制确保现有的报告工具和接口可以将这些新数据直接提交到桌面。纯 XML 技术提供了对业务成功很重要的敏捷性。
新的混合型 XML-关系功能不是 DB2 Viper for Linux, Unix, and Windows 上惟一的新特性。我将讨论 DB2 Viper 上可用的主要特性。您可以自己通过 Viper 的开放测试来尝试这些特性（ibm.com/db2/viper）。
XML 驱动业务
除了存储关系数据之外，DB2 Viper 的混合型引擎还能够使用纯 XML 结构存储 XML 文档。因此，正在逐渐转向 XML 的公司可以使用一种高性能的 XML 存储引擎，并利用工作人员现有的数据库技能来管理和保护 XML 数据（见图 1）。
图 1. DB2 混合型数据服务器能够管理关系和纯 XML 存储
由于许多原因，XML 对于当今的业务很重要。在面向服务的体系结构（service-oriented architecture，SOA）环境中，使用独立通用服务的思想使得不再需要为每个应用程序开发自己的访问方法了，并有助于应用程序的集成。XML 是应用程序和通用服务之间常用的消息传递语言。例如，在股票交易中，顾客通过一个 Web 界面购买一定份额的股票。这个 Web 过程向经纪人系统发送一个 XML 消息，从而执行交易。这个 XML 消息是临时的，只是为了触发经纪人系统而存在。DB2 Viper 可以保存这个 XML 消息，同时完整地保留它的数字签名。这样的话，就可以在金融审计中使用这些 XML 消息。
目前，大多数公司无法轻松地访问现有的业务数据，这是由于使用的大多数数据库技术、平台和数据格式的限制。通过创建一种统一的数据格式，SOA 通用服务可以从原始数据源接收数据，将数据格式化为一种标准格式，并存储在 XML 中，这样就对关键业务数据提供了灵活且标准化的访问方式。
能够存储业务关键型文档（比如 Excel 电子表格或法律合同）并将此数据与相关的关系数据联系起来，这是 Viper 关键的优势之一。Microsoft Office、Adobe 程序和大多数前端办公产品都提供了将文档存储为 XML 格式的功能。业务用户现在能够轻松地访问电子表格数据，因为 Microsoft Excel 电子表格（常常用来存储对于决策很重要的金融统计数据）现在可以按照 XML 格式存储在 DB2 Viper 数据服务器中，而不是存储在容易损坏的文件服务器或硬盘上。
纯XML
现有的关系数据服务器将 XML 文档存储为字符或二进制大对象（CLOB 或 BLOB）。但是，在 CLOB 或 BLOB 中，数据存储为单一的单元或连续的字节串。当查询 XML 文档中的特定值或者更新 XML 文档的一部分时，这种存储格式会造成性能难题。必须读取整个记录并进行解析，然后才能进行谓词评估。建立索引可以降低搜索成本；但是，对 XML 文档的更新要求更新 XML 索引。对 XML 文档的更新还需要重写整个文档。
对 XML 文档进行分解（Shredding 或 decomposing）是另一种 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 数据类型：
清单 1. 创建包含 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 是一种由 World Wide Web Consortium（W3C）推动的标准，设计它是为了查询 XML 的层次化结构，正如设计 SQL 是为了查询表格数据结构一样。XQuery 与 SQL 的不同之处是它能够提供路径表达式，使程序员能够在 XML 的层次化结构中导航。下面这个简单的 XQuery 示例返回客户的联系数据：
清单 2. XQuery 语句
xquery db2-fn:xmlcolumn('CLIENTS.CONTACTINFO')
假设希望检索所有提供了传真号码的客户的传真号码，那么可以编写下面这样的查询：
清单 3. 检索所有提供了传真号码的客户的传真号码
xquery
for $y in db2-fn:xmlcolumn('CLIENTS.CONTACTINFO')/Client/fax
return $y
第一行让 DB2 调用它的 XQuery 解析器。下一行让 DB2 遍历 CLIENTS.CONTACTINFO 列中 Client 元素的 fax 子元素。每个 fax 元素被绑定到变量 $y。第三行要求对于每次迭代返回 $y 的值。结果就是下面的 XML 元素序列：
清单 4. XML 元素序列结果
4081112222
5559998888
DB2 直接支持 XQuery 语言，这意味着它无需将 XQuery 转换为 SQL（转换会引入不必要的开销以及语义的不一致）。而且它不要求客户将 XQuery 语句包装在 SQL 语句中。DB2 客户可以按照自己的希望利用 XQuery 和 SQL；甚至可以使用 “双语” 查询，也就是在同一个查询中同时利用这两种语言的独特功能。新的高级 XML 索引技术补充了 Viper 对 SQL/XML 和 XQuery 的支持，能够提供很好的运行时性能。
关于混合型 DB2/XML 引擎的更多信息，请参考 DB2mag.com 上的 “Firing up the Hybrid Engine” Quarter 3, 2005。
在信息管理行业庆祝数据库管理系统的第 40 个生日时，IBM 邀请了顾客和合作伙伴来测试 DB2 “Viper”，这是一种混合型的数据服务器，它标志着信息管理技术的又一次进化。
信息管理技术始于 20 世纪 60 年代早期，也就是美国总统肯尼迪制订 10 年内实现人类登月目标的时候。1966 年，IBM 与 North American Rockwell（它赢得了发射第一艘登月飞船的合同）合作创建了一个自动化系统来管理建造飞船所需的大量资料。层次化的 Information Management System（IMS）和数据库管理技术本身由此诞生了。
下一个重要的里程碑也是在 IBM 出现的，即 20 世纪 70 年代关系模型和结构化查询语言（Structured Query Language，SQL）的发明。1982 年，IBM 在大型机上引入了 DB2，直到现在这仍然是世界各地的大银行和金融机构选用的数据库。随着市场开始在非大型机平台上实现应用程序，IBM 于 1987 年在 OS/2 上引入了 DB2，90 年代又在 AIX、AS/400、HP-UX、Solaris、Windows 和 Linux 上引入了 DB2。DB2 在这么多平台上的实现使得顾客可以选择最适合自己应用程序需要的版本。
目前，IBM 正在将数据服务器的进化推进到下一层次，引入了一种可以管理纯 XML 和纯关系数据的混合型引擎，即 DB2 Viper。DB2 Viper 中的新技术使公司能够充分利用非关系业务数据（比如 Excel 电子表格中的金融信息或通常存在于纸上或字处理文档中的重要合同）。利用 DB2 Viper，一个联结语句就可以将这些业务数据与传统的关系数据合并在一个完整的视图中。对电子表格、合同、传真图像或收据的手工搜索可以由一个简单的语句替代。对 XML 数据的标准化访问机制确保现有的报告工具和接口可以将这些新数据直接提交到桌面。纯 XML 技术提供了对业务成功很重要的敏捷性。
新的混合型 XML-关系功能不是 DB2 Viper for Linux, Unix, and Windows 上惟一的新特性。我将讨论 DB2 Viper 上可用的主要特性。您可以自己通过 Viper 的开放测试来尝试这些特性（ibm.com/db2/viper）。
XML 驱动业务
除了存储关系数据之外，DB2 Viper 的混合型引擎还能够使用纯 XML 结构存储 XML 文档。因此，正在逐渐转向 XML 的公司可以使用一种高性能的 XML 存储引擎，并利用工作人员现有的数据库技能来管理和保护 XML 数据（见图 1）。
图 1. DB2 混合型数据服务器能够管理关系和纯 XML 存储
由于许多原因，XML 对于当今的业务很重要。在面向服务的体系结构（service-oriented architecture，SOA）环境中，使用独立通用服务的思想使得不再需要为每个应用程序开发自己的访问方法了，并有助于应用程序的集成。XML 是应用程序和通用服务之间常用的消息传递语言。例如，在股票交易中，顾客通过一个 Web 界面购买一定份额的股票。这个 Web 过程向经纪人系统发送一个 XML 消息，从而执行交易。这个 XML 消息是临时的，只是为了触发经纪人系统而存在。DB2 Viper 可以保存这个 XML 消息，同时完整地保留它的数字签名。这样的话，就可以在金融审计中使用这些 XML 消息。
目前，大多数公司无法轻松地访问现有的业务数据，这是由于使用的大多数数据库技术、平台和数据格式的限制。通过创建一种统一的数据格式，SOA 通用服务可以从原始数据源接收数据，将数据格式化为一种标准格式，并存储在 XML 中，这样就对关键业务数据提供了灵活且标准化的访问方式。
能够存储业务关键型文档（比如 Excel 电子表格或法律合同）并将此数据与相关的关系数据联系起来，这是 Viper 关键的优势之一。Microsoft Office、Adobe 程序和大多数前端办公产品都提供了将文档存储为 XML 格式的功能。业务用户现在能够轻松地访问电子表格数据，因为 Microsoft Excel 电子表格（常常用来存储对于决策很重要的金融统计数据）现在可以按照 XML 格式存储在 DB2 Viper 数据服务器中，而不是存储在容易损坏的文件服务器或硬盘上。
纯XML
现有的关系数据服务器将 XML 文档存储为字符或二进制大对象（CLOB 或 BLOB）。但是，在 CLOB 或 BLOB 中，数据存储为单一的单元或连续的字节串。当查询 XML 文档中的特定值或者更新 XML 文档的一部分时，这种存储格式会造成性能难题。必须读取整个记录并进行解析，然后才能进行谓词评估。建立索引可以降低搜索成本；但是，对 XML 文档的更新要求更新 XML 索引。对 XML 文档的更新还需要重写整个文档。
对 XML 文档进行分解（Shredding 或 decomposing）是另一种 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 数据类型：
清单 1. 创建包含 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 是一种由 World Wide Web Consortium（W3C）推动的标准，设计它是为了查询 XML 的层次化结构，正如设计 SQL 是为了查询表格数据结构一样。XQuery 与 SQL 的不同之处是它能够提供路径表达式，使程序员能够在 XML 的层次化结构中导航。下面这个简单的 XQuery 示例返回客户的联系数据：
清单 2. XQuery 语句
xquery db2-fn:xmlcolumn('CLIENTS.CONTACTINFO')
假设希望检索所有提供了传真号码的客户的传真号码，那么可以编写下面这样的查询：
清单 3. 检索所有提供了传真号码的客户的传真号码
xquery
for $y in db2-fn:xmlcolumn('CLIENTS.CONTACTINFO')/Client/fax
return $y
第一行让 DB2 调用它的 XQuery 解析器。下一行让 DB2 遍历 CLIENTS.CONTACTINFO 列中 Client 元素的 fax 子元素。每个 fax 元素被绑定到变量 $y。第三行要求对于每次迭代返回 $y 的值。结果就是下面的 XML 元素序列：
清单 4. XML 元素序列结果
DB2 直接支持 XQuery 语言，这意味着它无需将 XQuery 转换为 SQL（转换会引入不必要的开销以及语义的不一致）。而且它不要求客户将 XQuery 语句包装在 SQL 语句中。DB2 客户可以按照自己的希望利用 XQuery 和 SQL；甚至可以使用 “双语” 查询，也就是在同一个查询中同时利用这两种语言的独特功能。新的高级 XML 索引技术补充了 Viper 对 SQL/XML 和 XQuery 的支持，能够提供很好的运行时性能。
关于混合型 DB2/XML 引擎的更多信息，请参考 DB2mag.com 上的 “Firing up the Hybrid Engine” Quarter 3, 2005。
6同行回答
谢谢了收起
浏览895
收藏。顶一下，辛苦了收起
浏览860
接上......应用程序支持 DB2 Viper 简化了在自己开发的或打包的应用程序中实现 DB2 的过程。新设计的 Developer Workbench 基于 Eclipse 平台，提供了与基于 Eclipse 的工具（比如 Rational Application Developer）的互操作性。这个工作台、支持的所有开发人员界面和 API...接上......
应用程序支持
DB2 Viper 简化了在自己开发的或打包的应用程序中实现 DB2 的过程。新设计的 Developer Workbench 基于 Eclipse 平台，提供了与基于 Eclipse 的工具（比如 Rational Application Developer）的互操作性。这个工作台、支持的所有开发人员界面和 API 以及新工具（比如 XQuery builder）都包含对新的 XML 技术的支持。容易使用的 XQuery builder 提供了语法彩色显示、自动代码补齐和许多其他实用程序，能够加快创建 XQuery 和 XML 文档的速度（见图 2）。
图 2. XQuery builder 界面
为了解决数据质量问题，DB2 Viper 允许在本地 DB2 存储库中可选地创建和注册 XML 模式。然后，在应用程序试图将文档插入或导入表中时，DB2 就可以针对这些模式检验 XML 数据。为了提供最大的灵活性，DB2 允许在表的同一列中存储与不同 XML 模式相关联的 XML 文档。这样做可以支持模式演化，并使 DB2 能够适应业务需求的变化，而不会破坏现有的应用程序或者被迫对数据库模式进行昂贵的修改。
除了 XML 增强之外，DB2 Viper 还针对 .NET 环境进行了改进。DB2 新的 .NET 数据提供者支持对 .NET Framework 2.0 类库进行访问。它还通过存储过程扩展 DB2 数据源访问，这些存储过程可以用任何 Common Language Runtime（CLR）兼容语言（比如 C# 或 Visual Basic .NET）编写。DB2 Viper 还引入了支持 Visual Studio 2005 的数据库插件。这些特性可以帮助开发人员减少为 DB2 服务器系列开发 .Net 应用程序的时间。（关于 .NET 改进的更多信息，请参见 Application Development。）
自管理内存
DBA 要负责确保应用程序和数据库的性能和可用性，他们很难挤出时间研究 XML 和 SOA 这样的新技术。最近的每个 DB2 版本都添加了减少数据库管理所需时间的特性，从而使 DBA 的工作更有效率。
DB2 Viper 引入了一种新的内存调整特性，它会自动地设置内存配置参数和缓冲池大小的值。启用这个特性时，内存调整器会在几个内存消费者之间动态地分配可用内存资源，包括排序、包缓存、锁列表区域和缓冲池。在 Windows 和 AIX 平台上，自调整内存特性还可以判断总的数据库内存需求，并动态地调整数据库共享的内存。这个特性使 DB2 能够在工作负载加大时使用更多的物理内存，在数据库内存需求降低时将内存释放给操作系统。
除了简化内存配置之外，新的自调整特性还通过提供一个优化配置来提高性能，它能够对工作负载的显著变化进行动态响应。
范围分区
在 Linux、Unix 和 Windows 上，DB2 引入的新的分区技术可以提高数据仓库的性能并降低管理时间。新的表分区方法通常称为范围分区，它允许为每个分区定义数据范围，并根据数据范围将数据存储为单独的对象。例如，可以根据表中的一个日期列，按照月和年对表进行分区。这些存储对象可以位于不同的表空间或同一个表空间中，或者两种情况的组合（见图 3）。
图 3. DB2 Viper 范围分区
不要将这种分区技术与 Database Partitioning Feature（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 是第一种同时支持全部三种数据库分区方法的数据服务器，这是数据管理和信息可用性方面的重大改进。
数据行压缩
早期的 beta 版测试结果表明，DB2 Viper 压缩技术最多可以节省 80% 的存储空间。由于行的大小减小了（这会减少 I/O 并提高缓冲池的命中率），物理 I/O 的数量和缓冲池需求也减少了。最终结果是在存储上花费的预算减少了，而且在某些情况下会提高性能。
DB2 Viper 压缩解决方案与 DB2 for z/OS 中使用的解决方案相似。压缩方法是将一个数据行中的重复数据模式映射为更小的符号，由此减小表数据的总大小。这个解决方案使用一种静态的基于词典的压缩算法，逐行进行压缩。与 DB2 for z/OS 中一样，使用 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(*) 函数只返回用户有读访问权的行的数量。
加速向前
DB2 Viper 代表着信息管理方面的又一次进化。它使公司有机会从根本上改变管理信息的方式。DB2 Viper 的纯 XML 功能对于 SOA 实现是一大帮助，因为 SOA 实现依赖于访问以不同格式存储的大量数据的能力。数据不再只限于静态的关系形式，因此 Viper 可以更好地交付信息，成为 SOA 环境中可被轻松访问的服务。
DB2 Viper 包含许多其他新特性，能够满足数据仓库、存储、安全和其他需要。但是，不要只听我说。请通过开放测试自己体会这些性能和处理特性。收起
应用程序支持
DB2 Viper 简化了在自己开发的或打包的应用程序中实现 DB2 的过程。新设计的 Developer Workbench 基于 Eclipse 平台，提供了与基于 Eclipse 的工具（比如 Rational Application Developer）的互操作性。这个工作台、支持的所有开发人员界面和 API 以及新工具（比如 XQuery builder）都包含对新的 XML 技术的支持。容易使用的 XQuery builder 提供了语法彩色显示、自动代码补齐和许多其他实用程序，能够加快创建 XQuery 和 XML 文档的速度（见图 2）。
图 2. XQuery builder 界面
为了解决数据质量问题，DB2 Viper 允许在本地 DB2 存储库中可选地创建和注册 XML 模式。然后，在应用程序试图将文档插入或导入表中时，DB2 就可以针对这些模式检验 XML 数据。为了提供最大的灵活性，DB2 允许在表的同一列中存储与不同 XML 模式相关联的 XML 文档。这样做可以支持模式演化，并使 DB2 能够适应业务需求的变化，而不会破坏现有的应用程序或者被迫对数据库模式进行昂贵的修改。
除了 XML 增强之外，DB2 Viper 还针对 .NET 环境进行了改进。DB2 新的 .NET 数据提供者支持对 .NET Framework 2.0 类库进行访问。它还通过存储过程扩展 DB2 数据源访问，这些存储过程可以用任何 Common Language Runtime（CLR）兼容语言（比如 C# 或 Visual Basic .NET）编写。DB2 Viper 还引入了支持 Visual Studio 2005 的数据库插件。这些特性可以帮助开发人员减少为 DB2 服务器系列开发 .Net 应用程序的时间。（关于 .NET 改进的更多信息，请参见 Application Development。）
自管理内存
DBA 要负责确保应用程序和数据库的性能和可用性，他们很难挤出时间研究 XML 和 SOA 这样的新技术。最近的每个 DB2 版本都添加了减少数据库管理所需时间的特性，从而使 DBA 的工作更有效率。
DB2 Viper 引入了一种新的内存调整特性，它会自动地设置内存配置参数和缓冲池大小的值。启用这个特性时，内存调整器会在几个内存消费者之间动态地分配可用内存资源，包括排序、包缓存、锁列表区域和缓冲池。在 Windows 和 AIX 平台上，自调整内存特性还可以判断总的数据库内存需求，并动态地调整数据库共享的内存。这个特性使 DB2 能够在工作负载加大时使用更多的物理内存，在数据库内存需求降低时将内存释放给操作系统。
除了简化内存配置之外，新的自调整特性还通过提供一个优化配置来提高性能，它能够对工作负载的显著变化进行动态响应。
范围分区
在 Linux、Unix 和 Windows 上，DB2 引入的新的分区技术可以提高数据仓库的性能并降低管理时间。新的表分区方法通常称为范围分区，它允许为每个分区定义数据范围，并根据数据范围将数据存储为单独的对象。例如，可以根据表中的一个日期列，按照月和年对表进行分区。这些存储对象可以位于不同的表空间或同一个表空间中，或者两种情况的组合（见图 3）。
图 3. DB2 Viper 范围分区
不要将这种分区技术与 Database Partitioning Feature（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 是第一种同时支持全部三种数据库分区方法的数据服务器，这是数据管理和信息可用性方面的重大改进。
数据行压缩
早期的 beta 版测试结果表明，DB2 Viper 压缩技术最多可以节省 80% 的存储空间。由于行的大小减小了（这会减少 I/O 并提高缓冲池的命中率），物理 I/O 的数量和缓冲池需求也减少了。最终结果是在存储上花费的预算减少了，而且在某些情况下会提高性能。
DB2 Viper 压缩解决方案与 DB2 for z/OS 中使用的解决方案相似。压缩方法是将一个数据行中的重复数据模式映射为更小的符号，由此减小表数据的总大小。这个解决方案使用一种静态的基于词典的压缩算法，逐行进行压缩。与 DB2 for z/OS 中一样，使用 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(*) 函数只返回用户有读访问权的行的数量。
加速向前
DB2 Viper 代表着信息管理方面的又一次进化。它使公司有机会从根本上改变管理信息的方式。DB2 Viper 的纯 XML 功能对于 SOA 实现是一大帮助，因为 SOA 实现依赖于访问以不同格式存储的大量数据的能力。数据不再只限于静态的关系形式，因此 Viper 可以更好地交付信息，成为 SOA 环境中可被轻松访问的服务。
DB2 Viper 包含许多其他新特性，能够满足数据仓库、存储、安全和其他需要。但是，不要只听我说。请通过开放测试自己体会这些性能和处理特性。收起
浏览903