为什么我现在不怎么看AWR报告了

白鳝的洞穴 2022-03-24

1757

二十年前我在DBA圈子里推广STATSPACK报告，那时候大多数DBA分析问题还是习惯于用一些自己写的脚本，而不习惯于使用STATSPACK报告。这是因为Oracle官方并未提供任何阅读报告的辅助性的资料，对着天书一样的指标数据，压根儿就摸不着头脑。

从Oracle 7.3的OWI出现之后，我一直认为OWI是打开Oracle数据库这个魔盒的关键。2003年开始，正好和Oracle开展一些优化服务方面的合作，因此我有权限访问WEBIV等内部系统。从而获得了使用一个称为PTA的工具。这个工具可以输入一份STATSPACK报告，产生一系列的分析报告。

我利用那个工具分析了近百份存在问题的系统的STATSPACK报告，通过研读分析，逐步理解了其中的一些关键指标和等待事件，掌握了阅读STATSPACK报告的一些技巧。充分掌握了解读报告的方法之后，STATSPACK报告成了我分析客户Oracle数据库离不开的工具。

后来数据库升级到10g了，易读性更好的AWR报告也替代了STATSPACK报告。不过虽然如此，AWR报告对于大多数的DBA来说，依然是不够友好的。在这十多年里，我多次产生过自己写一个PTA工具的想法，通过这些年积累的经验来解读这份报告，生成一份更加易读的报告出来。不过做了几个工具，发现其水平顶多也就达到了ADDM的水平，真的很难在实战中使用。

虽然这些年AWR报告的进步很快，已经纳入了ADDM、ASH等相关信息，能够提供的信息更为丰富了，甚至很多国产数据库也在学习AWR，构建了自己的性能分析报告体系。不过作为一个干了二十多年系统优化的老DBA，我依然认为AWR报告能够给我们提供的信息，以及信息的展现方式还是不够理想。

在某些场景中，因为AWR展现的是一段时间的平均值，因此可能会让人无法感知一些细节的问题，虽然AWR也提供了等待事件的直方图信息，不过仅仅能够让我们在平均值中间感知一些少量的异常值而已。很多指标的变化是有因果关系的，也有关联关系，这些关系我们无法从AWR中看的很清楚。另外在一个一小时或者半小时的区间内，如果问题只是几种在其中的三五分钟，那么可能一些其他的亚健康状态会掩盖掉着几分钟的信息，从而引发误判。前两天，一个网友发了一份AWR报告，让我帮助分析一下。从报告上，他认为共享池和解析出了问题。

从ADDM的分析中的发现都是和硬解析有关的。甚至LATCH FREE也有可能是硬解析引起的。

解析消耗的CPU比例也很高，一些“资深”的DBA或者遇到过类似问题的DBA可能会从这些数据中看出解析的问题。

当然也少不了TOP EVENT的数据，可能看到这些数据，大多数朋友会毫不犹豫的判断硬解析引发了性能问题。因此我简单看了看，就认同了他们的怀疑，并和他一起讨论了一些解决硬解析问题的方法，然后就去干其他事情了。

过了一阵子稍微有点空，我又想起了这份AWR报告，多年的工作习惯还是让我再次打开，认真的看了看Load profile。

每秒5000多次的执行，4000多次的PARSE，200多次的HARD PARSE，无论如何也不会让一台8路服务器跑崩掉。似乎这点负载还不足以引发严重的性能问题，是不是还有其他因素呢？

从OS的状态看，CPU的使用情况是没有问题的。因此哪怕SQL解析占用的CPU高一点，也不至于出现严重的性能问题。另外，从TOP EVENT的平均等待时间上来看，都不是很高。说明系统中在这方面的等待问题并不是特别突出。

认真看一下Wait Classes汇总信息，就能够看到一些疑点了，Concurrency带来的总等待时间只占DB TIME的9.4%,而Other震了34.1%，是除了DB CPU外最多的。当然DB CPU里也有50%左右是用在解析上的，算起来OTHER和并发引起的问题的重要性差不多。从前面我们也可以看出，这个OTHER最主要的是LATCH FREE。

