从活跃会话数指标谈起

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

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

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

某个数据库指标异