SQL> select dbms_rowid.rowid_relative_fno(rowid) file#,
dbms_rowid.rowid_block_number(rowid) block#,
dbms_rowid.rowid_row_number(rowid) row# from scn_test ;
FILE# BLOCK# ROW#
---------- ---------- ----------
6 31 0
6 31 1
SQL> select ora_rowscn,t.* from scn_test t ;
ORA_ROWSCN OBJECT_ID NAME
---------- ---------- ----------
5052657 1 synonym
5052657 2 view
-- dump 数据块
SQL> oradebug setmypid
Statement processed.
SQL> alter system dump datafile 6 block 31;
System altered.
SQL> oradebug tracefile_name
/sharevg/oracle/admin/thinking/udump/thinking_ora_11534376.trc
数据块本身有三处记录的相应的SCN：数据块头的SCN（block scn)、ktbbh结构下的 kscnbas,kscnwrp（cleanout scn)、ITL信息中的scn/fsc(commit scn 有时候会是control scn)
1.如下查看dump出的数据块：
-- block scn
*** 2013-06-23 21:44:15.119
*** ACTION NAME:() 2013-06-23 21:44:15.104
*** MODULE NAME:(sqlplus@node1svr (TNS V1-V3)) 2013-06-23 21:44:15.104
*** SERVICE NAME:(SYS$USERS) 2013-06-23 21:44:15.104
*** SESSION ID:(310.103) 2013-06-23 21:44:15.104
Start dump data blocks tsn: 9 file#: 6 minblk 31 maxblk 31
buffer tsn: 9 rdba: 0x0180001f (6/31)
scn: 0x0000.004d18f1 seq: 0x02 flg: 0x06 tail: 0x18f10602
frmt: 0x02 chkval: 0x9524 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
-- block scn (cache layer记录的block scn)
BBED> p kcbh
struct kcbh, 20 bytes @0
ub1 type_kcbh @0 0x06
ub1 frmt_kcbh @1 0xa2
ub1 spare1_kcbh @2 0x00
ub1 spare2_kcbh @3 0x00
ub4 rdba_kcbh @4 0x0180001f
ub4 bas_kcbh @8 0x004d18f1
ub2 wrp_kcbh @12 0x0000
-- cleanout scn (csc)
BBED> p ktbbh
struct ktbbh, 72 bytes @20
ub1 ktbbhtyp @20 0x01 (KDDBTDATA)
union ktbbhsid, 4 bytes @24
ub4 ktbbhsg1 @24 0x0000fe04
ub4 ktbbhod1 @24 0x0000fe04
struct ktbbhcsc, 8 bytes @28
ub4 kscnbas @28 0x004d18cf
ub2 kscnwrp @32 0x0000
-- ITL 部分的SCN(scn/fsc)
Block header dump: 0x0180001f
Object id on Block? Y
seg/obj: 0xfe04 csc: 0x00.4d18cf itc: 2 flg: E typ: 1 - DATA
brn: 0 bdba: 0x1800019 ver: 0x01 opc: 0
inc: 0 exflg: 0
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0005.019.000006a7 0x008007c8.04a4.34 C--- 0 scn 0x0000.004d1733
0x02 0x0002.01b.000005e5 0x008002eb.0312.06 --U- 1 fsc 0x0000.004d18f1
-- 显示为U，表示是up bound scn（undo header 中的control scn)
可见目前三者是相同的 4d18f1=5052657
block scn 记录的是block 最后一次改变时的SCN.一般情况下会等于ITL上最新的commit SCN（因为可能有delayed cleanout block发生）。
2. 什么时候发生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的值。
事务没有提交前，block scn是不会改变的，因为它只记录block改变时的SCN。
fast commit cleanout ：会将事务提交时的SCN作为commit scn，更新block 上itl 和undo segment header上transaction table 相应slot上的scn, 并修改block scn，这时候三个是一致的。
delayed block cleanout : 当发生时，已经commit的事务对应的undo segment header上transaction table 相应slot还没有被覆盖，可以在slot上找到确切的commit scn,用这个SCN更新block scn和ITL上的scn/fsc值 。如果slot已经被覆盖了，那么会用undo segment header中的control scn来做为commit scn更新ITL中的scn ，也就是所谓的upper bound scn. 同时更新block scn为 delayed block cleanout 发生时的SCN。
block header中的ITL信息有一列是flag，其不同值的含义如下 ：
—- = transaction is active, or committedpending cleanout
C— = transaction has been committed andlocks cleaned out
-B– = this undo record contains the undofor this ITL entry
–U- = transaction committed (maybe longago); SCN is an upper bound
—T = transaction was still active atblock cleanout SCN
3. 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。
—————————————————————————————————————
A ：下面对fast cleanout block 验证，commit时，会同时更新block_scn、itl scn、transaction table slot scn
1.执行如下过程：
SQL> ! cat csc_test.sql
select current_scn from v$database;
create table csc_test (id number) ;
select current_scn from v$database;
insert into csc_test values (1);
select current_scn from v$database;
commit;
select current_scn from v$database;
insert into csc_test values (2);
select current_scn from v$database;
commit;
select current_scn from v$database;
alter system checkpoint;
select current_scn from v$database;
SQL> @csc_test.sql
CURRENT_SCN
-----------
5622039
Table created.
CURRENT_SCN
-----------
5622055
1 row created.
CURRENT_SCN
-----------
5622059
Commit complete.
CURRENT_SCN
-----------
5622062
1 row created.
CURRENT_SCN
-----------
5622063
Commit complete.
CURRENT_SCN
-----------
5622066
System altered.
CURRENT_SCN
-----------
5622068
-- 可知最一个commit scn 肯定在5622063和5622066之间
-- dump 这个block:
SQL> select dbms_rowid.rowid_relative_fno(rowid) file#,
2 dbms_rowid.rowid_block_number(rowid) block# from csc_test;
FILE# BLOCK#
---------- ----------
6 150
6 150
SQL> conn / as sysdba
Connected.
SQL> oradebug setmypid
Statement processed.
SQL> alter system dump datafile 6 block 150;
System altered.
SQL> oradebug tracefile_name
/sharevg/oracle/admin/thinking/udump/thinking_ora_9175064.trc
-- 查看dump文件的 itl 信息：
*** SESSION ID:(308.2234) 2013-07-02 09:00:25.734
Start dump data blocks tsn: 9 file#: 6 minblk 150 maxblk 150
buffer tsn: 9 rdba: 0x01800096 (6/150)
scn: 0x0000.0055c930 seq: 0x02 flg: 0x06 tail: 0xc9300602 --- 块SCN(0x0000.0055c930)
frmt: 0x02 chkval: 0x34dc type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00000001103DA000 to 0x00000001103DC000
………………
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x0001.02c.00000718 0x00800685.0412.05 --U- 1 fsc 0x0000.0055c92c
0x02 0x0008.02e.0000080b 0x00800f7f.0497.2e --U- 1 fsc 0x0000.0055c930
data_block_dump,data header at 0x1103da064
-- BBED查看 块150上的ITL信息：
BBED> set dba 6,150
DBA 0x01800096 (25165974 6,150)
BBED> p kcbh
struct kcbh, 20 bytes @0
ub1 type_kcbh @0 0x06
ub1 frmt_kcbh @1 0xa2
ub1 spare1_kcbh @2 0x00
ub1 spare2_kcbh @3 0x00
ub4 rdba_kcbh @4 0x01800096
ub4 bas_kcbh @8 0x0055c930 -- 块scn (block scn)
ub2 wrp_kcbh @12 0x0000
ub1 seq_kcbh @14 0x02
ub1 flg_kcbh @15 0x06 (KCBHFDLC, KCBHFCKV)
ub2 chkval_kcbh @16 0x34dc
ub2 spare3_kcbh @18 0x0000
BBED> p ktbbh
struct ktbbh, 72 bytes @20
ub1 ktbbhtyp @20 0x01 (KDDBTDATA)
union ktbbhsid, 4 bytes @24
ub4 ktbbhsg1 @24 0x00010157
ub4 ktbbhod1 @24 0x00010157
struct ktbbhcsc, 8 bytes @28
ub4 kscnbas @28 0x0055c92a
ub2 kscnwrp @32 0x0000
b2 ktbbhict @36 2
ub1 ktbbhflg @38 0x32 (NONE)
ub1 ktbbhfsl @39 0x00
ub4 ktbbhfnx @40 0x01800091
struct ktbbhitl[0], 24 bytes @44
struct ktbitxid, 8 bytes @44
ub2 kxidusn @44 0x0001
ub2 kxidslt @46 0x002c
ub4 kxidsqn @48 0x00000718
struct ktbituba, 8 bytes @52
ub4 kubadba @52 0x00800685
ub2 kubaseq @56 0x0412
ub1 kubarec @58 0x05
ub2 ktbitflg @60 0x2001 (KTBFUPB)
union _ktbitun, 2 bytes @62
b2 _ktbitfsc @62 0
ub2 _ktbitwrp @62 0x0000
ub4 ktbitbas @64 0x0055c92c -- 第一次commit scn
struct ktbbhitl[1], 24 bytes @68
struct ktbitxid, 8 bytes @68
ub2 kxidusn @68 0x0008
ub2 kxidslt @70 0x002e
ub4 kxidsqn @72 0x0000080b
struct ktbituba, 8 bytes @76
ub4 kubadba @76 0x00800f7f
ub2 kubaseq @80 0x0497
ub1 kubarec @82 0x2e
ub2 ktbitflg @84 0x2001 (KTBFUPB)
union _ktbitun, 2 bytes @86
b2 _ktbitfsc @86 0
ub2 _ktbitwrp @86 0x0000
ub4 ktbitbas @88 0x0055c930 -- 第二次commit scn
-- 可知最后一次的commit 时的scn是0x0055c930 和上面dump 的block scn一致
-- 由上面可知最一次insert 发生的undo segment 在 8号段上，下面dump undo header,查看slot scn:
SQL> oradebug setmypid
Statement processed.
SQL> alter system dump undo header '_SYSSMU8$';
System altered.
SQL> oradebug tracefile_name
/sharevg/oracle/admin/thinking/udump/thinking_ora_9502842.trc
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
node1svr:/home/oracle/$> more /sharevg/oracle/admin/thinking/udump/thinking_ora_9502842.trc
/sharevg/oracle/admin/thinking/udump/thinking_ora_9502842.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /sharevg/oracle/10.2.0
System name: AIX
Node name: node1svr
Release: 1
Version: 6
Machine: 00F74A764C00
Instance name: thinking
Redo thread mounted by this instance: 1
Oracle process number: 26
Unix process pid: 9502842, image: oracle@node1svr (TNS V1-V3)
*** 2013-07-02 09:04:56.411
*** ACTION NAME:() 2013-07-02 09:04:56.403
*** MODULE NAME:(sqlplus@node1svr (TNS V1-V3)) 2013-07-02 09:04:56.403
*** SERVICE NAME:(SYS$USERS) 2013-07-02 09:04:56.403
*** SESSION ID:(324.160) 2013-07-02 09:04:56.403
********************************************************************************
Undo Segment: _SYSSMU8$ (8)
********************************************************************************
Extent Control Header
-----------------------------------------------------------------
Extent Header:: spare1: 0 spare2: 0 #extents: 3 #blocks: 143
last map 0x00000000 #maps: 0 offset: 4080
Highwater:: 0x00800f80 ext#: 2 blk#: 119 ext size: 128
#blocks in seg. hdr's freelists: 0
#blocks below: 0
mapblk 0x00000000 offset: 2
Unlocked
Map Header:: next 0x00000000 #extents: 3 obj#: 0 flag: 0x40000000
Extent Map
-----------------------------------------------------------------
0x0080007a length: 7
0x008000a1 length: 8
0x00800f09 length: 128
Retention Table
-----------------------------------------------------------
Extent Number:0 Commit Time: 1372687265
Extent Number:1 Commit Time: 1372687301
Extent Number:2 Commit Time: 1372687301
TRN CTL:: seq: 0x0497 chd: 0x001e ctl: 0x0019 inc: 0x00000000 nfb: 0x0002
mgc: 0x8201 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe)
uba: 0x00800f80.0497.1c scn: 0x0000.0055c2d7
Version: 0x01
FREE BLOCK POOL::
uba: 0x00000000.0497.1b ext: 0x2 spc: 0x1d4
uba: 0x00800f78.0497.02 ext: 0x2 spc: 0x1f06
uba: 0x00800f7d.0497.03 ext: 0x2 spc: 0x1c54
uba: 0x00000000.047d.01 ext: 0x2 spc: 0x1f88
uba: 0x00000000.0261.01 ext: 0x2 spc: 0x1f88
TRN TBL::
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt
------------------------------------------------------------------------------------------------
0x00 9 0x00 0x080d 0x0003 0x0000.0055c453 0x00800f7e 0x0000.000.00000000 0x00000001 0x00000000 1372724079
0x01 9 0x00 0x080e 0x0016 0x0000.0055c9fd 0x00800f80 0x0000.000.00000000 0x00000001 0x00000000 1372726838
0x02 9 0x00 0x080d 0x0026 0x0000.0055c4fa 0x00800f7e 0x0000.000.00000000 0x00000001 0x00000000 1372724466
…………………………
-- 找到2e的slot: scn同样为 55c930
0x2e 9 0x00 0x080b 0x002b 0x0000.0055c930 0x00800f7f 0x0000.000.00000000 0x00000001 0x00000000 1372726649
由上面过程可知 commit 时，若发生fast cleanout scn 这时：
block scn : scn: 0×0000.0055c930
itl scn : fsc 0×0000.0055c930
transaction tables slot scn :0×0000.0055c930
这三者是一致的。
– 说明：
FLAG – status of the txn
. If the cleanout was performed; that is, the block was modified: The block is flagged as containing delayed-logging cleanout (the flag KTBFUPB in ktbitflg indicates in this case a cleanout at commit time)
Flag – Transaction flag
—- = Uncommitted
-B– = The UBA (Undo Block Address) contains undo for this ITL
–U- = Committed by fast commits & delayed block cleanout has not occurred
—T = Transaction active at block cleanout SCN
-C-U- = Block cleaned by delayed block cleanout, and rollback segment info is overwritten.
必须使用块修改工具BBED来修改存在问题的数据块将ITL事务槽的FLAG从U修改为C(Commit)。
TRANSACTION_COMMITED = 0×08;
TRANSACTION_UPBOUND = 0×02;
TRANSACTION_ACTIVE = 0×01;
同时注意 OS的大，小端问题。
可能还会有 itl 的commit flag = 0xa的情况，这是发生delayed cleanout 时，oracle 认为这不是一个确切的commit scn，而是一个上限SCN，大与commit scn的上限，所以标记为0xa = 0×08 + 0×02 .
关于block scn，也可参阅
http://czmmiao.iteye.com/blog/2077043
参考至：http://www.dbaqhs.com/archives/1691
如有错误，欢迎指正
邮箱:czmcj@163.com
相关推荐
2. **定时 Checkpoint**：根据 `LOG_CHECKPOINT_TIMEOUT`、`LOG_CHECKPOINT_INTERVAL`、`fast_start_io_target` 和 `fast_start_mttr_target` 参数的设置，定时触发 Checkpoint。 3. **手动触发**：通过执行 `...
Oracle SCN（System Change Number）机制是Oracle数据库中用于追踪和管理数据变化的关键组件。SCN是一个不断递增的数字，确保了数据库能够准确地识别和处理事务中的数据修改，尤其是在故障恢复、Data Guard、Streams...
随机配置网络（SCN，Stochastic Configuration Network）是一种在机器学习领域中，特别是神经网络模型中的先进算法。它是 Extreme Learning Machine (ELM) 的一种扩展和优化版本，旨在解决ELM在实际应用中的一些限制...
### 个人经验总结：Oracle数据库SCN号详解 #### 一、引言 在Oracle数据库管理与维护过程中，了解SCN(System Change Number)的概念及其作用至关重要。SCN是Oracle数据库内部用于跟踪数据库状态变化的一个重要机制，...
"SCN"可能是这个压缩包中的一个特定库或功能的缩写，它专注于屏幕控制和用户交互。让我们深入探讨一下这个压缩包中可能涉及的知识点。 首先，"字符屏幕函数"是C语言中处理文本输出和输入的基础。在没有图形用户界面...
这可能包括图像处理、自然语言处理、推荐系统等，其灵活性和可扩展性是其主要优点之一。 文件"SCN_release_v1"很可能是整个项目的主版本，包含了实现SCN网络的基础代码和相关文件。在深入研究和利用这些代码之前，...
**SCN（System Change Number，系统变更号）**是Oracle数据库内部用于标识事务处理中的事件顺序以及确保数据一致性的关键机制之一。SCN是一种逻辑的时间戳，它用于排序数据库中发生的事件，以满足事务的ACID特性...
"SCN号的闪回"是Oracle数据库中一个重要的恢复机制，全称为System Change Number，它是Oracle数据库中记录事务更改的唯一序列号。SCN是一个不断增加的数字，每次数据库中的数据发生变化时，都会生成一个新的SCN，...
Oracle SCN（System Change Number）是Oracle数据库中的一个关键概念，它是数据库系统中记录所有更改的序列号，确保了数据的一致性和可恢复性。SCN是一个递增的数字，每次数据库发生事务性改变时，SCN都会增加。...
Oracle系统的System Change Number (SCN)是其内部用于记录数据库变化的关键组件，它是一个不断递增的数值，确保了数据库操作的顺序性和一致性。SCN的重要性在于，它不受操作系统时间的影响，避免了由于时间篡改导致...
- **控制文件中的SCN类型**：控制文件中包含多种类型的SCN，分别是system SCN、datafile SCN、last SCN以及start SCN。 - **system SCN**：表示整个数据库的状态，通常可以从`V$DATABASE`视图中的`CHECKPOINT_...
### SCN号与Oracle数据库恢复研究 #### 一、SCN与Checkpoint 在Oracle数据库中，SCN(System Change Number)是一个非常重要的概念，它用来标识数据库中的任何改变。SCN是Oracle内部使用的数字序列，每当数据库发生...
oracle scn修改工具，可以直接修改oracle scn，在极端情况下恢复使用，比如解决ORA-600 2662等类似错误,使用说明：https://www.xifenfei.com/2022/06/win-oracle-scn-patch.html
"迅浏览硬盘 scn2"是一款专门设计用于快速浏览硬盘上所有文件，包括隐藏文件位置的软件工具。在日常计算机操作中，我们往往需要查找特定的文件或文件夹，尤其是在大型硬盘或存储设备中，这个过程可能非常耗时。"迅...
Oracle 数据库在2019年 6月23日自动生效了新的SCN 生成的量由以前的16K 涨导 32K，但还是没有根本上解决问题，历史遗留问题还有可能发生，所以我们需要继续监控数据库 SCN 问题
Oracle数据库中的SCN（System Change Number，系统改变号）是Oracle系统内部维护的一种序列号，它随着系统更新自动增加，用于标记数据库中的每一个改变，保证数据的一致性和顺序恢复。SCN在数据库中无处不在，几乎...
ASIO4ALL_2_9_SCN 是一个针对声音处理的专业驱动程序，主要适用于音乐制作、音频编辑和专业音频系统。这个驱动程序的核心是ASIO（Audio Stream Input/Output），它是由Steinberg公司开发的低延迟音频接口标准。ASIO...
针对Oracle 在 2019年 6月23日后，新SCN 策略生效后，我们开始对数据库 Oracle scn 监控