共計 1524 個字符，預計需要花費 4 分鐘才能閱讀完成。

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

----------- -------------------------- ----------
shared pool free memory 4928280

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