直接看实验吧。

—–block dump

从上面block dump我们可以看到，有一个未提交事务：
0x02 0x000e.025.00000176 0x0240439e.015b.2f —- 1 fsc 0x0017.00000000

0x02： 表示第2个itl
0x000e.025.00000176 表示xid，xid的结构= 回滚段编号14+事务槽编号37+序号374
0x0240439e.015b.2f 表示UBA，uba的结构= undo block adress+Sequence + last enrty of undo block
=(file 9 block 17310)+347+47
Flag 表示该事务的状态，事务状态有如下几种：

——undo segment header dump

###### 提交该事务

此时trace信息如下：

—-undo segment header dump

事务提交以后，此时的scn：

block scn： 004310ae –> 4395182
itl scn： 0x0017.004310ae –>4395182
undo segment scn(事务表上slot scn)：0x0000.004310ae –>4395182

从上面的实验我们可以看出，当事务commit以后，oracle会更新如下3处SCN，且保证是一致的：

block scn,itl scn,undo segment header slot scn.

注意：
1. 上面的实验是针对fast commit cleanout的，我们知道block cleanout有2种方式，其中之一就是
fast commit cleanout，另外一种是延迟块清除，也就是delayed block cleanout。

2. 如果发生延迟块清除，那么在事务commit以后，不会去更新block scn和block 内itl scn，
而是仅仅更新undo segment header scn solt scn。

3. 针对block 里面scn和itl scn的更改，这里有涉及到slot重用的问题，这里有分为2种情况：

1)无slot重用时，发生延迟块清除,block内scn和itl scn是根据undo 段头事务表的信息来进行更新的。
2)当时发生slot重用时，block scn被更新为延迟块清除时刻的scn，block itl scn会更新为control scn。

##### 下面来看延迟块清除的情况

—–block dump

—-undo segment header dump

下面用mos提供的一个脚本来进行slot重用实验，进而观察block scn，itl scn和undo scn的变化。

此时我们来dump data block和undo segment header

— data block dump

—–undo header dump

我们可以看到，此时undo control scn的值是等于block scn和block itl scn的，进而也验证了前面的观点。