Oracle dirty block的一些探讨(五)

通过以上一系列测试，我们知道Oracle对于dirty block，在执行内存刷出时，buffer cache的block会覆盖datafile的block。
如果数据库是rac，那会怎么样？
设想以下场景：
假设rac为2个节点，1号节点产生dirty block，1号节点通过lmns进程将此dirty block传输至2号节点，2号节点再次修改dirty block。
通过以上操作，可以看到该dirty block经过了2次修改，而且在1号节点修改的scn小于2号节点修改scn。
需要注意的是在Oracle 10g rac环境中，1号节点和2号节点的由GCS完成scn同步。
默认情况采用Broadcast-on-Commit Scheme，由max_commit_propagation_delay =0决定。在RAC一个节点启动时在alert日志可以看到如下信息：
ALTER DATABASE OPEN
Picked broadcast on commit scheme to generate SCNs
现在不仅有个疑问：
如果2号节点的dirty block先于1号节点的dirty block刷新至数据文件，根据Oracle 会将dirty block刷新至数据文件特点，
那1号节点将刷新dirty block时会将已存储在数据文件的2号节点的dirty block覆盖。在这种情况，将会导致数据丢失。
于是我们得出如下猜想：
（1）dirty block只会在多个节点中同时存在一份，即1号节点dirty block传输至2号节点时，会将1号节点dirty block从dirty list中移除，
通过这样的机制，Oracle在全局就保证了只有一份dirty block。但这种机制就带来传输效率的相对低下。
（2）dirty block在多个节点中同时存在，但2号节点要刷新最新的dirty block时，先刷新1号节点的dirty block。
通过这样的机制，也保证了数据的不丢失，但Oracle要先后写2份dirty block，在高并发，高负载的情况下，势必效率会非常低下。
通过实验解决以上疑问；
首先在1号节点创建dirty block
SQL> alter system flush buffer_cache;

System altered.

SQL> alter system switch logfile;

System altered.

SQL> update zhoul.zhoul set name='active1' where obj#=100;

1 row updated.

SQL> commit;

Commit complete.

然后在2号节点继续创建dirty block

SQL> alter system flush buffer_cache;

System altered.


SQL> update zhoul.zhoul set name='active2' where obj#=100;

1 row updated.

SQL> commit;

Commit complete.

注意在2好节点执行local模式的checkpoint，在rac环境中，执行alte system checkpoint，默认情况为globle。
SQL> alter system checkpoint local;

System altered.

dump 2号节点最新的redolog，注意到scn为0x0000.0008de69和时间戳10:33:15
SQL> select member from v$log a,v$logfile b where a.group#=b.group# and a.status='CURRENT' and a.thread#=2;

MEMBER
--------------------------------------------------------------------------------
/oradata/zhoul/redo2_01.log

SQL> alter system dump logfile '/oradata/zhoul/redo2_01.log' layer 23 opcode 1;

System altered.


REDO RECORD - Thread:2 RBA: 0x000003.00000004.0090 LEN: 0x0044 VLD: 0x02
SCN: 0x0000.0008de70 SUBSCN: 1 04/10/2011 10:33:15
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 6 rdba: 0x0180000c BFT:(1024,25165836) non-BFT:(6,12)
scn: 0x0000.0008de69 seq: 0x01 flg:0x06

dump 1号节点redolog
SQL> select member from v$log a,v$logfile b where a.group#=b.group# and a.status='CURRENT' and a.thread#=1;

MEMBER
--------------------------------------------------------------------------------
/oradata/zhoul/redo03.log

SQL> alter system dump logfile '/oradata/zhoul/redo03.log' layer 23 opcode 1;

System altered.

dump 2号节点最新的redolog，注意到scn为0x0000.0008de59 和时间戳10:33:14
REDO RECORD - Thread:1 RBA: 0x000005.00000004.0010 LEN: 0x0070 VLD: 0x06
SCN: 0x0000.0008de70 SUBSCN: 1 04/10/2011 10:33:14
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 6 rdba: 0x0180000c BFT:(1024,25165836) non-BFT:(6,12)
scn: 0x0000.0008de59 seq: 0x01 flg:0x02

通过以上测试可以清楚的知道，当2号节点要刷出最新的dirty block时，为保证数据不丢失，1号节点的dirty block会先于2号节点刷出。
这种机制告诉我们：对同一个对象做update尽量在同一节点执行，如果在不同节点执行，带来的副作用不仅仅是dirty block 2次刷出带来的低效率，比如块传递等一系列低效率。