Oracle效能調優 AWR分析一例
阿新 • • 發佈：2019-01-08
本節包含了Oracle關鍵指標的記憶體命中率及其它資料庫例項操作的效率。其中Buffer Hit Ratio 也稱Cache Hit Ratio，Library Hit ratio也稱Library Cache Hit ratio。同Load Profile一節相同，這一節也沒有所謂“正確”的值，而只能根據應用的特點判斷是否合適。在一個使用直接讀執行大型並行查詢的DSS環境，20%的Buffer
Hit Ratio是可以接受的，而這個值對於一個OLTP系統是完全不能接受的。根據Oracle的經驗，對於OLTP系統，Buffer Hit Ratio理想應該在90%以上。
Buffer Nowait
buffer hit表示程序從記憶體中找到資料塊的比率，監視這個值是否發生重大變化比這個值本身更重要。對於一般的OLTP系統，如果此值低於80%，應該給資料庫分配更多的記憶體。資料塊在資料緩衝區中的命中率，通常應在95%以上。否則，小於95%，需要調整重要的引數，小於90%可能是要加db_cache_size。一個高的命中率，不一定代表這個系統的效能是最優的，比如大量的非選擇性的索引被頻繁訪問，就會造成命中率很高的假相（大量的db file sequential read），但是一個比較低的命中率，一般就會對這個系統的效能產生影響，需要調整。命中率的突變，往往是一個不好的資訊。如果命中率突然增大，可以檢查top buffer get SQL，檢視導致大量邏輯讀的語句和索引，如果命中率突然減小，可以檢查top physical reads SQL，檢查產生大量物理讀的語句，主要是那些沒有使用索引或者索引被刪除的。
Redo NoWait
library hit表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率，當應用程式呼叫SQL或儲存過程時，Oracle檢查Library Cache確定是否存在解析過的版本，如果存在，Oracle立即執行語句；如果不存在，Oracle解析此語句，並在Library Cache中為它分配共享SQL區。低的library hit ratio會導致過多的解析，增加CPU消耗，降低效能。如果library hit ratio低於90%，可能需要調大shared pool區。STATEMENT在共享區的命中率，通常應該保持在95%以上，否則需要要考慮：加大共享池；使用繫結變數；修改cursor_sharing等引數。
Latch Hit
Parse CPU to Parse Elapsd：解析實際執行時間/(解析實際執行時間+解析中等待資源時間)，越高越好。計算公式為：Parse CPU 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時間過多。與PARSE_CPU相比，如果TOT_CPU很高，這個比值將接近100%，這是很好的，說明計算機執行的大部分工作是執行查詢的工作，而不是分析查詢的工作。
Execute to Parse：是語句執行與分析的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析後被重複執行的次數越多。計算公式為：Execute to Parse =100 * (1 - Parses/Executions)。所以如果系統Parses > Executions，就可能出現該比率小於0的情況。該值<0通常說明shared pool設定或者語句效率存在問題，造成反覆解析，reparse可能較嚴重,或者是可能同snapshot有關，通常說明資料庫效能存在問題。 本例中這個值比較低，說明SQL重用率很低。
In-memory Sort：在記憶體中排序的比率，如果過低說明有大量的排序在臨時表空間中進行。考慮調大PGA(10g)。如果低於95%，可以通過適當調大初始化引數PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE來解決，注意這兩個引數設定作用的範圍時不同的，SORT_AREA_SIZE是針對每個session設定的，PGA_AGGREGATE_TARGET則時針對所有的sesion的。
Soft Parse：軟解析的百分比（softs/softs+hards），近似當作sql在共享區的命中率，太低則需要調整應用使用繫結變數。sql在共享區的命中率，小於<95%,需要考慮繫結，如果低於80%，那麼就可以認為sql基本沒有被重用。
Buffer Nowait
buffer hit表示程序從記憶體中找到資料塊的比率，監視這個值是否發生重大變化比這個值本身更重要。對於一般的OLTP系統，如果此值低於80%，應該給資料庫分配更多的記憶體。資料塊在資料緩衝區中的命中率，通常應在95%以上。否則，小於95%，需要調整重要的引數，小於90%可能是要加db_cache_size。一個高的命中率，不一定代表這個系統的效能是最優的，比如大量的非選擇性的索引被頻繁訪問，就會造成命中率很高的假相（大量的db file sequential read），但是一個比較低的命中率，一般就會對這個系統的效能產生影響，需要調整。命中率的突變，往往是一個不好的資訊。如果命中率突然增大，可以檢查top buffer get SQL，檢視導致大量邏輯讀的語句和索引，如果命中率突然減小，可以檢查top physical reads SQL，檢查產生大量物理讀的語句，主要是那些沒有使用索引或者索引被刪除的。
Redo NoWait
library hit表示Oracle從Library Cache中檢索到一個解析過的SQL或PL/SQL語句的比率，當應用程式呼叫SQL或儲存過程時，Oracle檢查Library Cache確定是否存在解析過的版本，如果存在，Oracle立即執行語句；如果不存在，Oracle解析此語句，並在Library Cache中為它分配共享SQL區。低的library hit ratio會導致過多的解析，增加CPU消耗，降低效能。如果library hit ratio低於90%，可能需要調大shared pool區。STATEMENT在共享區的命中率，通常應該保持在95%以上，否則需要要考慮：加大共享池；使用繫結變數；修改cursor_sharing等引數。
Latch Hit
Parse CPU to Parse Elapsd：解析實際執行時間/(解析實際執行時間+解析中等待資源時間)，越高越好。計算公式為：Parse CPU 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時間過多。與PARSE_CPU相比，如果TOT_CPU很高，這個比值將接近100%，這是很好的，說明計算機執行的大部分工作是執行查詢的工作，而不是分析查詢的工作。
Execute to Parse：是語句執行與分析的比例，如果要SQL重用率高，則這個比例會很高。該值越高表示一次解析後被重複執行的次數越多。計算公式為：Execute to Parse =100 * (1 - Parses/Executions)。所以如果系統Parses > Executions，就可能出現該比率小於0的情況。該值<0通常說明shared pool設定或者語句效率存在問題，造成反覆解析，reparse可能較嚴重,或者是可能同snapshot有關，通常說明資料庫效能存在問題。 本例中這個值比較低，說明SQL重用率很低。
In-memory Sort：在記憶體中排序的比率，如果過低說明有大量的排序在臨時表空間中進行。考慮調大PGA(10g)。如果低於95%，可以通過適當調大初始化引數PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE來解決，注意這兩個引數設定作用的範圍時不同的，SORT_AREA_SIZE是針對每個session設定的，PGA_AGGREGATE_TARGET則時針對所有的sesion的。
Soft Parse：軟解析的百分比（softs/softs+hards），近似當作sql在共享區的命中率，太低則需要調整應用使用繫結變數。sql在共享區的命中率，小於<95%,需要考慮繫結，如果低於80%，那麼就可以認為sql基本沒有被重用。