在编译《Oracle Core——Essential Internals for DBAs and Developers》这本书的第6章时,这章有提到进程在查找空闲缓冲区时,会从REPL_AUX链(即辅助LRU链)开始扫描,在扫描的过程中发现有dirty buffer,则会将该buffer从REPL_AUX链取下再链到WRITE_MAIN链上。这里提到的REPL_AUX链,主要用于链接那些能够马上复用的buffer(缓冲区),比如一致性读块,很少访问的块,大表全表扫描的块。而进程在查找可用的空闲或可复用的缓冲区时,会从REPL_AUX链开始查找,如果REPL_AUX链上如果有可用的缓冲区,那么进程就能很快获取到缓冲区以便用于存储从磁盘读入的块。

那在REPL_AUX链上会不会有脏块呢?如果没有,那么进程在扫描REPL_AUX时会更快更简单。而答案是”在REPL_AUX链上是会存在脏块“的。下面用实验来验证一下,测试环境为Oracle 10.2.0.4 for Windows。
1. 准备测试数据:

create table test.t1 as select * from dba_objects;
insert into test.t1 select * from test.t1;
--多执行几次上面的insert.
commit;
--最终T1表的segment大小为72M左右。
create index test.t1_idx on test.t1(owner);

2. 将数据库buffer_cache设置为60M大小,重启数据库(注意sga_target参数值为0)。

3. 执行下面的查询:

select /*+ index(t1) */ sum(object_id) from test.t1 where owner='SYS' ;

4. 查询X$BH表里面挂在REPL_AUX链上的buffer:


SQL> select * from (
  2  select obj,dbarfil,dbablk,to_char(state,'xxxxxxxx') state,to_char(lru_flag,'xxxxxxxx') lru_flag,to_char(flag,'xxxxxxxx') flag
  3  ,tch,dirty_queue from x$bh where obj=24523 and state<>0 and bitand(lru_flag,4)=4 order by dbablk
  4  ) where rownum<=10;

       OBJ    DBARFIL     DBABLK STATE     LRU_FLAG  FLAG             TCH DIRTY_QUEUE
---------- ---------- ---------- --------- --------- --------- ---------- -----------
     24523          8      16743         1         6     80000          0           0
     24523          8      27850         1         6     80000          0           0
     24523          8      27938         1         6     80000          0           0
     24523          8      28895         1         6     80000          0           0
     24523          8      29620         1         6     80000          0           0
     24523          8      29692         1         6     80000          0           0
     24523          8      29830         1         6     80000          0           0
     24523          8      29842         1         6     80000          0           0
     24523          8      29906         1         6     80000          0           0
     24523          8      29980         1         6     80000          0           0

已选择10行。

LRU_FLAG是一个按位的标志,4表示”on auxiliary list(在辅助链表上)“,而上面的结果中LRU_FLAG为6,即2+4,说明这些buffer都在REPL_AUX链上。

5. 更新表T1中的一行数据:


SQL> select dbms_rowid.rowid_create(1,24523,8,16743,1) from dual;

DBMS_ROWID.ROWID_C
------------------
AAAF/LAAIAAAEFnAAB

更新这一行:

update test.t1 set object_name='b' where rowid='AAAF/LAAIAAAEFnAAB';
commit;

6. 再次检查X$BH中刚刚更新的那个块:

SQL> select obj,dbarfil,dbablk,to_char(state,'xxxxxxxx') state,to_char(lru_flag,'xxxxxxxx') lru_flag,to_char(flag,'xxxxxxxx') flag

  2  ,tch,dirty_queue from x$bh where obj=24523 and dbablk=16743 order by dbablk;

       OBJ    DBARFIL     DBABLK STATE     LRU_FLAG  FLAG             TCH DIRTY_QUEUE
---------- ---------- ---------- --------- --------- --------- ---------- -----------
     24523          8      16743         1         6   2002001          1           0

上面的结果中,FLAG也是按位表示的标示,最右边的1(即最低位的1)表示块是脏块(dirty buffer,从v$gbh的视图定义也能看到)。而LRU_FLAG=6表示buffer仍然还在REPL_AUX链上。

