从一个数据库健康预警的案例谈起

健康分突然从平时的90多分下降到60多分。信息调度人员发现该问题后通知了运检中心进行分析处置。运检中心的人员对该健康情况进行维度分析：

发现数据库总体状况丢分严重，另外数据库命中率与数据库IO两方面的指标也比较差。由于现场的DBA属于系统监控人员，不具备深度问题分析的能力，D-SMART系统的运维经验报警模块又没有明显的报警，于是，现场人员决定求助基石数据三线专家。将该时间段的“状态巡检报告”打包发送给三线专家后，三线专家通过对“状态巡检报告”的解读发现该状态出现是因为另外一套系统通过DBLINK远程访问本数据库，对本数据库上的一张大表进行了全表扫描，触发了Oracle的一个BUG导致，如果该问题不进行及时处置，系统的DFS HANDLE等待会越来越严重，系统的整体性能还会进一步下降。于是三线专家建议在相关表上创建索引，并在晚上选择可停机的窗口对数据库实例进行重启（此BUG在11.2.0.4上暂无补丁）。

晚上完成紧急处置后，第二天系统恢复正常。事后，信息调度部门检查了该系统的HELP DESK申告记录，确实发现了在当天上午11点到17点期间，出现了数次业务部门申报系统业务功能缓慢的记录，通过电话询问业务部门，也确认了近期本系统性能不稳定。

由于本次性能处置遇到了一个以前D-SMART的运维经验没有包含的场景，因此通过本次处置，形成了第52号运维经验，在优化专家的协助下，确定了遇到类似问题的诊断路径，并通过知识点工具的组合，快速生成了诊断工具。下次类似情况发生时，运维经验会自动生成告警，同时现场运维人员可以使用诊断工具完成故障定位。

我们再次回顾一下本次优化工作的整个过程：

其实这种情况在我们日常的运维工作中十分容易出现，现场工程师一般来说处置复杂问题的能力较弱，而三线工程师如果无法直接连到用户生产系统上，要分析系统的问题也存在一定的难度，现场工程师与三线人员无法在同一个平面上进行对话，无法拥有共同的思维方式。健康管理工具与“状态巡检报告”把这一些分析工作程序化了，现场与三线专家拥有同样的数据，采取同样的维度分析方法去看数据。这样二者之间的互动效果将会大大加强，故障定位的速度也会大大提升。

另外，通过运维经验固化知识，通过工具化的诊断知识库来替代以前很难用的文字，使得我们遇到的任何问题都能被闭环管理起来，知识都能够沉淀下来，为以后的运维工作服务。通过常态化工作模式的优化我们将形成如下的工作流程：

如果中间无法形成闭环，网络不通，无法建立企业健康管理服务中心，那么用户的数据可以通过工具经过脱敏加密后通过邮件发送给三线专家，三线专家可以将数据导入后在三线数据中心使用工具对数据进行分析与处理。比较简单的问题直接通过生成”状态巡检报告“发送给三线专家，三线专家就可以完成分析了。