开始
学习网上文章：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 来维持。
结束
本文转自健哥的数据花园博客园博客，原文链接：http://www.cnblogs.com/gaojian/archive/2012/11/13/2767620.html，如需转载请自行联系原作者
