进程在查找空闲缓冲区时，会从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。