在编译《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。
通过类似的测试还可以说明两点：
- 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