Oracle block scn什么时候发生变化

我们知道block scn存在 block头中，其具体位置在block offset 8-13中，即占用6个字节。
用bbed查看，可以看到scn处于kcbh结构体中，其中offset 8-11属于scn的低8位，offfset 12-13属于scn的高4位。
struct kcbh, 20 bytes @0
ub1 type_kcbh @0
ub1 frmt_kcbh @1
ub1 spare1_kcbh @2
ub1 spare2_kcbh @3
ub4 rdba_kcbh @4
[color=red] ub4 bas_kcbh @8
ub2 wrp_kcbh @12 [/color]
ub1 seq_kcbh @14
ub1 flg_kcbh @15
ub2 chkval_kcbh @16
ub2 spare3_kcbh @18
那我们不禁有个疑问？此scn是什么时候产生的呢？是该block发生变化时，还是该block从buffer_cache刷到数据文件时产生的呢？
我们先做简要分析
假设会话开始于scn 1000，block scn记录的是block变化时scn
（1）不论引起该block变化的事务提交与否，当block scn大于1000时，那么会话将读取该block后，为保证事务一致性会话将读取undo block（即consistent read）。
（2）不论引起该block变化的事务提交与否，当block scn小于1000时，那么会话将读取该block后，如果事务已提交，将直接读取结果。如果事务未提交，那再次读取undo block，构造一致性block。
采用此方法，当有多并发事务时，原理相似，并不会导致事务不一致。
如果block scn记录的是内存刷到数据文件时的current scn，那会有什么样的后果？
假设block变化scn为1500。block scn记录的是从block从buffer_cache刷到数据文件时产生，其scn为2000并已记录在block head中，且此block已不在内存中。
假设会话开始于scn 1600，当已引起该block变化的事务已提交，从事务一致性角度来讲，将直接读取block（即current read），但由于block head记录为scn 2000，
1600<2000，又满足consistent read条件（一直读到scn<1600，且事务已提交的scn为止），这样又会引起事务不一致。

经过以上分析，我们得出以下结论，block head记录的是该引起该block变化时的scn。


下面通过实验来解答上述结论。以下测试来自测试环境，数据库极少事务变化量。
首先查看表格zhoul在数据库的存放位置，由以下查询可知zhoul表格数据存放在7号文件block号为15511的数据块中。
SQL> col file# for 999
SQL> col block# for 99999
SQL> set linesize 300
SQL> select dbms_rowid.ROWID_RELATIVE_FNO(rowid) file#,dbms_rowid.ROWID_BLOCK_NUMBER(rowid) block#,i,name from zhoul;

FILE# BLOCK# I NAME
----- ------ ---------- --------------------
7 15511 1 aaa
7 15511 2 bbb
7 15511 3 ccc
为了获得比较干净的测试环境，首先切换一个归档日志，这样可以将其他事务的变化条目排除在这个online redolog之外。
SQL> alter system switch logfile;

System altered.


SQL> select * from zhoul;

I NAME
---------- --------------------
1 uuu
2 bbb
3 ccc
在内存中修改表格zhoul数据，注意将字段i=1修改成系统最新的scn值，并进行提交。这样该数据文件头在buffer_cache存储的scn将会比10995251185389略大
但应该会比10995251185563小。
SQL> update zhoul set i=(select current_scn scn from v$database) where i=1;

1 row updated.

SQL> commit;

Commit complete.

SQL> col i for 999999999999999999
SQL> select * from zhoul;

I NAME
------------------- --------------------
10995251185389 uuu
2 bbb
3 ccc

SQL> select current_scn i from v$database;

I
-------------------
10995251185563
打开statistic跟踪，可以看到全部为8个consistent gets，也就意味着15511号还在buffer_cache中。
SQL> set autot traceonly stat
SQL> select * from zhoul;


Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
8 consistent gets
0 physical reads
0 redo size
523 bytes sent via SQL*Net to client
400 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
3 rows processed
现在将buffer_cache中数据块刷出至数据文件中。
SQL> alter system flush buffer_cache;

System altered.

获得包含此事务的online redolog
SQL> set autot off
SQL> select member from v$log a,v$logfile b where a.group#=b.group# and a.status='CURRENT';

MEMBER
--------------------------------------------------------------------------------
/oradata/mcstar/redo01.log

将redo01.log dump出来，由于本文只研究数据块写出操作，固只需dump layer为23，opcode为1的change。
SQL> alter system dump logfile '/oradata/mcstar/redo01.log' layer 23 opcode 1;

System altered.
打开跟踪文件可以看到，其scn为 0x0a00.080a86ef，此值和bbed结果一致。
CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ: 0 OP:23.1
Block Written - afn: 7 rdba: 0x01c03c97 BFT:(1024,29375639) non-BFT:(7,15511)
scn: 0x0a00.080a86ef seq: 0x03 flg:0x06


BBED> dump block 15511 offset 0 count 20
File: /oradata/mcstar/zhoul01.dbf (0)
Block: 15511 Offsets: 0 to 19 Dba:0x00000000
------------------------------------------------------------------------
06a20000 973cc001 ef860a08 000a0306 3f130000
进一步将0x0a00.080a86ef转换成10进制之后为10995251185391，此值比10995251185389略大，但小于10995251185563，也就证明了我们的猜想：
block head的scn记录的是该block改变时的scn，并非从buffer_cache时刷出的scn。
SQL> col scn for 999999999999999
SQL> select to_number('0a00080a86ef','xxxxxxxxxxxx') scn from dual;

SCN
----------------
10995251185391