怎么監控library cache的活動情況

這篇文章主要講解了“怎么監控library cache的活動情況”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么監控library cache的活動情況”吧！

    通過查看v$librarycache視圖，可以監控library cache的活動情況，進一步衡量share pool設置是否合理。其中RELOADS列，表示對象被重新加載的次數，在一個設置合理的系統里，這個數值應該接近于0，另外，INVALIDATIONS列表示對象失效的次數，對象失效后，這意味著sql必須要被重新解析。

    下述sql查詢librarycache的性能狀況：

SELECT NAMESPACE, PINS, PINHITS, RELOADS, INVALIDATIONS
  FROM V$LIBRARYCACHE
 ORDER BY NAMESPACE;

輸出如下：

NAMESPACE             PINS    PINHITS    RELOADS INVALIDATIONS
--------------- ---------- ---------- ---------- -------------
BODY                  8870       8819          0             0
CLUSTER                393        380          0             0
INDEX                   29          0          0             0
OBJECT                   0          0          0             0
PIPE                 55265      55263          0             0
SQL AREA          21536413   21520516      11204             2
TABLE/PROCEDURE   10775684   10774401          0             0
TRIGGER               18521844          0             0

通過上述查詢，可以算出library cache的命中率：

Library Cache Hit Ratio = sum(pinhits) / sum(pins)

SUM(PINHITS)/SUM(PINS)
----------------------
            .999466248

另外，對于上述的查詢，解釋如下：

1.對于SQL AREA來說，共執行了21536413次。

2.其中11,204次執行導致了library cache miss。這就需要對這些sql進行重新解析，因為它們已經被age out。

3.sql有2次失效，這同時導致了library cache miss。

4.命中率為99.94%,這意味著只有0.06%的sql需要重復解析。、

另外一個問題，在什么情況下需要調整share pool的大小？

根據performance tuning上的解釋，綜合我自己的看法，結論如下：

（1）當V$LIBRARYCACHE.RELOADS的值較大，且應用程序已經很好的使用了綁定變量時，可以考慮調大share pool的值。

（2）當V$LIBRARYCACHE.RELOADS的值很小，且share pool里的free值較大，可以考慮減少share pool的值。通過以下查詢，獲取share pool的free情況：

SELECT * FROM V$SGASTAT 
 WHERE NAME = 'free memory'
   AND POOL = 'shared pool';


POOL        NAME                            BYTES
----------- -------------------------- ----------
shared pool free memory                   4928280

感謝各位的閱讀，以上就是“怎么監控library cache的活動情況”的內容了，經過本文的學習后，相信大家對怎么監控library cache的活動情況這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！