本文首先詳細介紹了oracle中buffer cache的概念以及所包含的記憶體結構。然後結合各個後臺程序（包括DBWRn、CKPT、LGWR等）深入介紹了oracle對於buffer cache的管理機制，並詳細解釋了oracle為什麼會採用現在的管理機制，是為了解決什麼問題。比如為何會引入touch次數、為何會引入增量檢查點等等。最後全面介紹了有關buffer cache監控以及調優的實用方法。

buffer cache深度分析：概念以及記憶體結構

1. buffer cache的概念
  用最簡單的語言來描述oracle資料庫的本質，其實就是能夠用磁碟上的一堆檔案來儲存資料，並提供了各種各樣的手段對這些資料進行管理。作為管理資料的最基本要求就是能夠儲存和讀取磁碟上的檔案中的資料。眾所周知，讀取磁碟的速度相對來說是非常慢的，而記憶體相對速度則要快的多。因此為了能夠加快處理資料的速度，oracle必須將讀取過的資料快取在記憶體裡。而oracle對這些快取在記憶體裡的資料起了個名字：資料快取記憶體區（db buffer cache），通常就叫做buffer cache。按照oracle官方的說法，buffer cache就是一塊含有許多資料塊的記憶體區域，而這些資料塊主要都是資料檔案裡的資料塊內容的拷貝。通過初始化引數：buffer_cache_size來指定buffer cache的大小。oracle例項一旦啟動，該區域大小就被分配好了。

buffer cache所能提供的功能主要包括：
1） 通過快取資料塊，從而減少I/O。
2） 通過構造CR塊，從而提供讀一致性功能。
3） 通過提供各種lock、latch機制，從而提供多個程序併發訪問同一個資料塊的功能。
2.buffer cache的記憶體結構

2.1 buffer cache概述
oracle內部在實現其管理的過程中，有兩個非常有名的名詞：連結串列和hash演算法。
連結串列是一種資料結構，通過將物件串連在一起，從而構成連結串列結構。這樣，如果要修改、刪除、查詢某個物件的話，都可以先到連結串列中去查詢，而不必實際的訪問物理介質。oracle中最有名的連結串列大概就是LRU連結串列了，我們後面會介紹它。

  而hash演算法則是為了能夠進行快速查詢定位所使用一種技術。所謂hash演算法，就是根據要查詢的值，對該值進行一定的hash演算法後得出該值所在的索引號，然後進入到該值應該存在的一列數值列表（可以理解為一個二維陣列）裡，通過該索引號去找它應該屬於哪一個列表。然後再進入所確定的列表裡，對其中所含有的值，進行一個一個的比較，從而找到該值。這樣就避免了對整個數值列表進行掃描才能找到該值，這種全掃描的方式顯然要比hash查詢方式低效很多。其中，每個索引號對應的數值列在oracle裡都叫做一個hash bucket。

  我們來列舉一個最簡單的hash演算法。假設我們的數值列表最多可以有10個元素，也就是有10個hash buckets，每個元素最多可以包含20個數值。則對應的二維陣列就是t[10][20]。我們可以定義hash演算法為n MOD 10。通過這種演算法，可以將所有進入的資料均勻放在10個hash bucket裡面，hash bucket編號從0到9。比如，我們把1到100都通過這個hash函式均勻放到這10個hash bucket裡，當查詢32在哪裡時，只要將32 MOD 10等於2，這樣就知道可以到2號hash bucket裡去找，也就是到t[2][20]裡去找，2號hash bucket裡有10個數值，逐個比較2號hash bucket裡是否存在32就可以了。

  buffer cache就是使用多個hash bucket來管理的，其hash演算法當然比我們前面列舉的要複雜多了。
我們先來看下面這個圖一。這副圖從邏輯上說明了整個buffer cache的結構是怎麼樣的。這副圖的右
上角列出了三個名詞：hash bucket、buffer header和hash chain。

  這裡的hash bucket就是我們前面說明hash演算法中提到的二維陣列的第一維。它是通過對buffer header
 裡記錄的資料塊地址和資料塊型別運用hash演算法以後，得到的組號。
這裡的hash chain就是屬於同一個hash bucket的所有buffer header所串起來的連結串列。實際上，hash
bucket只是一個邏輯上的概念。每個hash bucket都是通過不同的hash chain而體現出來的。每個hash chain都會由一個cache buffers chains latch來管理其併發操作。

  而對於buffer header來說，每一個數據塊在被讀入buffer cache時，都會先在buffer cache中構造一個buffer header，buffer header與資料塊一一對應。buffer header包含的主要資訊有：
