学习v$librarycache

http://www.blogjava.net/gdufo/archive/2010/01/01/307966.html

学习v$librarycache

转自：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

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

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
 
 
 
 另参考：
 
 http://www.itpub.net/thread-269800-1-1.html