技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> Oracle --> REPL_AUX链上会不会有脏块?

REPL_AUX链上会不会有脏块?

浏览:772次  出处信息

    在编译《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 state0 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。

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

  • 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的链上移动。
  • 只有进程在读磁盘或通过clone产生一致性读需要buffer时,才会扫描LRU链并使buffer在LRU的四个子链上移动,而update这类DML操作在修改内存中的块时,是不会使buffer在LRU四个子链上移动的,所以如果REPL_AUX链上的buffer修改了,它也不会移动,仍然在REPL_AUX链上,使得REPL_AUX链上出现脏块。
  •     --the end

    QQ技术交流群:445447336,欢迎加入!
    扫一扫订阅我的微信号:IT技术博客大学习
    © 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

    京ICP备15002552号-1