共计 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 小编将为大家推送更多相关知识点的文章，欢迎关注！