开始
学习网上文章:http://blog.csdn.net/linwaterbin/article/details/7823519
我自己所作的实验。
首先根据网络上搜索的结论,DBWR会在如下几种情况下写数据:
什么时候dbwr会把数据写入数据文件呢?下面这几种情况: 1.当Buffer Cache中的Dirty List长度达到阀值:DBWR将Dirty List中的Dirty Buffer写入磁盘(user Server Process在LRU List中查找free buffer时将碰到的dirty blocks移入Dirty List)
2.当user Server Process在Buffer Cache的LRU List中搜索了过长的时间而仍然没有找到free buffer:DBWR直接从LRU List中将Dirty Buffer写入磁盘 3.每过3秒钟:DBWR把dirty buffers从LRU List移到Dirty List,一旦Dirty List长度达到阀值,DBWR便将数据写入磁盘 4.Checkpoint发生时:DBWR把所有的dirty buffers从LRU List移到Dirty List,并且开始写数据
5.当Tablespace开始Hot backup时:DBWR把所有属于该表空间的dirty buffers从LRU List移到Dirty List,并且开始写数据
6.当Tablespace offline时:DBWR把所有属于该表空间的dirty buffers从LRU List移到Dirty List,并且开始写数据
7.执行Drop时:drop table或者index将促使DBWR先将属于该segment的dirty blocks写入磁盘
上述描述表明,DBWR动作和是否commit 没有 必然的联系。下面是我的实验和扩展实验。
第一个session:
说明没有事务活动。
SQL> select xidusn, xidslot,xidsqn,ubafil,ubablk from v$transaction; no rows selected SQL>
第二个session:
SQL> create table testtab(id integer,name char(1)) tablespace users; Table created. SQL>
SQL> insert into testtab values(1,'a'); 1 row created. SQL> insert into testtab values(2,'b'); 1 row created. SQL> insert into testtab values(3,'c'); 1 row created. SQL> commit; SQL> update testtab set name='d' where id=1; 1 row updated. SQL>
此时没有提交对 id=1 的 name='d' 的修改。
回到 session 1:
SQL> select dbms_rowid.rowid_relative_fno(rowid) as fno, 2 dbms_rowid.rowid_block_number(rowid) block, t.* from testtab t; FNO BLOCK ID N ---------- ---------- ---------- - 4 20927 1 a 4 20927 2 b 4 20927 3 c SQL> SQL> select FILE#,NAME from V$datafile; FILE# ---------- NAME -------------------------------------------------------------------------------- 1 /home/oracle/app/oracle/oradata/orcl/system01.dbf 2 /home/oracle/app/oracle/oradata/orcl/sysaux01.dbf 3 /home/oracle/app/oracle/oradata/orcl/undotbs01.dbf FILE# ---------- NAME -------------------------------------------------------------------------------- 4 /home/oracle/app/oracle/oradata/orcl/users01.dbf 5 /home/oracle/app/oracle/oradata/orcl/example01.dbf 6 /home/oracle/app/oracle/oradata/orcl/APEX_1930613455248703.dbf FILE# ---------- NAME -------------------------------------------------------------------------------- 7 /home/oracle/app/oracle/oradata/orcl/APEX_2041602962184952.dbf 7 rows selected. SQL> SQL> alter system dump datafile 4 block 20927; System altered. SQL> select value from v$parameter where name='user_dump_dest'; VALUE -------------------------------------------------------------------------------- /home/oracle/app/oracle/diag/rdbms/orcl/orcl/trace SQL> SQL> SQL> select spid from v$session s, v$process p 2 where p.addr = s.paddr 3 and s.audsid = sys_context('userenv','sessionid'); SPID ------------------------ 3984 4042 SQL>
找到 /home/oracle/app/oracle/diag/rdbms/orcl/orcl/trace 下的 dump 文件:
vim orcl_ora_3984.trc,其末尾一段有:
block_row_dump: tab 0, row 0, @0x1f90 tl: 8 fb: --H-FL-- lb: 0x2 cc: 2 col 0: [ 2] c1 02 col 1: [ 1] 64 tab 0, row 1, @0x1f88 tl: 8 fb: --H-FL-- lb: 0x0 cc: 2 col 0: [ 2] c1 03 col 1: [ 1] 62 tab 0, row 2, @0x1f80 tl: 8 fb: --H-FL-- lb: 0x0 cc: 2 col 0: [ 2] c1 04 col 1: [ 1] 63 end_of_block_dump End dump data blocks tsn: 4 file#: 4 minblk 20927 maxblk 20927
64 就是 d 的 ascii 码,表明未提交数据也被刷到数据文件上了。
再来看事务状态:active 表示尚未提交。
SQL> select xidusn,xidslot,xidsqn,ubafil,ubablk,status from v$transaction; XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK STATUS ---------- ---------- ---------- ---------- ---------- ---------------- 10 8 9187 3 1334 ACTIVE SQL> SQL> select * from testtab; ID N ---------- - 1 a 2 b 3 c SQL>
然后回到session 2:
SQL> commit;
然后回到session 1,来看:这是就看到提交好的数据了。
SQL> select dbms_rowid.rowid_relative_fno(rowid) as fno,dbms_rowid.rowid_block_number(rowid) block, t.* from testtab t; FNO BLOCK ID N ---------- ---------- ---------- - 4 20927 1 d 4 20927 2 b 4 20927 3 c
此时如果在dump 数据文件,得到的结果,可以看到 提交后的数据(name=d)在 dump 中。
事实上,数据文件中,对此table,只会维持一份拷贝。其他的要靠 undo 表空间的undo segment 来维持。
结束