http://m.blog.itpub.net/12679300/viewspace-1244578/
Buffer Cache是SGA的一部分，Oracle利用Buffer Cache來管理data block，Buffer Cache的最終目的就是盡可能的減少磁盤I/O。 Buffer Cache中主要有3大結構用來管理Buffer Cache：Hash Bucket、Hash Chain List、LRU List；
Hash Bucket & Hash Chain List：Hash Bucket與Hash Chain List用來實作data block的快速定位。 注意：Hash Chain結構是在共享池中，使用典型記憶體結構Bucket->Chain->Header結構進行管理。而實際緩沖區資訊存儲在高速緩沖區中。
LRU List：挂載有指向具體的free buffer, pinned buffer以及還沒有被移動到 write list的dirty buffer 等資訊。所謂的free buffer就是指沒有包含任何資料的buffer，所謂的pinned buffer，就是指目前正在被通路的buffer。
Write(Dirty)List：挂載有指向具體的 dirty block的資訊。所謂的dirty block，就是指在 buffer cache中被修改過但是還沒有被寫入到磁盤的block。
使用者記憶體中讀資料的順序：
a) 對該Block運用Hash算法，得到Hash值。
b）獲得cache buffers chains latch
c) 到相應的Hash Bucket中搜尋相應Buffer Header
d) 如果找到相應的Buffer Header，然後判斷該Buffer的狀态，看是否需要構造CR Block，或者Buffer處于pin的狀态，最後讀取。
e) 如果找不到，就從磁盤讀入到Buffer Cache中。
邏輯讀的過程
1、Oracle以每個塊的file#+block#和類型做HASH運算,得到HASH值。根據HASH值，到HASH表中取出指定塊的記憶體位址
2、擷取CBC Latch(實驗的重點測試部分)
3、根據HASH值,搜尋CBC連結清單
4、根據DBA找到BH(Buffer Header)加Buffer Pin
5、加完Buffer Pin馬上釋放CBC Latch
6、通路Buffer開始fetch資料
7、擷取CBC Latch
8、釋放Buffer Pin
9、釋放CBC Latch
latch: cache buffer chains:
一個cache buffers chain Latch管理多個Hash Chain。 當多個程序同時檢索Buffer Cache時，獲得cache buffers chain Latch的過程中發生争用，就會産生 latch: cache buffers chain等待事件。
現象：大量的latch: cache buffers chains等待事件導緻系統消耗量大量的CPU，最終導緻系統hang住。
原因：1） 執行效率低下的SQL語句，多個程序同時掃描大範圍的表或索引時；2）熱點塊争用；3）Hash Bucket太少；4）Hash Chain太長，掃描清單時間長；
總結以上的特征：
a) 占用大量的CPU資源；
b) 邏輯讀比正常情況要多很多；
c) 等待事件裡面肯定有latch: cache buffers chains
d) Latch的命中率一般在95%以下，嚴重的在90%以下；
http://blog.itpub.net/12798004/viewspace-1818231/
在Oracle9i以前，如果其它使用者程序已經獲得了這個latch，那麼新的程序就必須等待，直到該使用者程序搜尋完畢(搜尋完畢之後就會釋放該latch)。從Oracle9i開始 cache buffers chains latch可以隻讀共享，也就是說使用者程序A以隻讀(select)的方式通路Block，這個時候獲得了該latch，同時使用者程序B也以隻讀的方式通路Block，那麼這個時候由于是隻讀的通路，使用者程序B也可以獲得該latch。但是，如果使用者程序B要以獨占的方式通路Block，那麼使用者程序B就會等待使用者程序A釋放該latch，這個時候Oracle就會對使用者程序B标記一個latch:cache buffers chains的等待事件。
free buffer waits：是由于無法找到可用的buffer cache 空閑區域，需要等待DBWR 寫入完成引起
- 一般是由于
- 低效的sql
- 過小的buffer cache
- DBWR 工作負荷過量
buffer busy waits：
read by other session：
buffer busy wait/ read by other session 一般以上2個等待事件可以歸為一起處理，建議客戶都進行監控 。 以上等待時間可以由如下操作引起
- select/select —- read by other session: 由于需要從 資料檔案中将資料塊讀入 buffer cache 中引起，有可能是 大量的 邏輯/實體讀 ;或者過小的 buffer cache 引起
- select/update —- buffer busy waits/ read by other session 是由于更新某資料塊後 需要在undo 中 重建建構 過去時間的塊，有可能伴生 enq:cr-contention 是由于大量的實體讀/邏輯讀造成。
- update/update —- buffer busy waits 由于更新同一個資料塊（非同一行，同一行是enq:TX-contention） 此類問題是熱點塊造成
- insert/insert —- buffer busy waits 是由于freelist 争用造成，可以将表空間更改為ASSM 管理 或者加大freelist 。
latch: in memory undo latch
write complete waits