1） 該資料塊在buffer cache中實際的記憶體地址。就是上圖中的虛線箭頭所表示的意思。
2） 該資料塊的型別，包括data、segment header、undo header、undo block等等。
3） 該buffer header所在的hash chain，是通過在buffer header裡儲存指向前一個buffer header的指標和指向後一個buffer header的指標的方式實現的。
4） 該buffer header所在的LRU、LRUW、CKPTQ等連結串列（這些連結串列我們後面都會詳細說明）。也是通過記錄前後buffer header指標的方式實現。
5） 當前該buffer header所對應的資料塊的狀態以及標記。
6） 該buffer header被訪問（touch）的次數。
7） 正在等待該buffer header的程序列表（waiter list）和正在使用該buffer header的程序列表（user list）。
   
   buffer cache中，預設的hash bucket的數量或者說預設有多少條hash chain連結串列，是由一個隱藏引數：
_db_block_hash_buckets決定的。置於該引數的取值，在我的

測試中，8i下，該引數預設為db_block_buffers×2；但是到了9i以後，該引數似乎取的是小於且最接近於db_block_buffers×2的素數。

2.2 轉儲buffer cache
就象例項中的其他記憶體結構一樣，oracle提供了可以將buffer cache轉儲到跟蹤檔案的方法。方法如下：

ALTER SESSION SET EVENTS 'immediate trace name buffers level level';

  這裡的level有很多值，分別可以轉儲buffer cache中的不同的內容。level的可選值包括：
1 只轉儲buffer header
2 在level 1的基礎上再轉儲資料塊頭
3 在level 2的基礎上再轉儲資料塊內容
4 轉儲buffer header和hash chain
5 在level 1的基礎上再轉儲資料塊頭和hash chain
6 在level 2的基礎上再轉儲資料塊內容和hash chain
8 轉儲buffer header和hash chain以及users/waiters連結串列
9 在level 1的基礎上再轉儲資料塊頭、hash chain以及users/waiters連結串列
10 在level 2的基礎上再轉儲資料塊內容、hash chain以及users/waiters連結串列

我們建立一個簡單的測試表，然後看看轉儲出來的buffer header是什麼樣子的。

SQL>createtable buffer_test(id number); SQL>selectobject_idfrom dba_objects whereobject_name='BUFFER_TEST'; OBJECT_ID ---------- 7087 SQL>insertinto buffer_test values(1); SQL>commit;

這時我們知道buffer_test表的object_id是7987，同時，該表中只有2個block具有資料。1個是segment header，另一個就是實際存放了1這個值的資料塊。接著我們把buffer header轉儲出來：

