PerformanceTuning 筆記4 v$librarycache的分析

調優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/，如需轉載，請註明出處，否則將追究法律責任。