REPL_AUX链上会不会有脏块?
在编译《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。
通过类似的测试还可以说明两点:
--the end
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:老熊 来源: 老熊的三分地-Oracle、UNIX、数据恢复
- 标签: REPL_AUX 脏块
- 发布时间:2012-06-07 00:25:04
- [68] Go Reflect 性能
- [64] 如何拿下简短的域名
- [60] Oracle MTS模式下 进程地址与会话信
- [59] android 开发入门
- [59] IOS安全–浅谈关于IOS加固的几种方法
- [58] 【社会化设计】自我(self)部分――欢迎区
- [56] 图书馆的世界纪录
- [49] 视觉调整-设计师 vs. 逻辑
- [47] 读书笔记-壹百度:百度十年千倍的29条法则
- [47] 界面设计速成