7. 在数据库上不做任何操作,过一段时间(大约5分钟之后),DBW进程会将刚才更改的脏块写到磁盘,再次检查X$BH:

SQL> select obj,dbarfil,dbablk,to_char(state,'xxxxxxxx') state,to_char(lru_flag,'xxxxxxxx') lru_flag,to_char(flag,'xxxxxxxx') flag

  2  ,tch,dirty_queue from x$bh where obj=24523 and dbablk=16743 order by dbablk;

       OBJ    DBARFIL     DBABLK STATE     LRU_FLAG  FLAG             TCH DIRTY_QUEUE
---------- ---------- ---------- --------- --------- --------- ---------- -----------
     24523          8      16743         1         6   2202000          1           0

在上面的结果中可以看到,LRU_FLAG仍然为6,表示仍然在REPL_AUX链上,而FLAG最低位从原来的1变成了0,表示已经不是脏块了。FLAG的从左向边第2个“2”数字(原来是0)表示"Buffer has been written once(缓冲区已经写过)"。

从上面的测试可以表明,在REPL_AUX链上是可能存在脏块的。不过REPL_AUX链上存在脏块的可能性非常小,其原因在于,REPL_AUX链上主要是很少被再次访问的块:一致性读的块不可能被修改;大表的全表扫描的块(“大表”的概念在《Oracle Core》这本书中有提到,主要涉及_small_table_threshold这个隐含参数),很少有对整个大表的所有块进行修改;WRITE_AUX链上的buffer在写完后会放回REPL_AUX链,不过这样的块被重新修改的可能性较小,因为WRITE_MAIN和WRITE_AUX的块来源于REPL链上较早之前修改过并且很少被访问的块,从概率上说被再次修改的可能性很小。所以REPL_AUX链上通常都是可以马上能够被重用的buffer。

通过类似的测试还可以说明两点:

  1. buffer在三个LRU子链(REPL_MAIN/REPL_AUX/WRITE_MAIN/)上移动,主要是由进程在寻找可用的buffer时由该进程移动。而buffer在另三个LRU子链(WRITE_MAIN/WRITE_AUX/REPL_AUX)上的移动由数据库写进程(DBW)来完成。这里要说明的是,DBW进程只有在是由前台进程触发的数据库写操作之后才会将buffer从WRITE_AUX移到REPL_AUX链上,而由检查点触发的写操作,不会使buffer在LRU的链上移动。
  2. 只有进程在读磁盘或通过clone产生一致性读需要buffer时,才会扫描LRU链并使buffer在LRU的四个子链上移动,而update这类DML操作在修改内存中的块时,是不会使buffer在LRU四个子链上移动的,所以如果REPL_AUX链上的buffer修改了,它也不会移动,仍然在REPL_AUX链上,使得REPL_AUX链上出现脏块。

--the end

,
Trackback

12 comments untill now

  1. Hi 老熊,你在翻译《Oracle Core》吗? 估计什么时候能出版呀?

    老熊 Reply:

    @Xin, 我和其他人一起在翻译这本书,七八月应该能翻译完成,但是出版预计在年底左右了。

  2. 你在翻译?就你一个人?出版社约的?

    老熊 Reply:

    我跟另外两个朋友在翻译这本书,其中一个是boypoo。

  3. 期待呀。

  4. 无为而为 @ 2012-06-30 17:00

    老熊又在造福人类啊 强烈支持

  5. taowang2016 @ 2012-08-17 10:04

    非常期待,熊哥。

  6. taowang2016 @ 2012-08-20 15:50

    期待中。

  7. 老熊:

    你们翻译的《Oracle Core》 啥时候出版呀?
    由哪个出版社出版呀?

    Thanks
    Xin

  8. 赞高人!
    个人认为:1.当DBWR由 “默认3秒”这个事件启动时,会把Cache buffer checkpoint queue(BCQ)上的dirty block写入数据文件。
    2.但是之后是否会在LRU或者LRUW上的list作出修改,用以标记该脏块已经写入了数据文件?

  9. 老熊,你网站的代码高亮好完美… 好喜欢.

  10. 熊老师,最近很忙吧,您已经有很久没有更新你的博文了哦。呵呵

Add your comment now