BUFFER CACHE的命中率已成為一個老生常談的話題，在數據庫等待事件出現之前，DBA進行數據庫系統級優化時，往往會首先觀察BUFFER CACHE的命中率。命中率高就意味著數據庫運行正常，很多Oracle官方提供的巡檢腳本都將BUFFER CACHE的命中率大于90%作為考核數據庫性能的指標之一。
BUFFER CACHE命中率高意味著Oracle服務進程基本上都能從BUFFER CACHE中獲取相應的數據塊。如果不考慮存儲的CACHE因素，僅從數據塊的讀取效率上來講，從BUFFER CACHE中讀取（納秒級）要比直接從磁盤上讀取（毫秒級）高很多。所以運行效率高的數據庫往往BUFFER CACHE命中率也較高。但需要強調的是，僅通過一項指標就判斷數據庫BUFFER CACHE正常，未免顯得太過絕對，比如，來考慮一下如下場景：
?大表全表掃描時。如果大表的數據塊沒有在BUFFER CACHE中，那么對大表進行全表掃描時，會引起大量的物理讀（表現為db file scattered read等待事件），進而會導致BUFFER CACHE命中率下降。這種場景多見于數據庫倉庫系統，在這類系統中，BUFFER CACHE的命中率盡管很低，但其業務性質決定了不得不全表掃描。
?執行計劃出錯時。考慮如下相對極端的場景：2張大表，它們所占的數據塊全部在BUFFER CACHE中。它們等值連接時走的是全表掃描并且采用的是NESTED LOOP JOIN的執行計劃。由于2張表的數據塊全部在BUFFER CACHE中，所以在取值過程中BUFFER CACHE的命中率為100%，但事實上其執行效率卻是很低的。這是最常見的一種情況。
?“熱”塊爭用時。這里的“熱”塊指的是多個進程同時訪問BUFFER CACHE中的數據塊。“熱”塊肯定位于BUFFER CACHE中，所以訪問“熱”塊時BUFFER CACHE命中率肯定是100%。但多個進程訪問“熱”塊時往往出現LATCH:CACHE BUFFERS CHAINS等相關等待事件，數據庫的性能會因為這些等待事件而變得緩慢。
從以上3個場景可以看出，BUFFER CACHE命中率的高低和數據庫的性能沒有必然和絕對的關系。但一般情況下，還是希望BUFFER CACHE命中率指標越高越好，AWR/STATSPACK報告也將BUFFER CACHE的命中率期望定位在了100%。
眾所周知，RAC節點間數據塊傳輸主要采用的是CACHE FUSION機制，也就是說當服務進程發現數據塊在本節點中不存在時，會進一步查看數據塊在遠程節點的BUFFER CACHE中是否存在，如果存在且符合傳輸條件，則由LMS進程將數據塊從遠端的BUFFER CACHE傳輸至本地的BUFFER CACHE中。為了減少數據塊在節點間的傳遞次數，所以提高本地BUFFER CACHE的命中率顯得尤為重要。在AWR報告中，有獲取遠程節點CACHE數據塊的統計值。