PerformanceTuning 筆記4 v$librarycache的分析

snowdba發表於2014-11-17
調優Library Cache的核心思想就是減少解析(parse)

主要手段:
  • 確保使用者使用共享的SQL語句
  • 分配足夠多的記憶體防止已經parse的sql語句被喚出。
  • 避免無效物件的產生。比如drop掉原有的snow.t1表,重建snow.t1表。這樣再執行該表的查詢操作時,看似表名沒有變化但是查詢需要重新解析。
  • 為記憶體需求比較大的SQL保留一部分空間。
  • 將常用的一些應用固定在Library cache中不被喚出。
  • 消除大量的匿名PL/SQL程式碼塊
v$librarycache動態效能檢視統計了librarycache效能和活動指標。下面的引數常用來診斷當前library cache
  • Gets:(解析階段)查詢該SQL是否已經解析過了
  • GetsHits:查詢命中率
  • Pins:(執行階段)讀取或執行的次數
  • Reloads:(解析階段)執行期間找到的物件無效了,或者被喚出了,需要重新解析。
  • Invalidations:(解析階段)如果解析後的物件被改變了,需要重新解析。
v$librarycache的查詢示例:



解讀Library Cache統計資訊:

在動態效能檢視v$librarycache中reload的值應該接近0,如果該值很高就需要調整了。表示已經解析過的SQL由於某種原因被喚出了。如果該SQL語句再次執行需要重新解析。因此減少reload的次數是關鍵。

在動態效能檢視v$librarycache中invalidations值應該接近0。如果改制較高,可能是因為DDL操作導致表結構改變,之前解析的結果全部失效。

在動態效能檢視v$sgastat中的free memory的值應該儘可能低。如果reload值比較高很可能是因為記憶體太小導致。為shared pool分配足夠的記憶體可以提升效果。

librarycahce的命中率:下圖中由於library cache太小導致很多的parse結果被喚出了(reloads 13105)


reloads值應該小於pins的1%。如果reloads大於1,並且free memory值很低通常是因為library cache太小導致。可以透過擴充shared pool的大小來解決。

SQL> select sum(pins) "executions",sum(reloads) "cache misses",sum(reloads)/sum(pins) from v$librarycache;

executions cache misses SUM(RELOADS)/SUM(PINS)
---------- ------------ ----------------------
   4985760        33921             .006803577

注意該值是資料庫執行以來的歷史累加值,如果想要取得某個階段的確切至應該使用AWR報告或者statspack。
或者間隔一個時間段分別執行兩次select namespace,gethitratio,pinhitratio,reloads,invalidations from v$librarycache;對比各個欄位值的變化。

下面的SQL可以顯示正在執行中的SQL語句


根據已知資訊查詢SQL語句的完整資訊

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

相關文章