[20170419]关于块scn号.txt

--//数据块里面有许多scn号相关。

--//数据块本身有三处记录的相应的SCN：数据块头的SCN(block scn)、ktbbh结构下的 kscnbas,kscnwrp(cleanout scn)、ITL信息中的 --//scn/fsc(commit scn 有时候会是control scn),有时候会存在一点点混乱,通过例子说明：

1.环境：

SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- -------------------------------------------------------------------------------- x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SCOTT@book> create table deptx as select * from dept ;

Table created.

SCOTT@book> @ &r/qq deptx 1

ROWID                    OBJECT         FILE        BLOCK          ROW ROWID_DBA                  DEPTNO DNAME          LOC ------------------ ------------ ------------ ------------ ------------ -------------------- ------------ -------------- ------------- AAAWE6AAEAAAAIjAAA        90426            4          547            0  0x1000223                     10 ACCOUNTING     NEW YORK

SCOTT@book> alter system checkpoint ;

System altered.

--//ITL信息有一列是ktbitflg,其不同值的含义如下 ：

---- = transaction is active, or committedpending cleanout C--- = transaction has been committed and locks cleaned out -B-- = this undo record contains the undo for this ITL entry --U- = transaction committed (maybe longago); SCN is an upper bound ---T = transaction was still active atblock cleanout SCN C-U- = Block cleaned by delayed block cleanout, and rollback segment info is overwritten.

--//建立脚本：

$ cat scn.cmd set count 8192 set width 210

p dba 4,547  kcbh.bas_kcbh

p dba 4,547  ktbbh.ktbbhcsc.kscnbas

p dba 4,547  ktbbh.ktbbhitl[0].ktbitflg

p dba 4,547  ktbbh.ktbbhitl[0].ktbitbas

p dba 4,547  ktbbh.ktbbhitl[1].ktbitflg

p dba 4,547  ktbbh.ktbbhitl[1].ktbitbas

#p dba 4,547  ktbbh.ktbbhitl[2].ktbitflg

#p dba 4,547  ktbbh.ktbbhitl[2].ktbitbas quit

2.首先观察:

$ORACLE_HOME/bin/bbed parfile=bbed.par cmdfile=scn.cmd BBED> p dba 4,547  kcbh.bas_kcbh ub4 bas_kcbh                                @8        0x427a5508

BBED> p dba 4,547  ktbbh.ktbbhcsc.kscnbas

ub4 kscnbas                                 @28       0x427a5506

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitflg

