[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个很奇怪的情况，脏块并没有写盘，我一直不知道为什么?这也是我前面遇到的情况，链接
--//http://blog.itpub.net/267265/viewspace-2136017/ , 视乎这个问题出现在使用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
