Oracle dirty block的一些探讨(二)

继续前面的话题：
现在讨论第二种情况：
如果block在buffer cache中发生了变化（也就意味着dirty block），执行alter system flush buffer_cache是否也会将此block刷新至数据文件？
依然用bbed定位至block 15511 offset 8185中
BBED> set  block 15511 offset 8185
        BLOCK#          15511
        OFFSET          8185
为了观察效果，将zzz用bbed物理修改成ttt
BBED> modify /c ttt
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /oradata/mcstar/zhoul01.dbf (0)
Block: 15511            Offsets: 8185 to 8191           Dba:0x00000000
------------------------------------------------------------------------
74747405 067757

<32 bytes per line>

BBED> sum apply
Check value for File 0, Block 15511:
current = 0x9978, required = 0x9978

由于block 15511在buffer cache中依然存在，我们可以看到选择结果依然是zzz。
SQL>  select * from zhoul;

         I NAME
---------- --------------------
         1 zzz
         2 bbb
         3 ccc
现在在buffer cache中将zzz该为yyy，由于我们采用正规做法修改字段，Oracle认为block已处于dirty状态。
SQL> update zhoul set name='yyy' where name='zzz';

1 row updated.

SQL> commit;

Commit complete.
执行buffer cache刷出，观察block 15511是否刷出至数据文件中。
SQL> alter system flush buffer_cache;

System altered.
将yyy转储为16进制格式797979
SQL> select dump('yyy',16) from dual;

DUMP('YYY',16)
----------------------
Typ=96 Len=3: 79,79,79

用bbed物理查看，可以看到747474已被797979替换
BBED> dump block 15511 offset 8185
File: /oradata/mcstar/zhoul01.dbf (0)
Block: 15511            Offsets: 8185 to 8191           Dba:0x00000000
------------------------------------------------------------------------
79797902 063f64

<32 bytes per line>

通过以上实验我们可以推断出：
当Oracle 认为block在内存中处于dirty状态时，当执行内存刷出时，会将其写入数据文件中。