ub2 ktbitflg                                @60       0x8000 (KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitbas

ub4 ktbitbas                                @64       0x427a5506

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitflg

ub2 ktbitflg                                @84       0x0000 (NONE)

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitbas

ub4 ktbitbas                                @88       0x00000000

--//先观察伪列ora_rowscn.

SCOTT@book> select ora_rowscn,deptx.* from deptx where rownum=1;   ORA_ROWSCN       DEPTNO DNAME          LOC ------------ ------------ -------------- ------------- 14000215302           10 ACCOUNTING     NEW YORK

select 14000215302,trunc(14000215302/power(2,32)) scn_wrap,mod(14000215302,power(2,32))  scn_base from dual

14000215302     SCN_WRAP     SCN_BASE SCN_WRAP16 SCN_BASE16 ------------ ------------ ------------ ---------- ---------- 14000215302            3   1115313414          3   427a5506

--//首先颠覆我自己以前的看法，伪列ora_rowscn的信息来源于ITL槽,而不是数据块的 kcbh.bas_kcbh.

--//为什么不是 ktbbh.ktbbhcsc.kscnbas (表示 scn at last block cleanout)，我测试修改该值，执行以上语句14000215302还是不变。 --//执行前要 alter system flush buffer_cache ;(如果要写这些太长，大家可以自行测试)

3.产生1个事务，看看情况：

SCOTT@book> update deptx set dname=lower(dname) where deptno=10;

1 row updated.

SCOTT@book> select ora_rowscn,deptx.* from deptx where rownum=1;

  ORA_ROWSCN       DEPTNO DNAME          LOC ------------ ------------ -------------- ------------- 14000215302           10 accounting     NEW YORK

SYS@book> alter system checkpoint ;

System altered.

SYS@book> alter system checkpoint ;

System altered.

SYS@book> alter system checkpoint ;

System altered.

$ $ORACLE_HOME/bin/bbed parfile=bbed.par cmdfile=scn.cmd

BBED> p dba 4,547  kcbh.bas_kcbh

ub4 bas_kcbh                                @8        0x427a5a64

BBED> p dba 4,547  ktbbh.ktbbhcsc.kscnbas

ub4 kscnbas                                 @28       0x427a5506

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitflg

ub2 ktbitflg                                @60       0x8000 (KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitbas

ub4 ktbitbas                                @64       0x427a5506

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitflg

ub2 ktbitflg                                @84       0x0001 (NONE)

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitbas

ub4 ktbitbas                                @88       0x00000000

--//可以发现1个事务在第2个事务槽(从0记数)。没有提交。块kcbh.bas_kcbh 的scn_base =0x427a5a64,发生了变化。

--// 0x427a5a64 = 1115314788 SCOTT@book> select power(2,32)*3+1115314788 from dual ; POWER(2,32)*3+1115314788 ------------------------              14000216676

--//现在提交。

SCOTT@book> commit ;

Commit complete.

SYS@book> alter system checkpoint ;

System altered.

SYS@book> alter system checkpoint ;

System altered.

SYS@book> alter system checkpoint ;

System altered.

$ $ORACLE_HOME/bin/bbed parfile=bbed.par cmdfile=scn.cmd

BBED> p dba 4,547  kcbh.bas_kcbh

ub4 bas_kcbh                                @8        0x427a5a64

BBED> p dba 4,547  ktbbh.ktbbhcsc.kscnbas

ub4 kscnbas                                 @28       0x427a5506

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitflg

ub2 ktbitflg                                @60       0x8000 (KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitbas

ub4 ktbitbas                                @64       0x427a5506

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitflg

ub2 ktbitflg                                @84       0x0001 (NONE)

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitbas

ub4 ktbitbas                                @88       0x00000000

--//出现1个很奇怪的情况，脏块并没有写盘，我一直不知道为什么?这也是我前面遇到的情况，链接

--// , 视乎这个问题出现在使用IMU的情况。

SCOTT@book> select ora_rowscn,deptx.* from deptx where rownum=1;

  ORA_ROWSCN       DEPTNO DNAME          LOC ------------ ------------ -------------- ------------- 14000216978           10 accounting     NEW YORK

select 14000216978,trunc(14000216978/power(2,32)) scn_wrap,mod(14000216978,power(2,32))  scn_base from dual

14000216978     SCN_WRAP     SCN_BASE SCN_WRAP16 SCN_BASE16 ------------ ------------ ------------ ---------- ---------- 14000216978            3   1115315090          3   427a5b92

SCOTT@book> alter system flush buffer_cache ;

System altered.

$ $ORACLE_HOME/bin/bbed parfile=bbed.par cmdfile=scn.cmd

BBED> p dba 4,547  kcbh.bas_kcbh ub4 bas_kcbh                                @8        0x427a5b92

BBED> p dba 4,547  ktbbh.ktbbhcsc.kscnbas

ub4 kscnbas                                 @28       0x427a5506

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitflg

ub2 ktbitflg                                @60       0x8000 (KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitbas

ub4 ktbitbas                                @64       0x427a5506

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitflg

ub2 ktbitflg                                @84       0x2001 (KTBFUPB)

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitbas

ub4 ktbitbas                                @88       0x427a5b92

--//现在Ok了。ktbbh.ktbbhitl[1].ktbitflg 的表示0x2，表示U。也就是快速提交。

--//ktbbh.ktbbhitl[1].ktbitbas= kcbh.bas_kcbh = 提交事务的scn。

4.再产生1个事务，看看delay block cleanout情况：

--//正常出现delay block cleanout有几种情况，一般事务修改许多块，修改达到一定程度占缓存的10%以上。在提交时超出部分，不做

--//快速提交，而是等下次访问时更新，叫delay block cleanout。

As a transaction modifies blocks, the buffer header addresses are recorded in a commit cleanout data structure, which

can hold pointers to up to 10% of the buffers in the cache. When the transaction commits, it traverses its commit cleanout data structure in reverse order and cleans out its ITL entries. The commit cleanout of a block can fail if the block has already been written to disk, or for several other reasons. If a commit cleanout fails for any reason, then the block is written to disk with the ITL and row-level locks not yet cleaned out. This is where delayed block cleanout comes in.

也就是说data buffer有一个记录modified block 的list,用来记录每个transaction更改的block，而这个List最多只能记录占data

buffer 10%的block，当事务提交时，这部分记录在list中的block会做fast commit cleanout,没有记录到的list中的块，会在没有清除 ITL 中lck标记的情况下写入到磁盘的datafile中，这部分块在下次再访问时，会做一次delay block cleanout，而刷新block块中的三 处SCN的值。

--//另外的情况就是数据块已经不再缓存了。这样在下次访问做delay block cleanout。我测试使用这个方法。

SCOTT@book> update deptx set dname=lower(dname) where deptno=20;

1 row updated.

SCOTT@book> alter system flush buffer_cache ;

System altered.

--//相应数据块已经不再缓存。

$ $ORACLE_HOME/bin/bbed parfile=bbed.par cmdfile=scn.cmd

BBED> p dba 4,547  kcbh.bas_kcbh ub4 bas_kcbh                                @8        0x427a5f4a

BBED> p dba 4,547  ktbbh.ktbbhcsc.kscnbas

ub4 kscnbas                                 @28       0x427a5506

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitflg

ub2 ktbitflg                                @60       0x8000 (KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitbas

ub4 ktbitbas                                @64       0x427a5506

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitflg

ub2 ktbitflg                                @84       0x2001 (KTBFUPB)

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitbas

ub4 ktbitbas                                @88       0x427a5b92

BBED> p dba 4,547  ktbbh.ktbbhitl[2].ktbitflg

ub2 ktbitflg                                @108      0x0001 (NONE)

BBED> p dba 4,547  ktbbh.ktbbhitl[2].ktbitbas

ub4 ktbitbas                                @112      0x00000000

--// 注意看第3个ITL槽。现在提交：

SCOTT@book> commit ; Commit complete.

SCOTT@book> alter system flush buffer_cache ;

System altered.

--//如果现在使用bbed查看，查询结果同上，没有变化，因为数据块已经不再缓存，仅仅在下次访问时才会更新，这个就是

--//delay block cleanout.

SCOTT@book> select ora_rowscn,deptx.* from deptx where rownum=1;

  ORA_ROWSCN       DEPTNO DNAME          LOC ------------ ------------ -------------- ------------- 14000218294           10 accounting     NEW YORK

select 14000218294,trunc(14000218294/power(2,32)) scn_wrap,mod(14000218294,power(2,32))  scn_base from dual

14000218294     SCN_WRAP     SCN_BASE SCN_WRAP16 SCN_BASE16 ------------ ------------ ------------ ---------- ---------- 14000218294            3   1115316406          3   427a60b6

SYS@book> alter system checkpoint ;

System altered.

SYS@book> alter system checkpoint ;

System altered.

SYS@book> alter system checkpoint ;

System altered.

BBED> p dba 4,547  kcbh.bas_kcbh ub4 bas_kcbh                                @8        0x427a6161

BBED> p dba 4,547  ktbbh.ktbbhcsc.kscnbas

ub4 kscnbas                                 @28       0x427a6161

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitflg

ub2 ktbitflg                                @60       0x8000 (KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitbas

ub4 ktbitbas                                @64       0x427a5506

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitflg

ub2 ktbitflg                                @84       0x8000 (KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitbas

ub4 ktbitbas                                @88       0x427a5b92

BBED> p dba 4,547  ktbbh.ktbbhitl[2].ktbitflg

ub2 ktbitflg                                @108      0x8000 (KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[2].ktbitbas

ub4 ktbitbas                                @112      0x427a60b6 --//注意看第3个ITL槽。ktbbh.ktbbhitl[2].ktbitflg=0x8000也就是提交。ktbbh.ktbbhitl[2].ktbitbas=0x427a60b6,再次证明ora_rowscn来源ITL槽。 --//这个时候的kcbh.bas_kcbh=ktbbh.ktbbhcsc.kscnbas=等于访问块时的scn。同时kcbh.bas_kcbh也更新了。

BBED> p dba 4,547 ktbbh.ktbbhitl[2]

struct ktbbhitl[2], 24 bytes                @92    struct ktbitxid, 8 bytes                 @92       ub2 kxidusn                           @92       0x0009       ub2 kxidslt                           @94       0x0001       ub4 kxidsqn                           @96       0x00000a62    struct ktbituba, 8 bytes                 @100       ub4 kubadba                           @100      0x00c001c7       ub2 kubaseq                           @104      0x039b       ub1 kubarec                           @106      0x1f    ub2 ktbitflg                             @108      0x8000 (KTBFCOM)    union _ktbitun, 2 bytes                  @110       sb2 _ktbitfsc                         @110      3       ub2 _ktbitwrp                         @110      0x0003    ub4 ktbitbas                             @112      0x427a60b6

BBED> x /rncc *kdbr[1]

rowdata[44]                                 @8140 ----------- flag@8140: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@8141: 0x00 cols@8142:    3

col    0[2] @8143: 20

col    1[8] @8146: research col    2[6] @8155: DALLAS

--//lock的表示也清除了。

5.这里就产生一种非常特殊的情况，假设很久不访问这个块。

--//这样就产生一个control scn。

--//当访问块时，oracle通过ITL槽查询事务的scn相关信息，因为时间久远，undo的事务槽已经被覆盖，这样scn只能取undo header中能

--//确定的提交的最小的SCN。也就是control scn。

control scn 存在于undo segment header中，这个SCN 是最近一个被重用的事务槽的SCN，事务槽的重用是按事务的先后顺序重用的。也

就是这个scn是目前在这个undo header中能确定的提交的最小的SCN。

如果现在有一个事务，发生的大量的更新和commit,导致其相应的transaction table slot被重用，切其对应的uba前镜像也被重用，这时

，如果再有一个事务查询前面事务更新的数据块时，会用查询时的SCN(snapshot scn) ，根据ITL上xid找到transaction table 相应的 slot，由于相应的slot已经覆盖，无法获得slot的SCN，和查询时的SCN相比较，这时就去和control scn比较，因为control scn是目前这 个segment上能确认的提交的最小的SCN,如果这时snapshot scn还是小于这个control scn, 则直接 给也ORA-1555的错误，因为oracle 实 在无法构造能一致读的数据块了。如果这时snapshot scn大于control scn，则直接使用这个数据块，因为snapshot scn肯定也大于事务 提交时的SCN。因为control scn 肯定大于之前事务提交时的SCN。

--//实际上这个时候就使用control scn作为事务scn写入块中。一般要演示这个情况是通过建立小的undo表空间不扩展，执行一些事务覆

--//盖undo的事务槽。然后访问块。

--//做1个特殊测试。

SCOTT@book> update deptx set dname=lower(dname) where deptno=30; 1 row updated.

SYS@book> alter system checkpoint ;

System altered.

SYS@book> alter system flush buffer_cache;

System altered.

SCOTT@book> commit ;

Commit complete.

SYS@book> alter tablespace users read only ;

Tablespace altered.

--//先update，然后将脏块写盘，提交(因为数据块已经不再缓存)，执行是delay block cleanout。然后设置users表空间只读。

--//这样在访问数据块无法修改它。

$ORACLE_HOME/bin/bbed parfile=bbed.par cmdfile=scn.cmd

BBED> p dba 4,547  kcbh.bas_kcbh

ub4 bas_kcbh                                @8        0x427a73fb

BBED> p dba 4,547  ktbbh.ktbbhcsc.kscnbas

ub4 kscnbas                                 @28       0x427a6161

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitflg

ub2 ktbitflg                                @60       0x0001 (NONE)

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitbas

ub4 ktbitbas                                @64       0x00000000

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitflg

ub2 ktbitflg                                @84       0x8000 (KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitbas

ub4 ktbitbas                                @88       0x427a5b92

BBED> p dba 4,547  ktbbh.ktbbhitl[2].ktbitflg

ub2 ktbitflg                                @108      0x8000 (KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[2].ktbitbas

ub4 ktbitbas                                @112      0x427a60b6

--//这样即使访问数据块也无法更新块scn，看看情况。

COTT@book> select ora_rowscn,deptx.* from deptx where rownum=1;   ORA_ROWSCN       DEPTNO DNAME          LOC ------------ ------------ -------------- ------------- 14000223271           10 accounting     NEW YORK

--//重启数据库，可以发现访问ora_rowscn发生变化。

SYS@book> select ora_rowscn,deptx.* from scott.deptx where rownum=1;

  ORA_ROWSCN       DEPTNO DNAME          LOC ------------ ------------ -------------- ------------- 14000223295           10 accounting     NEW YORK

--//等1段时间。

SYS@book> select ora_rowscn,deptx.* from scott.deptx where rownum=1;   ORA_ROWSCN       DEPTNO DNAME          LOC ------------ ------------ -------------- ------------- 14000223368           10 accounting     NEW YORK   --//实际上每次重启，执行如上语句ORA_ROWSCN都会变化，因为无法写入数据文件。

BBED> p dba 4,547 ktbbh.ktbbhitl[0]

struct ktbbhitl[0], 24 bytes                @44    struct ktbitxid, 8 bytes                 @44       ub2 kxidusn                           @44       0x000a       ub2 kxidslt                           @46       0x0005       ub4 kxidsqn                           @48       0x00004e3e    struct ktbituba, 8 bytes                 @52       ub4 kubadba                           @52       0x00c003b0       ub2 kubaseq                           @56       0x0f4c       ub1 kubarec                           @58       0x06    ub2 ktbitflg                             @60       0x0001 (NONE)    union _ktbitun, 2 bytes                  @62       sb2 _ktbitfsc                         @62       0       ub2 _ktbitwrp                         @62       0x0000    ub4 ktbitbas                             @64       0x00000000

--//ktbbh.ktbbhitl[0].kxidusn=0x000a

SYS@book> select * from v$rollname where usn=10;

         USN NAME ------------ ------------------------------           10 _SYSSMU10_1197734989$

SYS@book> select ora_rowscn,deptx.* from scott.deptx where rownum=1;

  ORA_ROWSCN       DEPTNO DNAME          LOC ------------ ------------ -------------- ------------- 14000223536           10 accounting     NEW YORK

select 14000223536,trunc(14000223536/power(2,32)) scn_wrap,mod(14000223536,power(2,32))  scn_base from dual

14000223536     SCN_WRAP     SCN_BASE SCN_WRAP16 SCN_BASE16 ------------ ------------ ------------ ---------- ---------- 14000223536            3   1115321648          3   427a7530   SYS@book> ALTER SYSTEM DUMP UNDO HEADER '_SYSSMU10_1197734989$'; System altered.

********************************************************************************

Undo Segment:  _SYSSMU10_1197734989$ (10) ********************************************************************************   Extent Control Header   -----------------------------------------------------------------   Extent Header:: spare1: 0      spare2: 0      #extents: 4      #blocks: 271                   last map  0x00000000  #maps: 0      offset: 4080       Highwater::  0x00c003b3  ext#: 2      blk#: 51     ext size: 128   #blocks in seg. hdr's freelists: 0   #blocks below: 0   mapblk  0x00000000  offset: 2                    Unlocked      Map Header:: next  0x00000000  #extents: 4    obj#: 0      flag: 0x40000000   Extent Map   -----------------------------------------------------------------    0x00c00111  length: 7    0x00c00118  length: 8    0x00c00380  length: 128    0x00c00300  length: 128

Retention Table

  ----------------------------------------------------------- Extent Number:0  Commit Time: 1492592449 Extent Number:1  Commit Time: 1492592449 Extent Number:2  Commit Time: 1492592449 Extent Number:3  Commit Time: 1492592449

  TRN CTL:: seq: 0x0f4c chd: 0x0004 ctl: 0x0001 inc: 0x00000000 nfb: 0x0002

            mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)             uba: 0x00c003b2.0f4c.03 scn: 0x0003.427a7530                                     ~~~~~~~~~~~~~~~~~~~~ Version: 0x01   FREE BLOCK POOL::     uba: 0x00c003b2.0f4c.04 ext: 0x2  spc: 0x1e2a     uba: 0x00c003b3.0f4c.06 ext: 0x2  spc: 0x1d4e     uba: 0x00000000.0f4c.19 ext: 0x2  spc: 0xc78     uba: 0x00000000.0d09.38 ext: 0x2  spc: 0x64e     uba: 0x00000000.0000.00 ext: 0x0  spc: 0x0

--//注意看下划线部分，这里就是TRN CTL scn。等明天上班再看看。

SYS@book> select ora_rowscn,deptx.* from scott.deptx where rownum=1;

  ORA_ROWSCN       DEPTNO DNAME          LOC ------------ ------------ -------------- ------------- 14000293669           10 accounting     NEW YORK

select 14000293669,trunc(14000293669/power(2,32)) scn_wrap,mod(14000293669,power(2,32))  scn_base from dual

14000293669     SCN_WRAP     SCN_BASE SCN_WRAP16 SCN_BASE16 ------------ ------------ ------------ ---------- ---------- 14000293669            3   1115391781          3   427b8725

SYS@book> ALTER SYSTEM DUMP UNDO HEADER '_SYSSMU10_1197734989$';

System altered.

********************************************************************************

Undo Segment:  _SYSSMU10_1197734989$ (10) ********************************************************************************   Extent Control Header   -----------------------------------------------------------------   Extent Header:: spare1: 0      spare2: 0      #extents: 4      #blocks: 271                   last map  0x00000000  #maps: 0      offset: 4080       Highwater::  0x00c001b5  ext#: 2      blk#: 53     ext size: 128   #blocks in seg. hdr's freelists: 0   #blocks below: 0   mapblk  0x00000000  offset: 2                    Unlocked      Map Header:: next  0x00000000  #extents: 4    obj#: 0      flag: 0x40000000   Extent Map   -----------------------------------------------------------------    0x00c00111  length: 7    0x00c00118  length: 8    0x00c00180  length: 128    0x00c00300  length: 128

Retention Table

  ----------------------------------------------------------- Extent Number:0  Commit Time: 1492646424 Extent Number:1  Commit Time: 1492646424 Extent Number:2  Commit Time: 1492646424 Extent Number:3  Commit Time: 1492646424

  TRN CTL:: seq: 0x0f64 chd: 0x0009 ctl: 0x0019 inc: 0x00000000 nfb: 0x0001

            mgc: 0xb000 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)             uba: 0x00c001b4.0f64.2e scn: 0x0003.427b8725                                     ~~~~~~~~~~~~~~~~~~~~

--//注意看下划线部分，这里就是TRN CTL scn。因为无法写入，覆盖了就发生变化。

SYS@book> alter tablespace users read write ;

Tablespace altered.

SYS@book> select ora_rowscn,deptx.* from scott.deptx where rownum=1;

  ORA_ROWSCN       DEPTNO DNAME          LOC ------------ ------------ -------------- ------------- 14000294979           10 accounting     NEW YORK

select 14000294979,trunc(14000294979/power(2,32)) scn_wrap,mod(14000294979,power(2,32))  scn_base from dual

14000294979     SCN_WRAP     SCN_BASE SCN_WRAP16 SCN_BASE16 ------------ ------------ ------------ ---------- ---------- 14000294979            3   1115393091          3   427b8c43

SYS@book> alter system flush buffer_cache;

System altered.

$ $ORACLE_HOME/bin/bbed parfile=bbed.par cmdfile=scn.cmd

BBED> p dba 4,547  kcbh.bas_kcbh

ub4 bas_kcbh                                @8        0x427b913d

BBED> p dba 4,547  ktbbh.ktbbhcsc.kscnbas

ub4 kscnbas                                 @28       0x427b913d

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitflg

ub2 ktbitflg                                @60       0xa000 (KTBFUPB, KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[0].ktbitbas

ub4 ktbitbas                                @64       0x427b8c43 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitflg ub2 ktbitflg                                @84       0x8000 (KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[1].ktbitbas

ub4 ktbitbas                                @88       0x427a5b92

BBED> p dba 4,547  ktbbh.ktbbhitl[2].ktbitflg

ub2 ktbitflg                                @108      0x8000 (KTBFCOM)

BBED> p dba 4,547  ktbbh.ktbbhitl[2].ktbitbas

ub4 ktbitbas                                @112      0x427a60b6

--// 注意看下划线,ktbbh.ktbbhitl[0].ktbitbas更新了= undo 头 的control scn。kcbh.bas_kcbh=ktbbh.ktbbhcsc.kscnbas= 访问块是的scn。

--// ktbbh.ktbbhitl[0].ktbitflg = 0xa000. 对应的就是 --// C-U- = Block cleaned by delayed block cleanout, and rollback segment info is overwritten.

SYS@book> alter system dump datafile 4 block 547 ;

System altered.

Block header dump:  0x01000223

Object id on Block? Y seg/obj: 0x1613e  csc: 0x03.427b913d  itc: 3  flg: E  typ: 1 - DATA      brn: 0  bdba: 0x1000220 ver: 0x01 opc: 0      inc: 0  exflg: 0

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc

0x01   0x000a.005.00004e3e  0x00c003b0.0f4c.06  C-U-    0  scn 0x0003.427b8c43 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0x02   0x000a.00c.00004e37  0x00c00339.0f49.24  C---    0  scn 0x0003.427a5b92 0x03   0x0009.001.00000a62  0x00c001c7.039b.1f  C---    0  scn 0x0003.427a60b6 bdba: 0x01000223