宏观分析与微观分析

上星期我在高铁上的时候，一个朋友发来两份awr报告让我帮着分析一下，在火车上，看着手机屏幕，对于已经老花的我来说十分痛苦，因此只是简单的看了一下。

系统也没有什么特别明显的问题，不过从AWR上看，系统似乎存在一些问题。

从TOP EVENT上看，确实排在前面的都不是正常的等待事件。其实这种情况在现在的运维实践中是经常遇到的，系统也不是不健康，也没有什么特别明显的问题，不过一些指标出现了异常，这种状态我们称之为“亚健康”状态。在之前我们分类系统的状态的时候，把系统分为健康状态和不健康状态。而不健康状态的定义很宽泛，有时候是宕机了或者即将宕机或者系统HANG住了，有时候系统出现了卡顿但是很快就好了。而如果引入第三种状态“亚健康”状态后，对于系统的分类就更容易了。对于不健康状态的系统的分析，通过AWR报告是十分容易定位问题的，不过对于亚健康状态的系统，就没那么容易了。似乎我们能看到很多不正常的指标，但是我们不确定这些指标是否会引起更大的问题，或者说这些指标是不是导致一些问题的根源。

实际上我们要想看懂上面的这组数据，光凭着上面我贴出来的数据是不足够的，当然有些DBA看到上面的等待事件，就开始断言row cache出现了较大的争用，一定是共享池出问题了。因为一个小时内，latch:row cache objects出现了1200多万次等待，占了总等待事件的35%。我们实际上可以做一些更为精细的分析，分析之前，我们需要一些更多的信息。比如这台数据库服务器的配置情况。

从AWR报告中我们可以看到这是一台比较老的4路服务器，每路8核，合计32核，64线程。内存大概是512GB的，从操作系统上看到500G。除了硬件的信息，我们从上面的信息中还需要了解会话的情况，从上面的begin/end来看，大概有700个会话。

另外我们需要知道数据库的负载情况。这个从AWR的LOAD PROFILE中可以获得大部分的信息。

从上面的LOAD PROFILE看，每秒12M左右的REDO，算是比较高的了，每秒的读IO 3GB+，读IO也是十分高的,写IO总量并不大，23M而已。每秒的执行数量也不大，671。看来这个系统主要是做一些大的读写操作，有点像一个分析系统。从上面的IO延时上来看，底层存储应该是闪存。

从上面我们已经获得了足够的信息，那么我们能够定位系统的问题了吗？答案依然是否定的，从这些信息，我们还是无法定位系统的根因，更何况，我们甚至不知道系统有没有问题。

可能有些朋友要说了，刚才那个row cache objects的闩锁还不够明显吗？是的，从等待事件占比上看，确实这个等待占了35%，不过老司机不仅仅是看占比，更要看平均延时，6毫秒的平均延时还不足以让我认为这个等待就是有问题的。总的等待时间是77.2K,放在7200秒中，平均每秒也不过十多个等待。再加上平均延时十分低，一个偶发性的高负载等待，也可能会产生类似的效果。比如说产生了一次SGA RESIZE。不过从AWR报告中我们并没有看到SGA RESIZE的存在。

从内存对象的动态分析上，我们还是可以看出一些蛛丝马迹：

从这些数据上，我们有理由相信SGA出现过比较严重的抖动，SHARED POOL最小的时候倍压缩到只有10GB，而最大的时候有30GB。在共享池被缩小的时候，出现大量的row cache objects等待就十分正常了。

实际上到目前为止我们还只是猜测而已，因为没有任何可以确定我们的猜测的直接证据。这是因为AWR报告这种宏观的分析工具，给我们的只能是一个较为宏观的展示，而对于有些比较明显的问题，比如说用户已经感觉多明显卡顿的问题，AWR报告在大多数情况下还是能够发挥出一定的作用。而针对亚健康状态，AWR报告这个分析工具就不是很够用了。或者说宏观分析可能会因为一些宏观因素过于大而掩盖一些其他的问题，从而让我们的故障定位出现偏差。其实这时候我们需要通过微观分析来进一步的排除主要的干扰因素。对于Oracle数据库来说ash是一种十分号的做微观分析的工具。不过ash仅仅包含了对v$session的部分采样，依然不是十分充分的，在D-SMART中，我们为了能够实现更为精细的微观分析，针对Oracle数据库采样了近700个指标数据，其丰富程度远远超过ash。D-SMART的数据配合ash的数据，可以构成一个十分全面的分析数据体系，从而完成故障根因分析的基础。

实际上，这套系统是一套十分典型的批处理系统。从执行的SQL的种类上也可以看出其主要特点：

大量的操作都是人工操作的一些SQL语句核一些后台自动调度的作业。所以执行的并发量不大，但是每条SQL的开销都很大。这种系统的业务特点也决定了共享池争用不会成为特别严重的问题，而SQL本身的问题才是真正的问题。因为业务需求的多变，SQL优化也不是很容易做的事情。

微观分析与宏观分析是相辅相成的，宏观分析可以为微观分析裁剪诊断路径，调整诊断方向。微观分析可以佐证宏观分析的结论，也可以发现宏观分析中忽视的诊断路径，从而避免宏观分析走错方向。

在本案例中，虽然缺乏微观的数据，不过作为一个干了二十多年系统优化的人来说，我还是可以为这套系统提供一些优化的思路。比如说，对这种系统，我们的SGA_TARGET设置可以更高一些，让DB CACHE可以分配更多的空间，从而减少物理IO。同时SHARED_POOL_SIZE可以设置为30GB，从而不会出现SGA RESIZE把共享池急剧压缩的事情发生，从而避免短暂的卡顿。这是宏观分析对于微观分析的指导作用。

做出这种判断是基于经验的，单纯从数据上通过算法来实现还是存在很大的问题的。这也是智能化运维系统中根因定位比较难的原因。缺乏用于作证的数据，“智能机器人”这种呆头呆脑的东西怎么能形成如此复杂的判断呢？所以说，最终，大多数的智能化分析还是输在了数据上。构建完善的数据体系，完整的覆盖宏观分析与微观分析，其后才能谈得上“智能化故障溯源”吧。