Oracle Dba必須瞭解的buffer busy waits等待

Buffer Busy Waits是怎麼產生的？

作為一個Oracle Dba，如果你從未遇到過Buffer Busy Waits等待，那麼你算不上一個真正的Oracle Dba。Buffer Busy Waits是Oracle 資料庫非常常見的一個等待，特別是在並發寫比較頻繁的環境裡。說起為什麼會產生這個等待，首先要描述下，Oracle讀寫資料區塊的過程：

1）首先依據資料區塊地址計算出（HASH演算法）資料區塊所在的HASH BUCKET。

2）根據桶的編號，計算出保護這個桶的CBC LATCH，然後申請CBC LATCH，找尋資料區塊在不在桶裡（記憶體裡），我們這裡假設在記憶體裡。

3）讀取/修改資料區塊。

4）釋放CBC LATCH。

以上的描述看似是非常通暢，但是存在一個問題，CBC LATCH的持有是排他的（我們暫時不考慮複雜情況：共用LATCH的持有情況），如果在排他持有CBC LATCH的情況下，讀取資料區塊內容，那麼這個LATCH的持有時間就會比較長，因為相對於LATCH的擷取和釋放這種CPU原子操作，讀取資料區塊的內容是非常耗時的，因此在持有CBC LATCH的情況下，讀取資料區塊，對於讀寫頻繁的資料庫/塊，那麼勢必會造成CBC LATCH的爭用。為瞭解決這個問題，Oracle引入了buffer pin（buffer lock)的功能。

我們有必要對讀取資料區塊的內容重新做下描述，大致步驟如下：

1）首先需要判斷資料區塊所在的HASH BUCKET。

2）然後申請CBC LATCH，定位到資料區塊。

3）以S/X模式擷取資料區塊的buffer pin/lock。（讀取獲得s模式，修改獲得x模式，S和S模式具有相容性，S和X、X和X模式不具有相容性）。

4）釋放CBC LATCH

5）在PIN的保護下，讀取/修改資料區塊。

6）獲得CBC LATCH。

7）釋放（UNPIN)BUFFER PIN(BUFFER LOCK)。

8）釋放CBC LATCH。

看似步驟複雜了，CBC LATCH擷取/釋放了兩次，可是卻大大的提高了並發度。上面描述的步驟裡，持有CBC LATCH的目的變得單純，只是為了修改BUFFER的PIN模式，然後依靠PIN的模式相容性來保護資料區塊，例如：S和S模式的PIN是相容的，可以並發的讀取，S和X模式是不相容的，後來的會話需要產生等待。

雖然LATCH的持有是排他的，但是這個時間極端，引起爭用的可能性不大，如果大家都是來讀資料區塊的，那麼BUFFER LOCK的S模式之間都是具有共用性的，不會產生爭用。但是同一個時刻，如果一個進程以S模式持有了資料區塊的BUFFER LOCK，另一個進程想以X模式持有，那麼就會出現爭用，因為道理很簡單，S模式的BUFFER LOCK和X模式的BUFFER LOCK不相容。同理，兩個同時欲修改同一個資料區塊的進程，也會遭遇BUFFER LOCK衝突.這個衝突以ORACLE 等待事件表示出來就是Buffer Busy Waits，也就是說Buffer Busy Waits等待的本質是buffer lock的爭用導致的。

我們平時經常說讀不阻塞寫，寫不阻塞讀，那是在物理的資料區塊層級，在記憶體裡，讀寫/寫寫在同一個時刻都是互相阻塞的。只有讀讀不阻塞。

為了方便理解，上面很多步驟做了簡化，下面對某些點做些補充：

1）一旦你PIN住了一個資料區塊，不需要立即去UNPIN（移除PIN）它。ORACLE認為你的本次調用後還有可能去訪問這個資料區塊，因此保留了PIN，直到本次調用結束再UNPIN。

2）Oracle在對唯一索引/undo塊/唯一索引的回表/索引root、branch塊的設計上，在訪問(讀取）的時候，擷取的是共用的CBC LATCH，不需要去PIN資料區塊，在持有共用CBC LATCH的情況下讀取資料區塊。可能的原因是這些塊修改的可能性比較小，因此Oracle單獨的採用這種機制。因此對於普通資料區塊的讀取都是需要擷取2次CBC LACTH，而對於這種特殊的資料區塊，只擷取一次共用CBC LATCH就OK 了。

3）我們上面所說的情況都是在資料區塊已經存在在記憶體裡的情況。如果資料區塊不在記憶體，有可能會產生READ BY OTHER SESSION爭用等待。有時間我們再看這個等待的原因。

4）上面描述只符合10G後的版本。在10G前讀讀也會產生BUFFER BUSY WAITS，10G後把這方面的BUFFER BUSY WAITS歸到了READ BY OTHER SESSION等待裡。

5）上面的描述基本都採用了資料區塊這個詞，更準確的表達應該是buffer block。