那么这个问题就更为复杂了，如果LATCH FREE中的主要有问题的闩锁都和硬解析有关，那么这个问题定位在硬解析上就很合理，否则这个定位还是不一定成立的。还有可能因为LATCH FREE导致了硬解析变慢。

在上百个闩锁里找问题还是挺费劲的，我走了一个捷径，先看一下LATCH SLEEP BREAKDOWN。因为如果闩锁引起性能问题，一般都是出现了比较严重的SLEEP，因此SLEEP比较高的闩锁往往可能是出问题的地方。这是一个按照SPIN 的次数排序的列表，一般来说，SPIN比较高同时SLEEP比较高的可能是存在问题的闩锁。

从上面的情况可以看出，排在前面的都是和GES相关的，而并不是和共享池相关的。于是我再次阅读这份报告，重点分析了RAC性能相关的指标。

500字节的PING延时两个实例是不同的，2->1是1->2的两倍，而且都超过100毫秒。这个指标明显是不正常的。于是我把这个发现和网友进行了讨论。后来他们关闭了其中一个实例，PARSE的问题居然就消失了。

后来的进一步分析，很可能这和19C的一个GES相关的BUG有关，不过总体上来看，最后这个分析没有被带到沟里。从这个案例可以看出AWR分析的复杂性，哪怕是经验丰富的专家，在第一时间里都很难一次性准确定位。甚至看到PING延时问题的时候，也还不一定真的就是能够完全确定GES是根因，因为19C ADAPTIVE SQL PLAN的BUG，也会有类似的表象。因为这个问题可能因为ROW CACHE方面的锁而导致GES的量过大，从而触发19C的GES HASH BUCKET的BUG。二者之间的因果关系很可能倒转。

正是因为AWR分析的复杂性，用AWR来定位问题十分困难，特别是在需要紧急处置的时候，根本不可能给专家这么多时间来慢慢阅读报告。往往只能采取更为极端的方式，比如重启数据库。自从2017年开始开发DBAIOPS产品D-SMART之后，我的思维方式已经从AWR报告的宏观分析逐步转到以自动异常检测算法为主要手段的自动化分析上了。我们的客户的系统出问题的时候，刚刚开始的时候我还习惯于找一份AWR报告来读读，后来这个习惯就改掉了，因为我发现智能化算法生成的诊断结论更具有导向性。

DBAIOPS可以瞬间帮你大体定位问题，让你能够很快就找到问题分析的主要方向。同时还会为你推荐一系列的诊断工具，让你能够快捷的完成下钻溯源或者结论验证。甚至直接告诉你问题所在与解决方法。

利用这个工具我曾经创造过5分钟定位了一个客户现场专家分析了两三天没有定位的问题。当我拿到监控数据后，没有打开AWR报告去阅读，而是直接在实验室利用智能分析工具进行分析，第一步定位就基本上确定了问题的大体方向。随后通过两次下钻，我就拿起电话和客户讨论这个CASE了。如果还是采用AWR分析的方式，哪怕我仔细阅读完AWR报告也至少要花上一两个小时。

另外AWR报告里无法提供一些更为细节的内容，比如问题严重时段的等待事件链，某些指标变化的趋势等。而在DBAIOPS系统中，我拿到的问题数据包就像是一个数字孪生体，我可以从各个角度去看它，这种立体的CT扫描一样的辅助工具，比AWR中枯燥的数字要容易解读的多。

我现在不怎么看AWR报告了，并不是因为AWR报告不够好，AWR报告中包含的技术细节十分丰富，只是解读它太困难了，太耗费专家的时间了。而通过DBAIOPS，我们可以换一种更为轻松的方法去解读系统。这个世界的推动技术发展的是懒人，不是吗？

数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

为什么我现在不怎么看AWR报告了

评论