从活跃会话数指标谈起

数据库中活跃会话数过多是引起数据库问题的一个十分重要的因素。不管是Oracle还是其他数据库，监控活跃会话数是发现系统问题的一个十分重要的手段。不过要分析活跃会话数过高就不那么容易了，这种分析是十分考验DBA的能力的。我以前在一个关于指标关联性分析的文章里发了一张Oracle数据库活跃会话分析的思维导图，可能实因为微信公众号上传后被压缩了，不是很清晰。前几天一个读者希望能发一张高清图出来，干脆今天我们就来讨论讨论这张图吧。这张图实际上是老白和技术团队的小伙伴们在这近二十年的Oracle数据库运维中的一些经验的总结。

这是从思维导图里直接导出的图，里面包含了我们技术团队这些年总结的和活跃会话过多相关的诊断路径。实际上这张图不太适合用思维导图来画，因为很多地方知识是网状的，存在大量的交叉和递归调用。在以前的那篇文章里，我是想用这张图来说明，对于一些数据库的问题，其诊断路径是如何的复杂。想要做到智能化诊断，必须至少要能够覆盖到这张图的水平，才能够获得较好的效果。

实际上智能化诊断的实现有很多种渠道，不过大部分做智能化诊断的厂家都会选择从数据入手，通过数据的异常来发现系统可能存在的问题，这种做法只要有算法工程师和略懂运维的人参与就可以开展，不需要大量的运维专家参与，比较容易开展工作。不过这条路对于一些较为简单的场景可能很有效，但是对于一些稍微复杂一些的场景就效果不佳了。今天下午在和公司的同事讨论“direct path write temp 平均等待时间”这个指标应该如何做问题归类的时候，有些同事说，最好能归类到一类比较确定的类别，因为他们发现有一些指标可以对应唯一的故障类。我请他们举个例子，大家想了半天，也只举出了空间不足的例子。我当时开玩笑说，空间不足几乎是所有的智能化运维系统介绍案例时都会提到的案例，我们能不能不用这个例子。然后经过冥思苦想，对应数据库指标，还真的很难找到能够归到唯一故障类的指标出来，能归类到唯一故障类的指标几乎都是操作系统指标。

某个数据库指标异常无法直接归类故障，这也是数据库智能化诊断比较难做的原因之一，哪怕我们拥有十分准确和完整的数据，我们都很难十分智能的、自动的对故障原因进行收敛，最后定位到唯一的根因上去。而活跃会话数（Active Session Count）是解释这个例子的最好的样本，也是最复杂的样本。不管是哪种数据库，如果能解决掉诊断活跃会话数异常的自动化故障定位问题，那么这个数据库的故障诊断应该至少已经解决了60%以上了。

我们对这张图中的三级路径进行裁剪，仅留下二级路径，这样可以看的更为清晰一点，不过这个经过裁剪的图，对于自动化诊断来说依然是太复杂了。以至于要想写一个工具实现对这个问题的分析也变得十分困难。事实上，在D-SMART中，最终和这个现象相关的诊断工具多大数十个，诊断路径有上百条。这些诊断工具之间还存在大量的下钻与二级关联，几乎可以形成一张覆盖整个Oracle数据库性能与故障分析的完整知识网了。因此针对这个问题的自动化诊断工具，其最后的难点是如何收敛结果。因为如果简单的通过有向图扫描所有诊断路径，最终的结果肯定是把所有的工具都执行一遍，然后所有的诊断路径中发现的问题再做汇聚。最终的诊断结论往往是一系列的问题，而很难收敛到根因上。

从这个例子我们也看到了，在这个不完整的诊断路径图中，一级诊断路径就有12条，几乎覆盖了从操作系统到数据库的主要维度。在不同的系统配置、不同的用户应用负载、不同的数据库参数配置下，可能会因为其中的某个或者某几个因素导致活跃会话数过多的问题。这些诊断路径是我们在这十多年中，通过上千个实际案例总结出来的。如果不通过知识梳理的方式，而采用深度学习的方法对数据进行分析，从而形成这样的诊断路径，那么所需要的数据和案例是海量的，其数据归集和数据标注工作也是一项巨大的工程。甚至在某个单一用户的生产环境中，哪怕积累10年的数据，都很难获得一个完整的模型。构建如此复杂的诊断模型，在一般的生产环境中恐怕很难实现。

基于这方面的考虑，我们觉得实现数据库运维中的智能化诊断，必须从深度学习和知识梳理两方面齐头并进，才能获得较好的效果，简单的通过一条技术路线恐怕很难获得好的效果。智能化运维不仅仅是一个软件，或者是一组算法模型，更多的是一种生态。利用更为广泛的生产案例（非单一客户的案例）来构建完整的诊断模型是完全可行的，因为同一种数据库在同一种内因外因下出现的故障，其内在原理是完全一致的。同时，一些目前智能化诊断还无法直接定位根因的情况，完全可以通过专家辅助来实现。

这就让我想起了两个例子，一个例子是2001年，我们的一帮朋友想做一个楼宇广告业务，他们拼命在攻克通过无线网络低成本传输大量视频文件的问题，这时候江南春已经开展这项业务了。当时我朋友不大相信江南春的技术比他们好，于是去调研了一番，发现江南春的分众传媒采用的是摩托车骑手插卡更换视频的方式实现视频分发的。

另外一个例子就是打码兔，在图像模式识别技术还没有达到今天水平的时候，带验证码的自动化登录必须解决自动识别验证码的问题。数据技术无法解决的问题，被华强北的“打码兔”给解决了。当自动化登录系统发现需要设别验证码的时候，立即把验证码的图片发给打码兔后端服务，打码兔用人工识别后立即回传给客户。虽然这个环节中还存在一个人工环节，不过其效率还是足以应付这个业务的需求。后来随着模式识别技术的发展，这个打码兔业务才寿终正寝了。

实际上，在智能化诊断发展的当前，类似打码兔的解决最后一公里的方法依然可以存在。让少数专家通过集中式服务的方式解决目前智能化诊断中的最为核心也最难以实现的部分，如果把这个生态化的服务构建起了，目前的各种智能化运维系统将会提升数个档次。