Statspack报告分析—第三部分：Instance Efficiency Percentages实例效率统计

-----

在这第三部分，主要是一些效率、命中率的统计：

这里主要列出了数据的命中率、library cache的命中率、排序、hard/soft parse等命中率。

可以和上期的Statspack这一部分比较，看一下命中率有什么变化，如果在某一项发生了明显的变化，可以在Statspack中对应的章节进行以下分析。

Statspack报告分析—第三部分：Instance Efficiency Percentages实例效率统计

-----

在这第三部分，主要是一些效率、命中率的统计：

这里主要列出了数据的命中率、library cache的命中率、排序、hard/soft parse等命中率。

可以和上期的Statspack这一部分比较，看一下命中率有什么变化，如果在某一项发生了明显的变化，可以在Statspack中对应的章节进行以下分析。

在进行这里的数据分析时，需要清楚目前的应用程序是哪种应用程序。 如果是一个DSS的环境中，很低的内存排序可能不是关键。但是对于一个OLTP系统，这就是一个很有价值的数据。

对上面这些数据进行一下说明：

Buffer Nowait Ratio：

说明了当server进程要求特定的buffer，立刻获得的百分比。所有的buffer类型都在统计范围内。如果这个数值比较低，再看一下Buffer Wait Statistics章节，哪个类型的buffer的获取率比较低。

Buffer Hit Ratio：

这个又可以称为 buffer cache hit ratio。当要求一个block的时候，直接在内存中而不必通过物理IO进行读取。虽然这个统计值是最重要的统计值之一，但是有时候会引起误解。很高的命中率（99.9%）说明cache设置了一个合适的值，但是这不适合与所有的情况。

如：经常重复的SQL查询，只使用到一小部分内存如index搜索，会歪曲整个的buffer数据统计。当这些blocks被读取后，会放在MRU（most recently used ）的尾部，重复的获取这些blocks会增大命中率，这使得buffer cache的调优成了一个有挑战性的工作。

在一些站点，出现‘write complete waits’事件可以说明buffer cache设置小了点，它说明了热快（hot block）在需要的时候又被调整出了cache。看一下wait event章节。

而有时，低的buffer hit ratio并不意味着cache设置太小了，可能是潜在的全表扫描降低了buffer hit的命中率。

Library Hit Ratio：

这个又可以称为：library cache hit ratio. The ratio indicates the number of pin requests which result in pin hits. A pin hits发生在当要执行SQL或者PL/SQL的时候，他已经在library cache中，并且可以被执行。

低的library hit ratio percent 说明SQL语句过早的被交换处shared pool，可能是shared pool设置了太小了。或者是非共享的SQL语句在执行。比较一下soft parse ratio，如果2者都是很低的，说明了是SQL parse的问题。

Redo no-wait Ratio：

这个值说明了当要求redo空间的时候，已经在redo log中准备好了。计算公式如下：

100 x (1- (redo log space requests/redo entries))

当Oracle写redo log的时候，而online redo log的没有足够的空间，‘redo log space request’统计数据在上升。‘redo entries’统计值在每次获取redo log的时候都在增加。

通常，慢的log switch会引起redo log space的等待。如果经常的切换log（如不到15分钟就要切换一次），应该增加onlie redo logs的文件尺寸。

如果log切换不是很频繁，检查一下redo log所在的磁盘，是否由于磁盘的I/O速度慢造成的切换时间增长了。如果磁盘I/O超载了，考虑或者将online redo log移到比较空闲的磁盘上，或者放到专用的磁盘、或者更换更快的磁盘。

In-memory Sort Ratio：

这个值说明了在内存中排序的百分比，对应的是通过磁盘进行排序。通常，在OLTP系统中，这个值应该是很高的，在Oracle8i Design 和性能调优手册上有对排序进行调优的资料。

Soft parse ratio：

A soft parse occurs when a session attempts to execute a SQL statement, the statement is already in the shared pool, and can be used. For a statement to be used (i.e. shared) all data, (including data such as the optimizer execution plan) pertaining to the existing SQL statement must be equally applicable to the current statement being issued.

A hard parse occurs when a SQL statement is executed, and the SQL statement is either not in the shared pool, or it is in the shared pool but can not be shared as part of the metadata for the two SQL statements is different (for example, this may happen if a SQL statement is textually identical as a preexisting SQL statement, but the tables referred to in the two statements resolve to physically different tables).

In an OLTP environment, hard parses are expensive CPU wise, which adds elapsed time to the user executing the statement. The aim is to parse once, execute many times. Ideally the soft parse ratio would be greater than 95%; when the soft parse ratio falls significantly lower than 80%, it may be cause to investigate whether it is possible to share SQL by using bind variables, or if the code can not be changed, to force cursor sharing by using the new Oracle8i release 8.1.6 init.ora parameter cursor_sharing.

As a sanity check, compare this ratio to the hard and soft parse rates (per second) in the Load Profile. If the rates are low (e.g. 1 per second), parsing may not be a significant issue.

Another useful comparison is against the proportion of parse time that was not CPU-related:

(parse time CPU) / (parse time elapsed)

A low value for this ratio could mean that the non-CPU-related parse time was spent waiting for latches, which might indicate a parsing or latching problem. To investigate further, look at the shared-pool and library-cache latches in the Latch sections for indications of contention on these latches.

Latch Hit Ratio ：

This percentage is based on the ratio of the total number of latch misses to the number of latch gets for all latches. The ratio is indicative of a latching problem if the ratio is low, however as the data is rolled up over all latches, a high ratio can artificially mask a low get rate on a specific latch. Cross check this value with the top-5 wait events to see if ‘latch free’ is in the list, and if so, refer to the Latch sections.