工程师手记

《怎么看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)

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180925G02A0P00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券