oracle证明题：未提交的事务也可能被DBWn写进数据文件

学oracle时，很多人会认为，DBWn的写与commit有关。这是错误的。其实，DBWn的写与事务是否commit，一丁点的关系都没有。现在，证明：一个未提交的事务，也是有可能被写入数据文件的。

会话1：

sys@ORCL> select xidusn,xidslot,xidsqn,ubafil,ubablk from v$transaction;

no rows selected

此时没有事务。

会话2：

hr@ORCL> select * from t;

        ID NAME
---------- ----------
         1 a
         2 b
         3 c

hr@ORCL> update t set name='d' where id=1;

1 row updated.

hr发起一条事务。

会话1：

sys@ORCL> /

    XIDUSN    XIDSLOT     XIDSQN     UBAFIL     UBABLK
---------- ---------- ---------- ---------- ----------
        12         10         14          6         88

此时，事务信息被查询出来。

会话1：

hr@ORCL> select dbms_rowid.rowid_relative_fno(rowid) fno,                                
  2             dbms_rowid.rowid_block_number(rowid) blk,
  3             t.*
  4        from t;

       FNO        BLK         ID NAME
---------- ---------- ---------- ----------
         4        404          1 d
         4        404          2 b
         4        404          3 c

接下来，我们分别在内存和数据文件，这两个地方把事务修改的id=1的内容dump出来比较一下：

1）把内存中的数据dump出来

sys@ORCL> alter system dump datafile 4 block 404;

System altered.

部分内容摘入如下：

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 404 maxblk 404

64便是我们这个事务所修改的数据。注意了，此时，我们的事务还没有提交哦。

2）把数据文件中的数据dump出来

sys@ORCL> alter system dump datafile '/u01/app/oracle/oradata/ORCL/datafile/o1_mf_users_8050fkdh_.dbf' block 404;

System altered.

部分内容摘入如下：

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 block from file /u01/app/oracle/oradata/ORCL/datafile/o1_mf_users_8050fkdh_.dbf minblk 404 maxblk 404

看到了没？在数据文件里面也有个64，说明事务修改的脏块已经被DBWn写进数据文件了。

我们再来看一下那个事务的提交状态：

sys@ORCL> select xidusn,xidslot,xidsqn,ubafil,ubablk from v$transaction;

    XIDUSN    XIDSLOT     XIDSQN     UBAFIL     UBABLK
---------- ---------- ---------- ---------- ----------
        12         10         14          6         88

可见：事务还没commit。

证明完毕。

所以，DBWn的写与事务是否commit一点关系也没有。内存是用来提高性能用的，而并不是用来放脏块的。也就是，oracle只要有空闲，就会把这些脏块给flush到数据文件内。

这些未提交的事务但被写入数据文件的数据，即便是已经在你的数据文件了。事务恢复阶段将按需把这些数据回滚掉，这些数据将不再被用上，也就是，已经是垃圾数据了。

注：64是d的ascii码的16进制数