最后，还有协作方面的好处。CheckFree 的 IT 基础设施有意地设计成包含多个平台(我们常常说的一句话是，“使用正确的工具完成工作”)。在我们最大的部门中，核心业务应用程序运行在一个大型机 parallel sysplex 上。这个部门的操作数据存储(ODS)运行在一个单独的 System z 服务器上。我们的 EDW 运行在 IBM pSeries 服务器集群上，CRM 应用程序运行在一个单独的 Sun Solaris 服务器上。这些系统有什么共同点？它们都是基于 DB2 的。DBMS 具有共同的 “基因”，这会简化平台之间的数据转移，并增强人员配置的灵活性。最近，我们的大型机 DB2 团队中 DBA 人员过剩(尽管这些系统已经增长了，这是一种便于管理的环境)，而快速增长的 EDW 需要更多的 DBA 人力资源。我们让一位 DB2 for z/OS DBA 转入了 DB2 for LUW 团队，他很快就适应了新的岗位。DB2 for z/OS 和 DB2 for LUW 之间存在 DBA 能够察觉到的差异吗？确实有差异，但是与 DB2 for z/OS 和在分布式系统服务器上运行的非 DB2 DBMS 之间的差异相比，这些差异是很小的。

　　高可用性 vs. 拿起电话话筒就能听到拨号音

　　在 CheckFree，我们一直在为应用程序的可用性而努力。我们希望应用程序的可用性像电话拨号音那样持续不断，当您拿起电话话筒时，就一定会听到拨号音。DB2 能够提供这样的可用性。单服务器 DB2 系统已经能够提供极其出色的可用性；多服务器配置甚至能够进一步提高可用性标准。

　　前面作为规模扩展解决方案提到了 parallel sysplex 上的 DB2 for z/OS 数据共享，这种技术也能够在两个方面提高可用性：

　　减小服务意外中断的影响

　　如果数据共享组中的一个 DB2 子系统失败了(无论是由于服务器、操作系统还是 DB2 故障)，那么并不需要等待替代服务器接管这个子系统的数据库连接。组中的其他成员已经能够访问数据库，工作负载会自动地从失败的子系统转移到其他 DB2 系统上。失败并非毫无影响，因为在失败的 DB2 子系统重新启动之前，这个成员上运行的程序正在更新的数据库页面是不可访问的；但是，在通常情况下，处于这种状态的数据库页面所占的百分比非常小，子系统的恢复是自动的(如果 “主” 服务器和操作系统仍然可用，那么会 “就地” 恢复；否则，在 sysplex 中的另一个服务器上恢复)而且很快(在我们的环境中大约需要 90 秒)。与单独的系统环境相比，数据共享组中的 DB2 失败的影响要小得多。几个月前，我们的生产数据共享组中发生了一次 DB2 for z/OS 故障，但是客户都没有察觉到。

　　几乎完全消除有计划的服务中断

　　因为数据共享为所有 DB2 成员提供对数据库中所有数据的读/写访问，所以可以让一个 DB2 子系统临时停止运行，对它进行软件维护，然后让它重新运行，这个过程不会中断应用程序的处理(当一个 DB2 成员停止运行时，应用程序通信量会转给组中的其他成员)。这种功能让我们能够自由地对数据共享组进行维护，而不需要指定维护时间窗。

　　DB2 对于业务的意义

　　如果需要用业务人员能够理解的方式讨论 DB2，那么可以试试下面这些词汇。

　　可伸缩性：DB2 可以随着业务而增长，而不是限制业务的发展；

　　效率：DB2 可以降低数据服务平台的总拥有成本(TCO)，而数据服务平台是组织的应用程序的基础。降低 TCO 就相当于增加收入；

　　服务质量：DB2 技术可以减少有计划的应用程序系统中断，还可以缩小意外服务中断的影响和范围。因此，能够提高服务质量和客户忠诚度；

　　敏捷性：DB2 为访问和管理传统数据和非结构化数据提供了众多可选方法；这种灵活性可以帮助组织对市场机遇做出快速响应。

