http://www.blogjava.net/gdufo/archive/2010/01/01/307966.html
转自:http://blog.chinaunix.net/u2/66903/showart_2004210.html通过查看v$librarycache视图,可以监控library cache的活动情况,进一步衡量share pool设置是否合理。其中
RELOADS
列,表示对象被重新加载的次数,在一个设置合理的系统里,这个数值应该接近于0,另外,INVALIDATIONS列表示对象失效的次数,对象失效后,这意味着sql必须要被重新解析。
下述sql查询librarycache的性能状况:
log_checkpoints_to_alert
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 0
通过上述查询,可以算出library cache的命中率:
Library Cache Hit Ratio = sum(pinhits) / sum(pins)SUM(PINHITS)/SUM(PINS)
----------------------
.999466248
另外一个问题,在什么情况下需要调整share pool的大小?
根据performance tuning上的解释,综合我自己的看法,结论如下:
转载于:https://blog.51cto.com/716378/804316