DB2 管理：超级可用性

　　c我们请这位专家为我们解释开发战略可用性计划需要围绕的目标。他的回答是：

　　“永不宕机，永不丢失任何东西”

　　这寥寥几个字与商业理论家 Jim Collins(Built to Last and Good to Great的作者)称为 BHAG(Big Hairy Audacious Goal，发音为“bee-hag”)的思想不谋而合。BHAG 倡导大胆的前瞻性思维。(我的一位朋友曾这样反向解释过 BHAG 式思维：“如果目标定得低，所获得的成就也就如此。”)

　　让我们来剖析一下这个可用性目标

　　永不宕机

　　首先，很有必要理解“永不宕机”的含义(即我对它的理解以及前面提及的那位IT专家对其含义的定义)。它不是指以某段时间内消逝时间的百分比所表示的数据库或应用服务器的正常运行时间。不要曲解我的意思，设定和争取最佳正常运行时间的目标(比如，99.9%的可用性)很有用，尤其是对于负责应用程序基础架构的那些人(即系统管理员)而言更是如此。然而，从业务角度考虑，更重要的可用性度量手段是故障客户交互数(FCI)。这是一个重要的区分指标。请考虑如下的两个场景：

　　场景 1：公司 A 的 IT 部门经理正兴高采烈地庆祝工作成绩：过去1个月内可用性指标达到了99.95%。不料，负责客户 B 的客户关系经理忽然通知 IT 部门说公司 B 不大满意，原因是上星期发到公司A进行处理的事务中竟有很大一部分都没有被妥善执行。这是怎么回事呢?实际上这不是很难理解。有可能是处理公司 B 请求的某个基础架构组件(比如应用服务器)一时出了故障;当然，这对于有数百个服务器的系统而言还不足以伤及可用性指标，但却足以招致公司 B 的抱怨之声。另一种可能性是由公司 A 负责系统的团队没有注意到的某个应用的程序逻辑错误恰好影响到公司 B 发来的事务处理。

　　场景 2：一星期之后，公司 A 的一名 DB2 DBA Julie 遇到了棘手的事情——Linux 服务器上的一个 DB2 实例受到了宕机的影响。这个DB2 实例是 HADR(High Availability Disaster Recovery)配置的一部分(HADR 是我在“DB2 Disaster Recovery, Part 2”中所描述的一个 DB2 for LUW 特性)。受影响的这个实例在20秒后再度处理请求，但从达到本月的可用性目标而论，这20秒没有任何帮助。负责客户 B 的关系经理恰巧路过，Julie 本准备好了要应对这场免不了的口舌之争。但没想到关系经理却称赞她杰出的工作表现：公司 B 的事务没有出任何故障(事务超时值是30秒)。

　　因此，“永不宕机”真正的含义是“无 FCI”，而不是“无服务器宕机时间”。这无疑是件好事：允许存在某些不足以引起 FCI 的短暂的服务器宕机。这就意味着为了将DB2 for LUW维护应用于维护窗口之外而发起的 HADR 故障转移这样的动作与“永不宕机”的可用性目标没有任何矛盾(DB2 for z/OS 数据共享也允许应用程序维护应用于维护窗口之外，正如在参考资料部分列出的我的“DB2 Disaster Recovery”DB2 DBA 专栏中所描述的那样)。

　　不太好的消息是：高级 IT 专家并没有界定是“由于本地故障而引起的永不宕机”，他只说了“永不宕机”。这就表示 IT 部门不能对因灾难(洪水、火灾、地震、龙卷风)致使整个数据中心瘫痪后所需进行的应用程序服务恢复袖手旁观。

　　现在，已经有很多很棒的技术，可用来显著减少当主站点发生灾难时让应用程序系统在备用站点恢复运行所需的时间，其中最棒的要数基于磁盘阵列的数据复制。而且还有一些编程实践(比如，频繁提交)和 DB2 参数设置(比如检查点频率)可以使用，但是在数据中心范围的故障发生之后恢复系统而同时又要让用户感觉不到任何宕机时间，即使是做到天衣无缝，这个目标看上去也很难实现。

　　想想看：在主站点发生灾难的30分钟内让应用程序在备用站点就绪对 IT 部