Oracle块里的 block scn字段什么时候发生变化

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

ub4 bas_kcbh @8

ub2 wrp_kcbh @12

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（即事务修改block时的scn，非事务提交时的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 //涉及大端小端问题，这里的ef860a08 000a就是scn: 0x0a00.080a86ef

进一步将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

Oracle dirty block的一些探讨(一) |Oracle
shared server配置