开始
学习网上文章：
我自己所作的实验。
首先根据网络上搜索的结论，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 来维持。
结束