这篇文章主要讲解了“怎么监控library cache的活动情况”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么监控library cache的活动情况”吧！

通过查看v$librarycache视图，可以监控library cache的活动情况，进一步衡量share pool设置是否合理。其中RELOADS列，表示对象被重新加载的次数，在一个设置合理的系统里，这个数值应该接近于0，另外，INVALIDATIONS列表示对象失效的次数，对象失效后，这意味着sql必须要被重新解析。

下述sql查询librarycache的性能状况：

SELECTNAMESPACE,PINS,PINHITS,RELOADS,INVALIDATIONSFROMV$LIBRARYCACHEORDERBYNAMESPACE;

输出如下：


NAMESPACEPINSPINHITSRELOADSINVALIDATIONS----------------------------------------------------------BODY8870881900CLUSTER39338000INDEX29000OBJECT0000PIPE552655526300SQLAREA2153641321520516112042TABLE/PROCEDURE107756841077440100TRIGGER1852184400

通过上述查询，可以算出librarycache的命中率：

LibraryCacheHitRatio=sum(pinhits)/sum(pins)

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

另外，对于上述的查询，解释如下：

1.对于SQLAREA来说，共执行了21536413次。

2.其中11,204次执行导致了librarycachemiss。这就需要对这些sql进行重新解析，因为它们已经被ageout。

3.sql有2次失效，这同时导致了librarycachemiss。

4.命中率为99.94%,这意味着只有0.06%的sql需要重复解析。、

另外一个问题，在什么情况下需要调整sharepool的大小？

根据performancetuning上的解释，综合我自己的看法，结论如下：

（1）当V$LIBRARYCACHE.RELOADS的值较大，且应用程序已经很好的使用了绑定变量时，可以考虑调大sharepool的值。

（2）当V$LIBRARYCACHE.RELOADS的值很小，且sharepool里的free值较大，可以考虑减少sharepool的值。通过以下查询，获取sharepool的free情况：

SELECT*FROMV$SGASTATWHERENAME='freememory'ANDPOOL='sharedpool';POOLNAMEBYTES-----------------------------------------------sharedpoolfreememory4928280

感谢各位的阅读，以上就是“怎么监控library cache的活动情况”的内容了，经过本文的学习后，相信大家对怎么监控library cache的活动情况这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！