DBWR 3个触发条件详细解释

来自：http://blog.itpub.net/21907916/viewspace-715578/

DBWR 3个触发条件详细解释2012-02-03 12:09:10

分类： Linux

Oracle Buffer Cache原理(DBWR 3个触发条件详细解释)  

DbWr3个触发条件：

1、当dirty list达到一定数量（阀值25%），,导致Server Proceess通知DBWn写赃数据

2、当扫描LRU list达到一定数量还未找到free buffer 时，停止搜索free buffer，直接通知DBWn写脏数据

3、checkpoint写数据

 

       通常数据的访问和修改都是需要通过buffer cache来完成的,当一个 server process访问数据的时候,首先需要确定的是,我们所需要的数据在buffer cache中是否存在,如果数据在buffer中存在呢,我们还需要根据data buffer的状态,来判断是否进行db block gets还是consistent gets,如果数据在buffer中不存在,则我们需要在buffer cache中寻找足够的空间来加载我们所需要的数据,如果在buffer cache中我们找不到足够的空间,那么我们就需要触发DBWn进程,去写出脏数据,用来释放我们的buffer空间.

Oracle通过3个list来对buffer进行管理，是LRU List + Dirty List+Auxiliary List

这些list存放的就是具体指向buffer的指针，类似索引。
      LRU List主要就是用来维护内存中的buffer,按照我们LRU(Least Recently Used)的方式来进行管理.，当db初始化的时候,所有的buffer都被捕HASH到LRU List上进行管理.当我们从数据文件中读取数据的时候我们现在要在LRU List上面寻找free的buffer,然后将数据读取到我们所找到的这个free buffer中.只要数据被修改了,那么这个buffer的状态就变为了dirty,那么Oracle就会把这个buffer从LRU List移到Dirty List(Checkpoint Queue)中去.在Dirty List上的buffer都是一些候选的稍后会被DBWn写出到数据文件的buffer, 注意点：一个buffer要么存在于LRU List上面,要么存在于Dirty List上面,不可能同时存在于两个List上面.
a、.当Server process试图通过扫描LRU List来寻找Free的Buffer的时候,扫描过程中会把已发现的所有Dirty buffer从LRU List移动到

Dirty List(Checkpoint Queue)中去，同时，这些buffer是我刚才说的可以候选的被DBWn进程写出到数据文件中的buffer.
   (Server process主动将Dirty buffer从LRU List移动到Dirty List)   --移动
 
b、当Dirty List(Checkpoing Queue)中的Dirty Buffer量超过了一顶的阀值,那么Server process就会通知DBWn进程写出脏数据
  (Checkpoint Queue阀值到达25%,,导致Server Proceess通知DBWn写赃数据)   --写
 
    SQL> select kvittag,kvitval,kvitdsc from x$kvit  where kvittag='kcbldq';

    KVITTAG                                                             KVITVAL
    ---------------------------------------------------------------- ----------
    KVITDSC
    ----------------------------------------------------------------
    kcbldq                                                                   25
    large dirty queue if kcbclw reaches this
c、如果Server process扫描了LRU超过一个阀值也没有找到足够的Free的buffer,这个时候也将会停止搜索free buffer的任务然后直接通知DBWn写脏数据来释放内存空间,当然这个Server process会处于free busy wait的等待事件.这个阀值是40%,同时这还是触发我们DBWn进程的一个条件
     (LRU扫描40%没有找到Free buffer,Server process通知DBWn写脏数据)  --写
    SQL> select kvittag,kvitval,kvitdsc from x$kvit
         where kvittag='kcbfsp';

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

  
d、同时,因为Checkpoint Queue的引入,DBWn还会主动的扫描LRU List,将我们发现的Dirty Buffer从LRU List移动到checkpoing queue,扫描LRU List的范围是25%.
   (DBWn主动扫描LRU的25%,依照结果从LRU中移动Dirty Buffer到Dirty List中) --移动
    SQL> select kvittag,kvitval,kvitdsc from x$kvit
         where kvittag='kcbdsp';

    KVITTAG                                                             KVITVAL
    ---------------------------------------------------------------- ----------
    KVITDSC
    ----------------------------------------------------------------
    kcbdsp                                                                   25
    Max percentage of LRU list dbwriter can scan for dirty
   
    
e、从Oracle 8i开始呢LRU List和Dirty List分别又引入了Auxiliary List,目的是为了提高管理的效率.那么这个List的是怎么工作的呢?当我们的数据库初始化的时候,BUffer首先会被HASH到LRU的Auxiliary List(Auxiliary RPL_LST)上面,那么当buffer被使用后(注意:是使用而不是修改),会被从LRU的Auxililary List移动到LRU的Main List(MAIN RPL_LST)上面,这个时候当用户搜索Free buffer的时候,就可以从Auxiliary RPL_LST中开始,而DBWn主动搜索LRU List寻找Dirty buffer的时候就会从MAIN RPL_LST开始.这样一来就提高了我们数据库的搜索效率和性能