awr报告解读一

这几天收到Richard niemiec的书，挺厚的。慢慢啃起来，看完awr报告调优后，才发现我以前的一些巡检指标不太准确，可能是太过于相信百度他人的信息了，确实网络确实很好，可以一下子就可以找的自己想要的内容，但是鱼目混珠，有大神的多年见解，也有瞎指挥。
没错，正如我们黄sir说的那样，能够利用awr找出问题，也是dba最基本的巡检能力，没有什么捷径走，就是多看多分析，以前呢利用了一个自以为是个准确的标准来巡检，现在才发现其实这不能完全表明oracle内部运行机制就这么按照这个标准说的那样。－－－》多做笔记，多分析。

1）报头信息（略）
2）load profile
负载摘要，这是监控系统的吞吐量和负载变化的极佳入口，当系统的负载增加时，每秒的数字将会变大。当系统调优到最佳效率时，每个事务的统计数据将下降。

负载摘要可以帮助识别正在运行的活动的负载和类型。
主要看以下几个要点：

• 相比正常负载，观察这段时间里逻辑读和物理读的变化状况。
• 每秒redo size ，block change的比例是否有增大。这意味着dml活动正增大
• 当执行一条不在共享池的sql语句时，就会出现硬解析。硬解析率超过100次／秒，就意味着绑定变量的使用效率不高，应当使用cursor_sharing初始化参数也可能是共享池的大小设置存在问题
• 当执行一条存在于共享池的sql语句时，就会有软解析，软解析超过300次／秒就意味着程序的效率不高，语句被反复的解析，正常情况每个会话一条语句只应该解析一次

3）实例效率
实例效率呢展示了许多命中率的信息。这个得结合以往的信息比较，才能知道系统是否有显著的变化。

主要可关注这些：

• buffer nowait％低于99%，这是针对特定缓存请求的命中率，这个指标考察缓存在内存中的执行比例。如果命中率下降，在buffer wait部分将会发现当前存在（热）数据块的争用现象。
• buffer hit％低于95%，这是针对特定缓存请求的命中率，这个指标考查缓存位于内存中且无需物理i/o操作的比例。 

       －>如果命中率稳定在95%，但是突然上升到99%，说明得查看执行糟糕的sql语句，或导致大量逻辑度操作的索引（检查load profile和top buffer gets sql）
      －>如果命中率稳定在95%，但突然下降到45%，这时应该查找导致大量物理读操作的sql（top physical read sql），这些物理读操作没有使用索引或者索引被删除

• library hit 低于95%，较低的命中率意味着sql语句呗过早挤出共享池（也可能是共享池有点小），较低的命中率还以为着没有使用绑定变量或者一些其他的问题造成sql没用被重用。－－－>注意ibrary lath 问题。
• soft parse ％低于95%，软解析低于80%意味着sql没有被重用，需要进一步分析。
• latch hit ％低于99%一般都会有锁的问题

   这个的需要定期观察，才能得出比较准确的反馈信息。不然对于一些影响变化是不易发现的。同样的，要记住在报告中，很高的命中率可能依然存在性能问题。有种情况就是，数据运行效率很好，但是性能却很糟糕

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30430420/viewspace-1798680/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30430420/viewspace-1798680/