深入分析LRU與DIRTY LIST（轉）

在BUFFER CACHE中，oracle通過幾個連結串列進行記憶體管理，最為人熟知的是LRU LIST與DIRTY LIST（WRITE LIST或CHECKPOINT QUENE），各個LIST上存放的是指向具體BUFFER的指標。

注：除LRU和DIRTY LIST這兩個重要連結串列之外，BUFFER CACHE的管理還存在另外兩個重要的資料結構：hash bucket和cache buffer chain。

具體的LRU演算法不多說了，下面就BUFFER的原理及使用做個簡單介紹：

1、當一個SERVER程式需要讀資料到BUFFER CACHE中時，首先會判斷BUFFER是否存在，如果存在且可用，則獲取該資料，如果BUFFER中不存在該資料，則需要從資料檔案中讀取。

2、在讀取資料之前，SERVER程式需要掃描LRU LIST需找FREE的BUFFER，掃描過程中SERVER程式會把發現的所有已經被修改過的BUFFER移動到CHECKPOINT QUENE上，這些DIRTY BUFFER隨後可以被寫出到資料檔案中。

3、如果CHECKPOINT QUENE超過了閥值,SERVER程式就會通知DBWn去寫出髒資料，這是觸發DBWn寫的一個條件，這個閥值是25%，也就是檢查點佇列超過25%時就會觸發DBWn的寫操作。

SQL> select kvittag,kvitval,kvitdsc from x$kvit
2 where kvittag='kcbldq';

KVITTAG KVITVAL
---------------------------------------------------------------- ----------
KVITDSC
----------------------------------------------------------------
kcbldq 25
large dirty queue if kcbclw reaches this

如果SERVER程式掃描LRU超過一個閥值仍然不能找到足夠的FREE BUFFER，將停止需找，轉而通知DBWn去寫出髒資料，釋放記憶體空間。這個閥值是40%

SQL> select kvittag,kvitval,kvitdsc from x$kvit
2 where kvittag='kcbfsp';

KVITTAG KVITVAL
---------------------------------------------------------------- ----------
KVITDSC
----------------------------------------------------------------
kcbfsp 40
Max percentage of LRU list foreground can scan for free

4、找到足夠的BUFFER之後，SERVER程式就可以將資料從資料檔案讀入BUFFER CACHE中。

5、如果讀取的BLOCK不滿足讀一致性需求，則SERVER程式需要通過當前BLOCK版本和回滾段構造前映象返回給使用者。

從ORACLE 8i開始LRU LIST和DIRTY LIST又分別增加了輔助LIST(AUXILIARY LIST)，引入輔助LIST之後，當資料庫初始化時，BUFFER首先存放在LRU的輔助LIST上，當被使用後移動到LRU住LIST上（MAIN PRL_LIST），這樣使用者程式搜尋FREE BUFFER時，就可以從LRU-AUX LIST開始，而DBWR搜尋DIRTY BUFFER時，則可以從LRU-MAIN LIST開始，從而提高搜尋效率和資料庫效能。

可以通過如下命令轉儲BUFFER CACHE內容，從而清晰地看到以上描述的資料結構：

alter session set events 'immediate trace name buffers level n';

不同LEVEL轉儲的內容詳細程度不同，此命令可用級別主要有1~10級，各級別含義如下：

LEVEL 1：僅包含BUFFER HEADERS資訊。

LEVEL 2：包含BUFFER HEADERS和BUFFER概要資訊轉儲。

LEVEL 3：包含BUFFER HEADERS和完整BUFFER內容轉儲。

LEVEL 4：LEVEL1 + LATCH轉儲 + LRU佇列。

LEVEL 5：LEVEL4 + BUFFER概要資訊轉儲。

LEVEL 6和LEVEL 7：LEVEL4 + 完整的BUFFER內容轉儲。

LEVEL 8：LEVEL4 + 顯示users/waiters資訊。

LEVEL 9：LEVEL5 + 顯示users/waiters資訊。

LEVEL 10：LEVEL6 + 顯示users/waiters資訊。

SQL> alter session set events 'immediate trace name buffers level 4';

會話已更改。

在跟蹤檔案中找到了我想要看到的：

MAIN RPL_LST Queue header (NEXT_DIRECTION)[24be8c70,24bf3a7c]
24BE8C1C=>247E7BF4=>247E7848=>247E7904=>247E7CB0=>247E79C0=>247E7D6C=>247E7A7C
247E7B38=>247E7E28=>24BE8CD8=>247F7F30=>247F7FEC=>24BE8290=>247E7EE4=>247E7FA0
247E805C=>247E8118=>247E81D4=>247E8290=>247E834C=>247E8408=>247E84C4=>247E8580
.........................
MAIN RPL_LST Queue header (PREV_DIRECTION)[24be8c70,24bf3a7c]
24BF3A28=>24BF3AE4=>24BF3BA0=>24BF3C5C=>24BF3D18=>24BF3DD4=>24BF3E90=>24BF3F4C
24BF4008=>24BF40C4=>24BF4A50=>25FF2ABC=>24BEAD28=>24BEBC94=>24BEC040=>24BEBEC8
24BEB480=>24BEB770=>257E778C=>257E7848=>257E7904=>257E7D6C=>277F947C=>277F976C
.........................
MAIN WRT_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN WRT_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY WRT_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY WRT_LST Queue header (PREV_DIRECTION)[NULL]
MAIN XOBJ_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN XOBJ_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY XOBJ_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY XOBJ_LST Queue header (PREV_DIRECTION)[NULL]
MAIN XRNG_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN XRNG_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY XRNG_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY XRNG_LST Queue header (PREV_DIRECTION)[NULL]
MAIN REQ_LST Queue header (NEXT_DIRECTION)[NULL]
MAIN REQ_LST Queue header (PREV_DIRECTION)[NULL]
AUXILIARY REQ_LST Queue header (NEXT_DIRECTION)[NULL]
AUXILIARY REQ_LST Queue header (PREV_DIRECTION)[NULL]

紅色部分我們可以清晰的看到LRU主LIST的佇列資訊，很直觀的連結串列。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/25964700/viewspace-703109/，如需轉載，請註明出處，否則將追究法律責任。

深入分析LRU與DIRTY LIST（轉）

相關文章