Statspack報告分析—第三部分：Instance Efficiency Percentages例項效率統計

Statspack報告分析—第三部分：Instance Efficiency Percentages例項效率統計

-----

在這第三部分，主要是一些效率、命中率的統計：

這裡主要列出了資料的命中率、library cache的命中率、排序、hard/soft parse等命中率。

可以和上期的Statspack這一部分比較，看一下命中率有什麼變化，如果在某一項發生了明顯的變化，可以在Statspack中對應的章節進行以下分析。

[@more@]

Statspack報告分析—第三部分：Instance Efficiency Percentages例項效率統計

-----

在這第三部分，主要是一些效率、命中率的統計：

Instance Efficiency Percentages (Target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buffer Nowait Ratio: 100.00 Buffer Hit Ratio: 99.49 Library Hit Ratio: 99.30 Redo NoWait Ratio: 100.00 In-memory Sort Ratio: 99.99 Soft Parse Ratio: 89.37 Latch Hit Ratio: 99.98

這裡主要列出了資料的命中率、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.

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/27500440/viewspace-1981441/，如需轉載，請註明出處，否則將追究法律責任。