　　对于 LUW 环境，DB2 提供了一个多服务器解决方案，这个方案能够提供更高的可用性，但它使用的是在非大型机环境中更有意义的非共享体系结构。这个解决方案称为 High Availability Disaster Recovery(HADR)，它可以维护 DB2 for LUW 数据库的一个拷贝(使用单独的服务器和硬盘存储)，这个拷贝与主数据库保持精确的同步。HADR 的实现方法是，不断地将事务日志记录发送给备用服务器，备用服务器实时地处理这些记录。这种方法会让备用数据库与主数据库同步，而且更新过的页面的内存页面缓冲区也与主服务器上的缓冲区保持一致。因此，在主系统发生故障时，备用系统会非常快速地接管(通常只需要几秒)，而且不会丢失已经提交的数据库更新。HADR 还可以按照异步模式运行，这种模式适合长距离数据更新复制，在可以接受少量数据损失的情况下，这可以提供灾难恢复功能。

　　HADR 也可以减少有计划的服务中断时间，因为它使 DB2 for LUW 的维护几乎不需要维护时间窗。为使用 HADR 实现这种效果，DBA 应该临时终止从主服务器到备用服务器的日志记录流，在备用服务器上应用并激活软件补丁，重新启动日志的传输，恢复同步(这个 “追赶期” 通常非常短)；然后，通过一次用户发起的接管，交换主服务器和备用服务器的角色(这个过程应该只需要花几秒时间)。在此之后，重复前面的步骤，在 HADR 配置中原来的主服务器(现在的备用服务器)上应用并激活软件补丁。

　　敏捷性 vs. 对新的需求做出快速响应

　　DB2 能够帮助组织对挑战和机遇做出快速响应，因为它能够提供多个访问 DB2 数据库中的数据的路径。您希望从 Java 应用程序访问数据吗？没问题：DB2 提供了 JDBC 驱动程序并支持 SQLJ，因此能够在 Java 应用程序中使用嵌入的预绑定的 SQL 语句。数据请求来自 Windows 系统上运行的 .Net 应用服务器吗？DB2 提供了 ADO.Net 驱动程序，并与 Microsoft 的 Visual Studio 应用程序开发工具集成。您希望使用服务器端 SQL 吗？DB2 存储过程可以用几种编程语言来编写(包括 Java)，也可以采用 SQL 存储过程的形式。在大型机环境中广泛使用的 CICS 和 IMS Transaction Manager 程序可以提供更多的服务器端 SQL 方式。对于文件处理这样的任务，批处理程序具有很高的效率。

　　通过 DB2 与 IBM WebSphere MQ(一种消息排队和传递技术)的集成，应用程序开发的灵活性会得到进一步增强。将 MQ 插入基于 DB2 的基础结构中是一种增强系统弹性的好方法：如果应用程序的 “处理消息” 的组件不可用(由于故障或有计划的停机)，那么从客户机系统收到的消息就会累积在队列中，当不可用的应用程序组件再次联机时，它会继续从队列中获取消息。从发送消息的用户或客户机应用程序的角度来看，并没有出现服务中断。MQ 队列还有助于控制大幅度变化的工作负载量，其作用就像是汽车引擎散热器的附属水箱：消息处理应用程序可以按照自己的节奏处理消息；如果消息到达的速度超过了处理消息的速度，那么消息就会累积在队列中，而不会造成 “目标” 服务器过载。DB2 和 MQ 组合的优点还包括：协调的提交和回退(如果程序在 DB2 表中插入一行并在 MQ 队列中放一个消息，那么当这个程序失败时，DB2 和 MQ 更改会回退到最近的提交点)；DB2 函数支持程序使用 SQL 语句与 MQ 交互；MQ 实用程序与 DB2 实用程序非常相似，因此 DB2/MQ 的交叉培训非常容易。

　　数据级别上的灵活性怎么样呢？DB2 可以存储和管理传统的文本和数字数据，还可以非常高效地管理大对象(LOB)，比如文档、图像和音频文件。DB2 9 引入了先进的 XML 数据存储特性，在存储 XML 文档时可以保留数据元素的结构特性，还可以使用 SQL 或 XQuery 高效地访问数据。当然，可以在 DBMS 之外存储 LOB 和 XML 文档；但是，将这些数据类型存储在 DB2 中，就可以为集成数据管理、安全性以及备份和恢复提供一个现成的解决方案。其结果是，管理和保护数据所需的时间更少了，可以留出更多的时间来开发使用数据的应用程序。

　　技术的最终目的

　　我很喜欢谈论在各个平台上 DB2 中使用的高级技术。但是，技术必须能够帮助我的公司实现业务目标；否则，就是浪费资金。大多数业务人员对 IT 产品的要求只有几点：产品必须能够工作(可靠性)，它们不能限制公司在市场上的作为(增长和创新)。DB2 在 CheckFree 的各个平台和应用环境中表现出了这些品质。业务人员需要的就是这些；技术人员请务必注意这一点。