oracle Statspack 报告解析之 Instance Efficiency Percentages (实例命中率)

该部分可以提前找出ORACLE潜在将要发生的性能问题，很重要。

Instance Efficiency Percentages
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:   99.98       Redo NoWait %:  100.00
            Buffer  Hit   %:   99.52    In-memory Sort %:  100.00
            Library Hit   %:   89.31        Soft Parse %:   93.26
            Execute to Parse %:   39.73         Latch Hit %:   99.70
            Parse CPU to Parse Elapsd %:  103.17     % Non-Parse CPU:   71.37

参数说明：
            Buffer Nowait %：在缓冲区中获取Buffer的未等待比率，Buffer Nowait<99%说明，有可能是有热块(查找x$bh的 tch和v$latch_children的cache buffers chains)。
            Redo NoWait %：在Redo缓冲区获取Buffer的未等待比率。
            Buffer Hit %：数据块在数据缓冲区中的命中率，通常应在950%以上， 如果小于95%，需要调整重要的参数，小于95%可能是要加db_cache_size，但是大量的非选择的索引也会造成该值很高（大量的db file sequential read）。如果一个经常访问的列上的索引被删除或者是统计信息太陈旧，可能会导致错误的执行计划，造成buffer hit 显著下降。如果增加了索引，但是它影响了ORACLE正确的选择表连接时的驱动顺序，那么可能会导致buffer hit 显著增高。如果命中率变化幅度很大，说明需要改变SQL模式。
            In-memory Sort %：在内存中的排序率。
            Library Hit %：主要代表sql在共享区的命中率，通常在95%以上，否则需要要考虑加大共享池，绑定变量，修改cursor_sharing等参数。
            Soft Parse %：近似看作sql在共享区的命中率，小于<95%,需要考虑到绑定，如果低于80%，那么就可能sql基本没有被重用。
            Execute to Parse %：一个语句执行和分析了多少次的度量。在一个分析，然后执行语句，且再也不在同一个会话中执行它的系统中，这个比值为0。
            计算公式为：Execute to Parse =100 * (1 - Parses/Executions)。所以如果系统Parses > Executions，就可能出现该比率小于0的情况。该值<0通常说明shared pool设置或效率存在问题，造成反复解析，reparse可能较严重,或者可是同snapshot有关，如果该值为负值或者极低，通常说明数据库性能存在问题。
            Latch Hit %：要确保>99%，否则存在严重的性能问题，比如绑定等会影响该参数。
            Parse CPU to Parse Elapsd %：计算公式为：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，如果非常低，用于解析花费的每个CPU秒花费了大量的wall clock时间，这说明花了很多时间等待一个资源。如果该比率为100%，意味着CPU时间等于经过的时间，没有任何等待。
            % Non-Parse CPU：计算公式为：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。太低表示解析消耗时间过多。与PARSE_CPU相比，如果TOT_CPU很高，这个比值将接近100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。

参考地址:http://blog.csdn.net/tianlesoftware/article/details/4682329