[20170419]关于块scn号.txt

[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

时间： 2024-08-22 16:00:33

[20170419]关于块scn号.txt的相关文章

[20150129]关于取scn号.txt

[20150129]关于取scn号.txt --SCN有称系统改变号或者系统提交号,在oracle占有重要的位置.可以讲scn无处不在. --取scn号一般使用查询dbms_flashback.get_system_change_number或者查询视图v$database的current_scn字段. --两种实际上还是有1点点小区别,通过例子来说明: SCOTT@test> @ver1 PORT_STRING                    VERSION        BANNER

[20151109]提升scn号11g测试.txt

[20151109]提升scn号11g测试.txt --以前的测试都在10g下进行的,在11.2.0.4下重复测试. 1.测试环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ------------------------------------------------------------

oracle中 SCN号总结 上篇

1.SCN(System Change Number) : SCN是什么? system change number (SCN)是一个非常重要的标记,Oracle使用它来标记数据库在过去时间内的状态和轨迹.Oracle使用SCN来保 存所有变化的轨迹.SCN是一个逻辑时钟来记录数据库事件.它非常的重要,并不是只是为了恢复.SCN的最大值是0xffff.ffffffff.SCN有点类似于sequence,Oracle 在SGA中增加它.当一个事务修改或者插入数据,Oracle首先写入一个新的SCN

[20170428]延迟块清除测试.txt

[20170428]延迟块清除测试.txt --//做一个延迟块清除测试,前面的测试太乱了,思路非常不清楚. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ------------------------------------------------------------------

[20170420]关于延迟块清除2.txt

[20170420]关于延迟块清除2.txt --昨天做延迟块清除测试时,有一个问题我自己一直没搞明白,就是把表空间设置为只读的情况下,当访问块时, --由于没法更新对应块,不知道为什么每次重启数据库,正常undo的事务槽不可能这么块覆盖,为什么ora_rowscn --总是变化,而且取的是control scn,要认真探究一下问题在那里. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BA

[20170420]关于延迟块清除3.txt

[20170420]关于延迟块清除3.txt --昨天做延迟块清除测试时,有一个问题我自己一直没搞明白,就是把表空间设置为只读的情况下,当访问块时, --由于没法更新对应块,不知道为什么每次重启数据库,正常undo的事务槽不可能这么块覆盖,为什么ora_rowscn --总是变化,而且取的是control scn,要认真探究一下问题在那里. --上午测试没有测试出来,链接http://blog.itpub.net/267265/viewspace-2137714/ => [20170420]关于

[20150515]关于块转储问题.txt

[20150515]关于块转储问题.txt --我自己在学习oracle有时候使用块转储时,发现转储的内容跟我自己的想象不一样. --正好前一阵子ITPUB有人也遇到类似的问题,自己做一个简单探究: 1.建立测试环境: SCOTT@test> @ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- -----------------------

[20150527]bbed与数据块检查和2.txt

[20150527]bbed与数据块检查和2.txt http://blog.itpub.net/267265/viewspace-1666781/ --我现在基本拿bbed学习,基本是拿bbed查看,而使用bvi修改数据.我感觉这种方便1写. --实际上使用bbed的好处就是修改数据块检查和不一致,而使用bbed修改很简单仅仅需要执行sum apply就ok了. --对比dbv与bbed确定检查和位置. --实际上既然检查和在16,17字节,只要清零,加上dbv就很容易确定要修改的内容. 1.

[20160406] 恢复until scn NNN.txt

[20160406] 恢复until scn NNN.txt --昨天别人问的问题,如果使用rman恢复,restore database until scn NNN;是恢复到NNN,还是NNN-1. --我个人的理解应该是NNN-1.包括像UNTIL SEQUENCE integer 以及UNTIL TIME xxx;也是少1个或者少1秒. --实际上我以前如果做测试,我自己总是查询误操作的scn,然后仅仅恢复到减去1的scn号.(感觉这样比较保险^_^) until prep.到...为止,