活跃会话数分析思维导图的分解（1）

前两天写了两个活跃会话数异常的案例，有几个朋友在私信上索要活跃会话数异常诊断的那张脑图，确实那张图密密麻麻的，上传倒微信公众号上就很模糊了。我曾经在私信里发给过网友，效果也不好。正好我们实验室的数据中有不少客户活跃会话数过多的案例，结合这张图，我分几次写几篇文章，把这张图的每个路径都简单介绍一下，我想这样比简单的贴出一张图更好一些。因为需要找到相关的案例数据，所以可能这个系列会断断续续，希望有兴趣的朋友随时关注一下。如果把主要的诊断路径都找到案例介绍一下，估计个把月时间就不用写别的了，可能你们也会看腻，我也会写腻。

这个案例的活跃会话数从早上9：02开始突然增加，最高到达75个，然后逐渐下降，十多分钟后逐渐恢复正常。

从上面的异常指标来看，这个时间段内出现的异常指标也是十分多的。从种类上看，和IO相关的指标异常较多，不过里面多了一个latch free这个问题，导致整个问题的分析路径变得复杂了。因为latch free可能导致其他任何指标异常，也可能是其他指标异常导致了latch free，鸡生蛋还是蛋生鸡的问题会让这个技术问题变成一个哲学问题。

我以前也说了，目前的智能诊断工具针对活跃会话数异常的分析还不够准确。而且目前的BETA版本中还缺少了最终版本中的路径最终裁剪的能力，因此可能给出的诊断结论过于宽泛。从最终给出的结论来看，是SQL执行并发量过大，REDO量过大，IO存在问题这几项可能实最终原因。

虽然目前的智能诊断算法还不够完善，不过我们依然可以通过关联性分析来进行问题的定位。

从关联度分析上看，和当时这个异常相关的指标排名靠前的是CPU使用率，OS LOAD ,library cache lock平均等待时间，数据文件并行写延时，每秒解析数量，大表扫描数量，每秒执行数量，每秒登录会话数量等。从这个角度来看首先是系统负载增加了，导致了一些共享池库缓冲闩锁延时增加，最终导致了活跃会话数的增加。当然，大多数活跃会话数的增加的根本原因都是应用负载引起的，这个也不例外。不过如果业务系统就有这样的负载，我们暂时无法对应用系统进行整改，是不是可以通过调整数据库来解决这个问题呢？

CPU飙升的曲线和活跃会话数增加是完全同步的，不过CPU最高也只到达了74%，并没有出现瓶颈。当然以前我也说过,X86的CPU，如果使用率超过67%，那么超线程结构已经会产生等待，CPU的处理延时已经不是最佳的了。

在这个时间区间里，library cache的命中率确实出现了类似的变化。

REDO 量的变化曲线和活跃会话数的曲线相比，存在延后，因此REDO量并不一定是问题的根因。不过存在一定的相似性。

数据库并行写的延时指标也是存在一定延时的，不过基本上在同一个水平线上。

Library cache lock的曲线与数据库并行写延时类似，看样子他们都是受到同样一个因素影响的受害者。而不是根因。

每秒登录数的曲线与活跃会话数十分吻合，这个不起眼的原因真的很有可能和这个活跃会话数异常的现象关系密切。

这个案例十分的复杂，我在D-SMART的帮助下，花了近1个小时的时间分析了这段时间内的数据库情况。发现引起活跃会话数异常的原因是多方面的。这是典型的企业刚刚上班时候，大量用户正在登录，同时昨天晚上做的RMAN备份还没有做完，IO负载较高，IO延时也不尽如人意。早上系统的签到业务也产生了大量的REDO。这些因素综合起来才触发了一段时间内数据库系统性能不佳。实际上这套系统在之后的半小时左右的时间里，一直存在十分严重的性能问题。

这个问题的定位是十分准确的，IO问题引起了系统的严重性能问题。

这个探针应用周期性的执行相同的业务，其执行时间出现了十分严重的波动，这段时间内，业务部门反馈也是系统很慢。过大的并发，SQL写的不够优化当然是其最重要的原因。不过DB CACHE/log buffer/shared pool等配置的不合理，进一步加剧了这些问题。过慢的备份速度，导致第二天备份还没有完成也是造成这次性能故障的元凶之一。

从上面这个案例可以看出，活跃会话数异常的问题是十分复杂的，有时候根因也是多方面的，甚至有些原因是相互影响，像几个浪交会一样，会积聚能量，形成更大的浪。这也导致了活跃会话异常分析变得十分困难。我们已经做了两年多的优化，针对这个问题的根因分析的算法依然不尽如人意。

今天我们涉及了几条主要的诊断路径，我分别把这部分图贴出来。

系统资源瓶颈是引起活跃会话异常的一个原因，今天我们分析了，CPU使用率虽然较高，但是还没有达到引发问题的极限。

闩锁争用特别是library cache相关的争用是引发问题的几个浪头中的一个，这一点我们在前面也已经分析到了。在绝大多数的活跃会话数异常的案例中，闩锁问题都不是最初的根因，但是大多数情况下，引发连锁反应，导致更严重问题的因素都会有闩锁的因素。

日志问题也是导致这个问题的浪花之一，同样的还有下面的OS IO延时问题。

系统负载过大是这些浪花中最大的一朵，特别时超高的登录数。这个登录波动一直持续了很长时间。

最后一个因素就是维护作业。在这个问题中，RMAN备份是导致系统恶化的原因。

活跃会话异常分析十分复杂，也十分考验DBA的能力。因此也是ORACLE数据库运维中最难的一件事，就像这个案例一样。通过综合分析，我们给客户提出的建议是服务器的内存扩容倒512GB，SGA_TARGET加大到260GB，把数据库全备任务提前4小时，可以有效的避免类似问题的发生。这个优化建议是不是有点让人感到意外？这实际上是解决这个问题的最省钱的方案，也是可以马上实施的方案。