工程师手记

《怎么看awr报告-1》

一、前面

这段时间系统整体性能下降了，大家都很着急。 一般性能下降的问题80%是数据库引起的。其他同事发来了awr报告，结果发现每次情况还不一样，问题可谓层出不穷，就跟p2p爆仓似的连环爆发。

看到awr后要么一目了然，要么一脸漠然。有些问题比较简单，建个索引，重新build表就好了；有的问题比较复杂，首先需要把系统整体情况搞清楚/同时建立基线，然后进入每日观察序列，有待进一步鉴别；有一些则是待爆发的，需要提前解决掉！

由于权限原因一旦碰oracle性能问题，偶一般通过基本的动态性能视图来查（实时/信息全）。实在没办法了才会向其他部门要awr报告，awr报告是个好东西（直白/系统）。

二、怎么看awr报告

作为应用型DBA，对自己的系统应当有一定的了解，所以那些cpu，内存，参数等就略过了。 如果遇到系统性能突然下降的情况，就依次先从awr报告里检查如下这些：SQL Statistics、Segment Statistics、Report Summary、Wait Events Statistics、Wait Statistics、Latch Statistics。

1SQL Statistics

同样根据二八定律，数据库变慢的问题80%是由SQL引起的，这背后可能是执行计划变差了，SQL写法有问题，索引/表建立不合理等原因，但最终他们都要通过SQL表现出来。

他这里分别按：耗时，耗cpu，耗io，耗逻辑读，耗物理等各排行榜列示出SQL来！

1.1 要是发现一些执行次数、执行耗时离谱的SQL，问题就会非常明显；

1.2 或是发现一些不常见的SQL突然冒出来了，问题也很明显；

1.3 如果是整体性出现一些变慢（一般也是其他会话或进程引起的，而且不在排行榜里），那就需要通过其他指标来辅助了——Report Summary，要是到了这一步，就需要慢慢比较具体指标来分析了！

2Segment Statistics

oracle存储组织上分为：段、区、块。我们可以通过dba_segments视图来查看我们的表、索引的大小。做到心中有数便于判断！

他这里分别按：逻辑读写、物理读写、Buffer Busy waits、ITL waits等各排行榜列示出segment来！ 这个就要比刚才的SQL指标更底层一些，

2.1 通过这可以发现表、索引的建立是否合理；

2.2 当然也不排除一些程序bug引起的。

3 Report Summary

如果不能从1和 2快读定位问题的话， 就回到这里系统地全面地了解系统的运行状况吧！

3.1 Load Profile 这里介绍系统的整体负载，按每秒/每个事务处理的逻辑读写（按块）、物理读写（按M）、SQL的解析和执行 以及每秒处理的事务数 等列出来——如果心中没有基线，这里容易看不懂！

3.2Instance Efficiency Percentages 这里介绍了数据缓冲区，库高速缓冲区，SQL解析，排序等情况，这里的指标越接近100%越好——这里一般看不出来啥问题，但是他真的太重要了，多唠叨一下！

3.3 Host CPU 类似vmstat命令展示的，有一次我们系统在测试环境上做批量测试，结果发现cpu空闲为2%，原来程序里死循环导致——对于线上的经过测试的系统，一般CPU不会突然发疯，根据二八原则很多问题是IO引起的！

3.4Top 10 Foreground Events by Total Wait Time 搂一眼有无引起性能问题的时间如：全表扫描、缓冲区忙等待——数据库优化的最终目的也是尽量消灭等待！

4Wait Events Statistics、Wait Statistics、Latch Statistics

进入深水区，待补充！

三、后面

粗略地点了下查看awr的一般步骤——先从SQL Statistics、Segment Statistics、Report Summary看起（仅限于应用型DBA）