dba需要自我反省

       这篇文章之所以被我收藏下来，最主要的原因是这个自我反省的过程。一个人之所以能向更高层次的发展，自我反省和自我的总结是最重要的。在这点上的确要好好学习并自己批判一下。

原文如下：

     在前几天的2012 ORACLE技术嘉年华上，Poder大师介绍了也一个复杂情况问题分析的案例。整个过程丝丝入扣，让人惊叹他的分析思路和驾驭工具脚本的能力。昨天有人给我发来了这个案例的PPT。

    在惊叹之余，我也在思考，如果我来处理这个案例，会有什么样的结果呢？我没有Poder的脚本能力，同时对HP-UX的工具也只是略懂一二，一些复杂的分析工具从来没有使用过。在这种情况下，我能够完成这个案例吗？多年复盘案例的习惯让我养成了看案例的习惯，在我看的过程中，我会不断的问自己，这个步骤，如果我来做，我会怎么做？然后我才会往下看，看看和作者的思路是否吻合。这个习惯使我在学习其他人的经验的时候，不简单的是接受知识，而且在思考，这样就可以体会一把亲身经历案例的过程。

 

好了，闲话少说，我们马上进入案例。首先介绍一下环境：

l  一个大并发的OLTP环境

l  Oracle 11.1.0.7 单节点

l  HP-UX 安腾，32C 128g

l  数千终端用户

l  多个WEBLOGIC APP SERVER通过连接池连接到数据库服务器

问题：

        l  数据库服务器和数据库都会出现偶发性的突然变慢（数据库和服务器二者）

       l  变慢的现象持续1-20分钟

       l  故障发生时，查询特别慢甚至无响应

       l  在那个时间段甚至无法登录到操作系统，故障结束后SSH连接恢复正常。在故障发生时执行一条操作系统命令都要好几分钟才有响应

     这种现象大家似曾相识吧，可能很多DBA都遇到过类似的案例。从这种现象上来看，这是一个全局性的问题，包括OS，数据库，应用都有可能导致问题。因此这种情况下，我们需要通过一些全局性的诊断来发现问题。在这一点上，我们大家可能和Poder有着共同的思路：

So, the scope of this problemis global, server-wide. Therefore we can use global, server-wide metrics to diagnose the problem.

由于故障发生在18：10，因此Poder做了18：00-18：20的AWR报告。当接到故障报告的时候，我们可以要客户做一个AWR的采样，这是十分有效的。因为AWR缺省是1小时的采样间隔，因此我们做一个SNAP，一般都能够获得一个小于1小时采样粒度的报告。从这份报告中我们看到

 

 

这个系统的负载并不高，DB TIME是559，从等待事件上看，LOG FILE SYNC慢一点，存在一些热块冲突，其他的还都比较正常。从系统负载数据上看，16.3%的USER,17.6%的SYS，66.1%的IDLE。对这个数据，Poder并未提出任何疑问，老白想这可能是Poder故意买了一个关子，17.5%的SYS 比例，对于任一个DBA来说都是需要打个问号的。而在这里，Poder关注了一个大家可能会遗漏的细节，就是在18：00-18：20这段时间中，会话数增加了500，也就是每分钟会话数增加25个会话。这只是增加的，还不包括断掉的。为什么会话会增加，这个问题也需要我们在心里打个问号的。

20分钟的粒度还是太大了，因此在处理这样问题的时候，老白会从18：00开始到18：20，每5分钟做一个ASH报告，进行进一步的分析。当然，如果你有OEM，那么就简单的多，可以直接在EM上拉动时间窗口，来进行分析。在这个案例中，PODER也做了ASH分析，不过他