脚本之查询库缓存上的PIN命中率

   v$librarycache

这个视图包含了关于library cache的性能统计信息，对于共享池的性能调优很有帮助。它是按照命名空间分组统计的，结构如下：

字段	数据类型	说明
NAMESPACE	VARCHAR2(15)	library cache的命名空间
GETS	NUMBER	请求GET该命名空间中对象的次数。
GETHITS	NUMBER	请求GET并在内存中找到了对象句柄的次数（锁定命中，latch命中）。
GETHITRATIO	NUMBER	请求GET的命中率。
PINS	NUMBER	请求pin住该命名中对象的次数。
PINHITS	NUMBER	库对象的所有元数据在内存中被找到的次数（pin命中）。
PINHITRATIO	NUMBER	Pin命中率。
RELOADS	NUMBER	Pin请求需要从磁盘中载入对象的次数。
INVALIDATIONS	NUMBER	命名空间中的非法对象（由于依赖的对象被修改所导致）数。
DLM_LOCK_REQUESTS	NUMBER	GET请求导致的实例锁的数量。
DLM_PIN_REQUESTS	NUMBER	PIN请求导致的实例锁的数量.
DLM_PIN_RELEASES	NUMBER	请求释放PIN锁的次数。
DLM_INVALIDATION_REQUESTS	NUMBER	GET请求非法实例锁的次数。
DLM_INVALIDATIONS	NUMBER	从其他实例那的得到的非法pin数。

注释：

gets字段是针对找句柄（library cache object handle），而pins字段是针对找library cache object。

library cache object handle和library cache object 两个部分组成了一个完整的库对象。

其中，library cache object 这个部分可以被刷出到磁盘上，需要时再重载（

reload

）到库缓存中。

只有状态为recreatable的chunk才是可以被刷出的对象（位于shared pool的LRU链表上）。

其中PIN的命中率（或未命中率）是我们系统调优的一个重要依据：

SQL> select sum(pins) "hits",           

  2         sum(reloads) "misses",           

  3         sum(pins)/(sum(pins)+sum(reloads)) "Hits Ratio"           

  4  from v$librarycache;           

      hits     misses Hits Ratio           

---------- ---------- ----------           

  84962803        288 0.99999661           

SQL>            

SQL> select sum(pins) "hits",           

  2         sum(reloads) "misses",           

  3         ((sum(reloads)/sum(pins))*100) "Reload%"           

  4  from v$librarycache;           

      hits     misses    Reload%           

---------- ---------- ----------           

  84963808        288 0.00033896           

SQL>           

当命中率小于99%或未命中率大于1%时，说明系统中硬解析过多（重载（

reload

）不是意味着将library cache object 这个部分从磁盘读取到库缓存中？而是通过重新解析SQL语句来重建（recreate）library cache object 这个部分？），要做系统优化（增加Shared Pool、使用绑定变量、修改cursor_sharing等措施，性能优化不是本文重点，不再赘述）。