AWR报告分析（一）

http://blog.csdn.net/mensuo1111/article/details/8905325

AWR:AutomaticWorkload Repository,自动负载信息库，是oracle 10g 版本推出的新特性。AWR通过对比两次快照收集到的统计信息来生成报表数据。

db time= cpu time + wait time（不包含空闲等待）（非后台进程）

DB Time：服务器花在数据库运算(非后台进程)和等待(非空闲等待)上的时间，小于Elapsed表示数据库比较空闲。

Elapsed：表示过去了多长时间，这里指两个快照之间的时间。

数据表示在168分钟内生成了四次快照（27-30），数据库耗时不到一分钟。

Buffer Cache:SGA的组成部分之一，用于保存从数据文件中读取的数据块的副本信息。

Std Block Size: oracle 标准块大小；

Share pool size：SGA中最关键的内存片段，主要由库缓存(共享SQL区和PL/SQL区)和数据字典缓存组成；

LogBuffer：日志缓冲区。

Logons大于每秒1~2个、Hard parses大于每秒100、全部parses超过每秒300表明可能有争用问题。

Redo size每秒产生的日志大小(单位字节)可标志数据变更频率,数据库任务的繁重与否。Logicalreads每秒/每事务逻辑读的块数.平决每秒产生的逻辑读的block数。

Logical Reads= Consistent Gets + DB Block Gets 

Block changes每秒/每事务修改的块数

Physical reads每秒/每事务物理读的块数

Physical writes每秒/每事务物理写的块数

User calls每秒/每事务用户call次数

 

ParsesSQL解析的次数.每秒解析次数包括fastparsesoft parse和hard parse三种数量的综合。软解析每秒超过300次意味着你的"应用程序"效率不高调整session_cursor_cache。在这里fastparse指的是直接在PGA中命中的情况设置了session_cached_cursors=nsoftparse是指在shared pool中命中的情形hard parse则是指都不命中的情况；

 

Hard parses其中硬解析的次数硬解析太多说明SQL重用率不高。每秒产生的硬解析次数,每秒超过100次就可能说明你绑定使用的不好也可能是共享池设置不合理。这时候可以启用参数cursor_sharing=similar|force该参数默认值为exact。但该参数设置为similar时存在bug可能导致执行计划的不优。

 

Sorts每秒/每事务的排序次数

Logons每秒/每事务登录的次数

Executes每秒/每事务SQL执行次数

Transactions每秒事务数.每秒产生的事务数反映数据库任务繁重与否

 

Blocks changed per Read表示逻辑读用于修改数据块的比例.在每一次逻辑读中更改的块的百分比。

Recursive Call递归调用占所有操作的比率.递归调用的百分比如果有很多PL/SQL那么这个值就会比较高；

Rollbackper transaction每事务的回滚率.看回滚率是不是很高因为回滚很耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来UndoBlock的竞争该参数计算公式如下:Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% ；Rows per Sort每次排序的行数

 

Buffer Nowait：表示在内存获得数据的未等待比例。在缓冲区中获取Buffer的未等待比率。BufferNowait的这个值一般需要大于99%。否则可能存在争用可以在后面的等待事件中进一步确认。

 

buffer hit：表示进程从内存中找到数据块的比率监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP系统如果此值低于80%应该给数据库分配更多的内存。

 

Redo NoWait：表示在LOG缓冲区获得BUFFER的未等待比例。如果太低可参考90%阀值考虑增加LOG BUFFER。

 

library hit：表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率当应用程序调用SQL或存储过程时Oracle检查LibraryCache确定是否存在解析过的版本如果存在Oracle立即执行语句如果不存在Oracle解析此语句并在LibraryCache中为它分配共享SQL区。低的library hit ratio会导致过多的解析增加CPU消耗降低性能；如果libraryhit ratio低于90%可能需要调大shared pool区。STATEMENT在共享区的命中率通常应该保持在95%以上否则需要要考虑加大共享池使用绑定变量修改cursor_sharing等参数。

 

Latch Hit：Latch是一种保护内存结构的锁可以认为是SERVER进程获取访问内存数据结构的许可。要确保Latch Hit>99%否则意味着Shared Pool latch争用可能由于未共享的SQL或者LibraryCache太小可使用绑定变更或调大Shared Pool解决。要确保>99%否则存在严重的性能问题。当该值出现问题的时候我们可以借助后面的等待时间和latch分析来查找解决问题。

 

Parse CPU to Parse Elapsd：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)越高越好。计算公式为ParseCPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%意味着CPU等待时间为0没有任何等待；

 

Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)太低表示解析消耗时间过多。计算公式为% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小表示解析消耗的CPU时间过多。

 

Execute to Parse：是语句执行与分析的比例如果要SQL重用率高则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。计算公式为Execute to Parse =100 * (1 - Parses/Executions)。

 

In-memory Sort：在内存中排序的比率如果过低说明有大量的排序在临时表空间中进行。考虑调大PGA(10g)。如果低于95%可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决；

 

SoftParse：软解析的百分比（softs/softs+hards）近似当作sql在共享区的命中率太低则需要调整应用使用绑定变量。sql在共享区的命中率小于<95%,需要考虑绑定如果低于80%那么就可以认为sql基本没有被重用。

Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明SharedPool有浪费，而如果高于90，说明共享池中有争用，内存不足；

 

SQL with executions>1：执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析；

 

Memory for SQL w/exec>1执行次数大于1的SQL消耗内存的占比。

 

显示了系统中最严重的5个等待按所占等待时间的比例倒序列示。