DB2 for Linux, Unix, and Windows 的下一个发行版(预计于今年年底推出)承诺改进 XML 开发、可用性、安全性、工作负载管理等特性，以帮助 IT 部门跟上不断变化的业务需求。
如今，实时数据对于企业来说至关重要。企业必须要以信息为基础来做出正确的决策，赶在竞争对手前发布新产品和新服务。这给 IT 部门带来的挑战不仅仅是要跟上变化的步调，更重要的是领导向业务需求看齐的创新过程。
Business Performance Management Institute(bpminstitute.org)最近开展的一项调查表明，对整体业务影响最大的因素就是IT 部门能否快速、灵活、及时地交付应用程序。但是调查也显示，只有 11% 的调查者认为他们的IT部门的变化过程可以跟得上业务需求。
响应业务需求的能力源于灵活的基础。“Viper 2”(DB2 9.5 版本的代码名称)就提供了这样的基础。
敏捷的 XML 开发
在 DB2 9 中，IBM 创建了一个新的混合数据服务器，可以同时管理关系型和 XML 数据存储库。DB2 Viper2 扩展了这种“纯 XML ”能力，以加快应用程序的交付。
XML 专为敏捷性而设计。它的众多特征使之非常适合动态企业应用应用程序，自描述元素、平台无关性和方便的可扩展性只是其中一部分。新的 DB2 Viper 2 特性又进一步增强了这种敏捷性。
XML 提供了快速传送数据的能力(这是 XML 盛行的原因之一); XSLT 是最流行的 XML 转换方式。DB2 Viper 2 内置 XSLT 支持。新的 XSLTRANSFORM 程序可将数据库中的 XML 文档转换为 HTML、普通文本或者其他格式的 XML。
XML 流行的另外一个原因是能够快速地更改 XML 记录。DB2 可以让您实时更新 XML 模式，而不会失去对已有 XML 文档的访问。XML 定义通常存储在 XML 模式中。DB2 Viper2 引入了模式演变，提供了根据一个注册模式的演化版本验证已有的和新的 XML 文档的能力。UPDATE XMLSCHEMA 命令和 XSR_UPDATE 存储过程让您可以修改已经在 XML 模式库中注册的 XML 模式，并且无须重新验证已有的 XML 文档。
减少系统宕机时间
从 8.2 版开始，DB2 for Linux, Unix, and Windows 中就已经提供了高可用性灾难恢复。DB2 HADR 维护一个备用数据库，它复制主 DB2 服务器上的更新。如果主 DB2 服务器停止工作，则可以通过在备用服务器上发出接管命令，让备用服务器接管主服务器的工作负载。为增强 DB2 高可用性的功能，DB2 Viper2 AIX 和 Linux 发行版中将包括 Tivoli System Automation(TSA)。TSA 检测停机故障，并自动发出接管命令(如图 1 所示)，从而提供自动化的 DB2 服务器故障恢复。现在可以使用 DB2 Viper2 中包含的 DB2 安装器或者 Tivoli 脚本安装、更新和卸载 TSA。
图 1. DB2 HADR(高可用性灾难恢复)和 TSA 的配置
DB2 的每个版本都包括了一些有助降低成本的改进; 即将发布的版本也不例外。DB2 Viper2 通过定期移除旧的文件来自动减少备份、负载拷贝和记录文件的存储占用量。在 DB2 9 中，DB2 数据服务器定期自动移除这些文件; DB2 数据库管理器剪除超过 num_db_backups 指定数量和早于 rec_his_retentn 指定的日期的历史文件记录。Viper2 版本包含了新的配置参数 auto_del_rec_obj; 当这个参数被设为 ON 时，数据服务器删除与它剪除的历史文件相关的备份、负载拷贝和日志文件。
对于数据仓库，DB2 Viper2 包括了一些增强，可提高分区数据库的整体可用性。在 Viper 2 中，当对某个分区数据库的编目节点进行备份时，可以指定将哪个分区包括在备份中。这些分区将会同时被备份。
为了辅助恢复，可以使用新的 END_OF_BACKUP 子句将分区数据库中的所有分区前滚到最小恢复时间，这是前滚期间使数据库取得一致的最早时间点。这个特性消除了手动确定一致点所需的时间，并提高了恢复的速度。
一些增强在缩短离线数据重分发时窗的同时，也提高了 DB2 分区数据库的可用性，确保数据仓库对企业是可用的、可访问的。DB2 Viper 2 随后的修复包中将提供对离线数据重分发的性能增强。
治理和安全性
随着对随处访问信息的需求的日益增长，数据窃取和失去安全控制的风险也越来越大。原先只对内部员工开放的数据，现在被提供给业务伙伴和客户——因而也更易受到未经授权的访问的攻击。来自行业法规和公共审查的压力越来越大，信息安全团队面临保护关键企业数据(公司财务、信用卡、个人身份、个人健康和知识产权信息)不受来自内部和外部的侵害的挑战。
DB2 Viper2 审计功能的显著增强提高了审计的性能，新的审计功能提供了足够细的粒度，可以只审计敏感的对象。DB2 Viper2 还提供了审计归档功能，以保留审计信息，用于将来的报告和调查。在参考资源的“Analyzing Audit Data in Viper 2”一文中，我对这些功能作了详细的解释。
三层应用程序在近年来非常流行，特别是随着基于 Web 的技术和 J2EE 平台的出现，这种模型更加盛行。三层应用程序模型——受到 WebSphere Application Server (WAS) 等产品的支持——扩展了标准的两层客户机/服务器模型，在客户机应用程序(WAS)与数据库服务器(DB2)之间增加了一个中间层。
在三层应用程序模型中，中间层负责认证用户和管理与数据库之间的交互。当一个用户经过中间层的认证后，每次都使用同一个用户 ID 和密码访问数据服务器。由于数据服务器将数据库权限授给中间层的用户 ID，因此应用程序的每个用户都享有和中间层应用程序一样的权限。所以审计报告只限于中间层的用户 ID，而不会针对请求数据的实际用户(如图 2 所示)。
图 2. 三层应用程序模型
尽管三层应用程序模型有很多优点，但也引发了一些安全问题，例如丢失用户身份。中间层用户 ID 将用于所有数据库连接; IT 安全最佳实践倾向于将实际访问数据库的用户身份用于控制目的。由于中间层用户 ID 不是真正的终端用户 ID，它并不提供大多数公司需要的审计和用户问责能力。
另外一个问题是过分授予特权。中间层的授权 ID 必须拥有执行来自所有用户(通常来自所有应用程序)的请求所需的所有特权。这导致用户拥有对某些信息的不必要的访问权。当前业界的实践要求，中间层使用的授权 ID 必须受保护，并且只能授给尽可能少的用户。如果中间层的授权 ID 受到危害，那么所有资源将被暴露。
这些安全问题突出了将初始用户 ID 传递给数据服务器，以便进行精确的审计和访问控制的必要性。为解决这些问题，DB2 Viper 2 发行版引进了“受信任上下文”。安全管理员(拥有 SECADM 权限)可以在数据库中创建一个受信任上下文对象，该对象定义数据库与中间层之间的一个信任关系。当连接属性与 DB2 服务器中定义的受信任上下文的属性匹配时，数据库连接便可以视为受信任的连接。信任关系基于以下一组属性：
系统授权 ID：代表建立数据库连接的用户;
IP地址(或域名)：代表数据库连接建立的主机;
数据流加密：代表在数据库服务器和数据库客户端的数据通信的加密设置(如果有)。
随后，中间层即可建立一个显式的到数据库的受信任连接，这使它可以将连接上的当前用户 ID 切换为不同的用户 ID，用户 ID 可以有也可以没有认证。此外，受信任上下文还提供了另一个优点：控制将特权授予数据库用户的时机的能力。安全管理员可以将一个或多个特权授予一个数据库角色，并且将该角色赋给一个受信任的上下文对象。只有与那个受信任上下文的定义相匹配的受信任的数据库连接(无论是显式的还是隐式的)，才能利用与那个角色相关的特权。
DB2 Viper2 增加的另外一个新的安全对象是数据库角色。数据库角色通过简化数据库特权的管理，降低了被入侵的风险。数据库角色是一个对象，其中包含一个或多个特权或数据库权限。用户、组、PUBLIC 或者其他角色可以成为数据库角色的成员。常常可以通过建立角色来反映一个组织的结构。例如，可以在数据库中创建与组织中的工作职能直接对应的角色。安全管理员只需增加适当角色的成员即可控制数据库访问，而不必为每个用户定义所有的访问权。
工作负载管理
DB2 Viper2 在性能上的提升主要集中在优化访问和更新大量数据的性能上。在过去，所有在数据服务器中执行的事务被认为具有同等重要性，意即最高优先权、高性能和低延迟。为了在整个系统上取得这样的高性能，企业必须不断地升级。既要降低成本，又不能牺牲敏捷性，这样的压力使企业认识到，不能把所有事务看作是同等重要的。通过根据业务的优先级平衡资源，企业就可以在降低成本的同时，继续提供它所关心的高性能。
DB2 Viper2 集成了一组新的工作负载管理特性，用于在 DB2 数据服务器中直接识别、管理和监视数据服务器工作负载。通过将工作负载定义与服务级别相关联，即可使用一个预测模型或反应模型为每个不同的工作负载定义优先级。这使企业可以调整 IT 应用程序的业务目标(如图3 所示)。
图 3. 分配服务器的工作负载和服务等级
利用 DB2 工作负载管理特性，可以根据工作负载定义自动将工作划分为易于管理的逻辑分组，将工作负载与服务级别相关联，然后将资源分配给每个服务级别。可以获取详细的工作负载配置和性能信息，以帮助改进工作负载和服务级别定义。
也可以使用新的工作负载管理特性，通过成本、时间和并发阈值控制执行。这些阀值可用于控制危险的查询，并帮助满足服务级别协议(SLA)目标。通过使用阀值，系统可以自动对不好的情况做出反应，或者事先预测到事故的发生。在控制长时间运行的和复杂的查询的影响的同时，可以保持事务的顺利运行。您可以跟踪每个处理阶段，为用户提供最新的状态信息。
在 AIX 操作系统上，可以将 DB2 服务级别与 AIX 工作负载管理器(WLM)服务级别联系起来。例如，AIX WLM 可以动态地调整 CPU 共享，或者使用其他服务级别剩下的 CPU 共享。
用于提高性能的增强的统计
对于查询性能，十分关键的一点是，在优化查询时具有正确的统计信息。DB2 8.2 引入了自动统计信息收集功能，该功能可以监视表，并收集所需的关于表的统计信息。虽然这个后台过程确实可以选择何时收集统计信息，但是只限于预先定义的维护周期。从更改数据到收集新的统计信息，这之间可能有一个时间间隔。DB2 Viper2 中的实时统计信息收集功能填补了这个空缺。当提交一个查询时，优化器判断受影响的表的统计信息是否准确。如果没有统计信息，或者查询没有像优化器预期的那样运行，那么受影响的统计是否精确。如果没有统计信息，或者查询并不是像优化器预期的那样进行，则立即更新统计信息，以提高下一次查询的性能，而不必等待一个维护时窗。
乐观锁定
DBA 常通过调优来解决数据库响应时间问题，往往没有考虑到问题可能与并发有关。Viper2 引入了“乐观锁定”技术，这种技术不会在选择一个行与更新或者删除这个行之间保持行锁。应用程序程序编写为乐观地假设未锁定的行在更新或者删除操作之前不大可能会被改变。如果行确实被改变了，那么更新或者删除将会失败; 对于这样的失败，应用程序逻辑会再次尝试选择(举例来说)操作。使用乐观锁定可以提高并发性，因为其他应用程序可以同时读写那一行。但是，如果在读操作与更新或删除操作之间数据行发生的变化，那么应用程序就需要重试逻辑。在三层环境中，业务事务常常没有与数据库事务相对应。这时就不能使用锁，因为不能在整个业务事务中维护锁。在这种情况下，乐观锁定成了很好的方法，它可以减少锁竞争，同时不会牺牲数据完整性(虽然乐观锁定刚刚被引入 DB2 for Linux, Unix, and Windows，但是早已被提供给 DB2 for z/OS 用户)。请参阅 2007 年 11 月一期和本期 DB2 Magazine 中的文章，以了解更多关于该平台上的乐观锁定的信息。
抢先使用 Viper 2
DB2 Viper 2 构建在 IBM 去年引入的混合型 XML 和关系数据服务器的基础上。抢先试用 Viper 2 可以增加您的 IT 敏捷性。
1
