如何高效的分析AWR报告

AWR报告分析

1.1 看CPU的负载情况

 

 

 

DBTime:表示CPU花费在处理Oralce非空闲等待和运算上的时间  

DB TIME= DB CPU + Non-Idle Wait +  Wait on CPU queue

Elapsed：表示本AWR报告由多久的快照间隔生成的

负载情况：DBTime / Elapsed * CPUs   这个比值越小 说明DB负载压力越小

 1.2看事务的繁忙程度、软硬解析

 Load Profile 主要用来显示当前系统的一些指示性能的总体参数，部分介绍如下

 

列Per Second：平均每秒

列Per Transaction：平均每个事务

 如图，平均每秒的事务数Transactions是75，非常小，说明系统压力非常小，一般来说Transactions不超过200都是正常的，或者200左右都是正常的，超过1000就是非常繁忙了，

再看看平均每秒的日志尺寸是4位数的，平均每个事务的日志尺寸是5位数的，说明了系统访问不是很频繁，而单个业务是比较复杂的，

如果反过来，平均每秒日志尺寸比平均每秒事务日志尺寸大很多，说明系统访问很频繁，而业务比较简单，不需要响应很久

• Redo Size ：用来显示平均每秒的日志大小和平均每个事务的日志大小，有时候可以结合 Transactions 每秒事务数，分析当前事务的繁忙程度。
• Parses：解析次数，包括软解析 + 硬解析，软解析优化得不好几乎等于每秒SQL执行次数， 即执行解析比1:1。理想状态是解析一次到处运行。
• Hard Parses：硬解析次数，最好小于每秒20次，否则就要考虑优化相关SQL。
• Transactions: 事务数量

1.3 看命中率指标

 efficiency percentages是一些命中率指标。Buffer Hint、Library Hint等表示SGA(System global area)的命中率；

Buffer Nowait : Buffer Nowait的这个值一般需要大于99%** 否则可能存在争用，可以在后面等待事件中进一步确认。

表示在内存获得数据的未等待比例。在缓冲区中获取Buffer的未等待比率。

Buffer Hit :如果此值低于80%，应该给数据库分配更多的内存

表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP系统，数据块在数据缓冲区中的命中率，通常应在95%以上。

Redo NoWait ：表示在Log 缓冲区获得Buffer的未等待比例。如果太低可考虑增加Log Buffer。当redo buffer达到1M时就需要写到redo log文件，所以一般当redo buffer设置超过1M，不太可能存在等待buffer空间分配的情况。当前，一般设置为2M的redo buffer，对于内存总量来说，应该不是一个太大的值。

In-memory Sort：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA(10g)。如果低于95%，可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决，注意这两个参数设置作用的范围时不同的，SORT_AREA_SIZE是针对每个session设置的，PGA_AGGREGATE_TARGET则时针对所有的sesion的。

Library Hit ：如果Library Hit Ratio低于90%，可能需要调大Shared pool区。

表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，Oracle检查Library Cache确定是否存在解析过的版本，如果存在Oracle立即执行语句；如果不存在Oracle解析此语句，并在Library Cache中为它分配共享SQL区。低的Library Hit Ratio会导致过多的解析，增加CPU消耗，降低性能。

Soft Parse：小于<95%,需要考虑绑定，如果低于80%，那么就可以认为sql基本没有被重用。

软解析的百分比(Softs/Softs+Hards)，近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。sql在共享区的命中率，

Latch Hit：要确保>99%，否则存在严重的性能问题。当该值出现问题的时候，我们可以借助后面的等待时间和latch分析来查找解决问题。

Latch是一种保护内存结构的锁，可以认为是Server进程获取访问内存数据结构的许可。要确保Latch Hit>99%，否则意味着Shared Pool latch争用，可能由于未共享的SQL，或者Library Cache太小，可使用绑定变更或调大Shared Pool解决。

Parse CPU to Parse Elapsd：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。如果该比率为100%，意味着CPU等待时间为0，没有任何等待。

Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。如果这个值比较小，表示解析消耗的CPU时间过多。

Execute to Parse：是语句执行与分析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。

1.4 看等待事件

 

 Top 10 Foreground Events by Total Wait Time，等待事件是衡量数据库优化情况的重要指标，通过观察Event和%DB time两列就可以直观看出当前数据库的主要等待事件

 

1.5 看TOP SQL统计

SQL Statistics 从 11 个维度对SQL进行排序并给出了Top SQL的详细内容，可以点击查看具体的SQL内容，进一步分析调优方案。

• SQL ordered by Elapsed Time。记录了执行总和时间的 TOP SQL(请注意是监控范围内该SQL的执行时间总和，而不是单次SQL执行时间 Elapsed Time = CPU Time + Wait Time)。
• SQL ordered by CPU Time。记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间)。
• SQL ordered by Gets。记录了执行占总 buffer gets (逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets)。
• SQL ordered by Reads。记录了执行占总磁盘物理读(物理IO)的TOP SQL。
• SQL ordered by Executions。记录了按照SQL的执行次数排序的TOP SQL。该排序可以看出监控范围内的SQL执行次数。
• SQL ordered by Parse Calls。记录了SQL的软解析次数的TOP SQL。
• SQL ordered by Sharable Memory。记录了SQL占用library cache的大小的TOP SQL。Sharable Mem (b)：占用library cache的大小，单位是byte。
• SQL ordered by Version Count。记录了SQL的打开子游标的TOP SQL。
• SQL ordered by Cluster Wait Time。记录了集群的等待时间的TOP SQL。

参考AWR深度好文章:  http://www.askmac.cn/archives/performance-tuning-oracle-awr.html

 https://www.cnblogs.com/cocowool/p/quick_view_of_oracle_awr_report.html

https://www.cnblogs.com/mzq123/p/10741208.html