AWR——Instance Efficiency Percentages (Target 100%)

目前都是AMM并ASMM内存管理，所以基于命中率的调优方法论已经过时(因为这是个平均值的概念，就像1和100的平均是50.5一样不代表完全准确)，但仍具有参考价值，全部是越高越好！

Buffer Nowait %：session申请一个buffer(兼容模式)在db buffer cache中不等待的次数比例。

 

Buffer Hit %：数据块在数据缓冲区中的命中率，小于90%可能是要加db_cache_size，但这个指标即便99% 也不能说明物理读等待少了，但是指标小于90%，那肯定是存在大量物理读

 

Library Hit %：申请一个library cache object例如一个SQL cursor时，其已经在library cache中的比例（表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率），低的library hit ratio会导致过多的解析，增加CPU消耗。比例过小则需要增加shared pool大小

 

Execute to Parse %：表示sql语句解析后被重复执行的命中率，如果该值偏小，说明分析（硬分析和软分析）的比例较大，快速分析较少，其公式为 1-(parse/execute)

 

Parse CPU to Parse Elapsd %：解析CPU时间和总的解析时间的比值(Parse CPU Time/ Parse Elapsed Time)【解析实际运行时间/(解析实际运行时间+解析中等待资源时间)】；若该指标水平很低，那么说明在整个解析过程中 实际在CPU上运算的时间是很短的，而主要的解析时间都耗费在各种其他非空闲的等待事件上了（有时候Parse CPU to Parse Elapsd%会超过100%，这是由于四舍五入造成的，CPU Time是一点一点纪录，并累加的（按SQL Parse 中的每个Call）而Elapsed Time 是一段一段纪录，并累加的（按SQL 一次parse）比如说，现在开始一个 parse , 中间有100次call, 本来每次应该是 0.8 微秒，但是，Oracle 纪录时每次计成是 1 微秒，结果，这一次的parse CPU 被记录成 100 微秒。而Elapsed Time 纪录的是整个的时间，等于 0.8 *100 + （wait time）,结果就可能小于 100 微秒。而最终结果就是 Parse CPU to Parse Elapsd% > 100%）

 

Redo NoWait %：session获取buffer 在redo buffer cache中不用等待的比例，redo相关的资源如redo space request争用可能造成生成redo时需求等待。

 

In-memory Sort %：排序在内存PGA中的比例。（不是workarea中所有的操作类型只是排序，所以现在越来越鸡肋了），比例过小则需要增加PGA_AGGREGATE_TARGET值

 

Soft Parse %：软解析的百分比，softs/(softs+hards), 太低则需要调整应用使用绑定变量

 

Latch Hit %：闩申请不要等待的比例

 

% Non-Parse CPU：非解析cpu比例，公式为 (DB CPU – Parse CPU)/DB CPU， 若大多数CPU都用在解析上了，则可能好钢没用在刃上了。

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

转载于:http://blog.itpub.net/30126024/viewspace-2083439/