SQL>ALTER SESSION SET EVENTS 'immediate trace name buffers level 1';  到user_dump_dest所定義的目錄下，找到跟蹤檔案並開啟，可以看到類似下面的資訊，這裡我們列出前兩個buffer header以及我們建立的object_id為7087的buffer_test表所對應的buffer header的內容： BH (0x637F0720) file#: 1 rdba: 0x004011ed (1/4589) class 1 ba: 0x63570000 ………………………………… hash: [64be8000,65a5eab4] lru: [637f06ac,637f0824] LRU flags: moved_to_tail ckptq: [NULL] fileq: [NULL] ………………………………… BH (0x64BE8000) file#: 0 rdba: 0x00000000 (0/0) class 0 ba: 0x64800000 ………………………………… hash: [65a5eab4,637f0720] lru: [64be8104,65aa3f0c] ………………………………… BH (0x63BEC0A0) file#: 6 rdba: 0x0180b00a (6/45066) class 1 ba: 0x638B0000 set: 3 dbwrid: 0 obj: 7087 objn: 7087 hash: [65a9ccd4,65a9ccd4] lru: [63bec1a4,63bec02c] ckptq: [65abceb4,63bec66c] fileq: [65abcfbc,63becd10] st: XCURRENT md: NULL rsop: 0x00000000 tch: 1 flags: buffer_dirty gotten_in_current_mode redo_since_read LRBA: [0xe9.229.0] HSCN: [0x0000.00122967] HSUB: [1] RRBA: [0x0.0.0] BH (0x63BECAE8) file#: 6 rdba: 0x0180b009 (6/45065) class 4 ba: 0x638CC000 set: 3 dbwrid: 0 obj: 7087 objn: 7087 hash: [65a9cbcc,65a9cbcc] lru: [63becbec,63beca74] ckptq: [637fc250,63becdc4] fileq: [65ab8ad0,63becdcc] st: XCURRENT md: NULL rsop: 0x00000000 tch: 2 flags: buffer_dirty gotten_in_current_mode redo_since_read LRBA: [0xe9.21b.0] HSCN: [0x0000.00122965] HSUB: [1] RRBA: [0x0.0.0] …………………………………

    我們可以看到第一個BH (0x637F0720)的hash: [64be8000,65a5eab4]和第二個BH (0x64BE8000)的hash：[65a5eab4,637f0720]。這裡記錄的就是指向前一個buffer header和後一個buffer header的指標。這裡，我們看到第一個BH所指向的後一個buffer header的指標是65a5eab4，而第二個BH所指向的前一個buffer header的指標也是65a5eab4，說明這兩個buffer header是在同一個hash chain上。同樣的，我們還可以看到類似結構的lru、ckptq、fileq，這些都是管理buffer header的一些連結串列結構。

  然後，我們來看我們建立的buffer_test表所對應的buffer header。  首先，我們看到class，表示該buffer header所對應的資料塊的型別，具體的值與含義的對應為：1=data block；2=sort block；3=save undo block；4=segment header；5=save undo header；6=free list；7=extent map；8=1st level bmb；9=2nd level bmb；10=3rd level bmb；11=bitmap block；12=bitmap index block；13=unused；14=undo header；15=undo block。我們可以看到與buffer_test表相關buffer header有兩個：一個是4（segment header），另一個是1（data block）。
 
  然後，我們看到rdba，這表示buffer header所對應的資料塊的地址。我們可以看到class為1的buffer header的rdba為0x0180b00a (6/45066)。說明該資料塊的位置是6號檔案的45066號block裡。018表示資料檔案號乘以4，而b00a表示資料塊的號。

SQL>select to_number('018','xxx')/4asfile#,to_number('b00a','xxxx') as block# from dual; FILE# BLOCK# ---------- ---------- 645066

我們看到，該buffer header指向的就是6號檔案裡的45066號資料塊。我們可以再來看看錶buffer_test
裡的rowid所告訴我們的檔案號以及資料塊號，從下面可以看到，結果是一樣的。

SQL>select id,dbms_rowid.rowid_relative_fno(rowid) asfile#, 2 dbms_rowid.rowid_block_number(rowid) as block# from cost.buffer_test; ID FILE# BLOCK# ---------- ---------- ---------- 1645066

  我們可以來看一下st，這表示buffer cache所指向的資料塊的狀態。一共有六種狀態：FREE(0)=可以被重用的資料塊；XCURRENT(1)=例項以排他方式獲取的當前模式資料塊；SCURRENT(2)=可以與其他例項共享的當前模式資料塊；CR(3)=作為一致性讀映象的資料塊，永遠不會被寫入磁碟；READING(4)=正在從磁碟讀出的資料塊；MRECOVERY(5)=正在進行介質恢復的資料塊；IRECOVERY(6)=正在進行例項恢復的資料塊。從狀態說明中我們可以看到，現在表buffer_test的資料塊都是當前模式的資料塊。我們可以來構造一個CR狀態的資料塊。
分別建立兩個session，在一個session中，執行：

SQL>update buffer_test set id=2where id=1;

不要提交，然後在另外一個session中，執行：

SQL>select*from buffer_test; ID ---------- 1

  然後我們轉儲buffer header後，到跟蹤檔案中找到obj為7087的記錄，可以看到類似如下的內容。可以看到該buffer header的狀態就是CR。

………………………………… BH (0x63FFBBC8) file#: 6 rdba: 0x0180b00a (6/45066) class 1 ba: 0x63F5C000 ………………………………… ckptq: [NULL] fileq: [NULL] st: CR md: NULL rsop: 0x00000000 tch: 0 …………………………………

  另外，我們還可以看到tch，就是表示該資料塊被掃描的次數。 以上這些是轉儲出來的內容。Oracle還提供了檢視來顯示buffer header的內容，這就是X$BH。這個檢視就是把轉儲到平面檔案以後所看到的諸如hash、st、tch等的值以列的方式呈現出來。這裡就不做過多的介紹了，有興趣的話，可以將該檢視取出的結果與轉儲出來的檔案進行比較，就可以知道每一列的含義。

http://blog.itpub.net/9842/viewspace-399665/

http://www.db2china.net/club/thread-26869-1-1.html