再出发..
全部博文(27)
分类:
2012-05-26 13:23:49
原文地址:学习v$librarycache 作者:lxl0121
通过查看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