腳本之查詢庫緩存上的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等措施，性能優化不是本文重點，不再贅述）。