首先介绍undo 中的简单结构：

undo entries包含的只有一个行改变的col值的undo，并不包含整个行的befor image。

1.读取数据块，如果该块在内存中，则增加一个克隆用于undo

2.读取行头：

3.检查lb是否这里有一个itl：

4.如果有，则读取这个itl的xid，xid=us#.slot#.wrap#

5.读取交易表，如果这个交易已经提交（state=9表示提交）并且有了一scn小于当前查询的system change number,

那么clean out这个块，继续下一个块（如果需要的话）并且返回第一步。（在每一个查询的时候都将产生一个查询

scn，在该scn一下的commit scn都认为对应的交易已经提交）

6.如果没有提交，那么读取最新改变的undo block根据transaction table中显示的dba（该地址为undo entries中最

新改变的块）

7.对比这个块的交易号同交易表中的交易号。如果在undo block中的交易号不等于交易表中的交易号，那么报告错误：

8.如果这个块的交易号等于交易表中的交易号，那么从这个undo entry的头开始，应用改变到块上（该块为在内存中

克隆的块）

9.如果这个undo enties的尾巴上有其他的块地址（因为一个交易可能占用了好几个undo块），那么将这个undo block

读到内存中重复分析第七步和第八步。重复7和8步直到首先的record不在包含其他块的地址。

10.当这里不再有前一个数据块的地址，那么这个交易就完全被undo了。（因为undo 块是从最后一个块往前读的，这

是为了保证在��读的时候，最新改变的数据都能在undo中体现）

11.如果这个undo entry包含：

a):包含一个指向前一个交易undo block的地址，读取这个交易的id号在这个前一个交易的undo block头里并读取相应

的交易表entries，返回第五步。record纪录也是从后往前读的，因此有irb指定先读取哪一个。

这个undo chain上还有一些undo 块。

后一个record。

这是因为，如果你查询的表有很多个交易在修改，那也需要读取这些所有的这些交易所涉及的undo block，应用到重做

b):如果包含一个ITL纪录，存储这个ITL record到数据块（cr block），然后返回第四步。

 还是关于consistent read。

a.create as select后增加一个表，然后确定当前存放数据的块20没有读到buffer中来：

b.起一个sqlplus 执行select，注意这个时候在buffer中有一个块缓存了：

c.在一个session中delete50行没有提交，这是产生一个block buffer：

d.在另外一个session中去执行select动作，有产生了一个block buffer

e.设想，c步骤和d步骤中的两个块在buffer中肯定不一样，因为在d步骤中产生的cr block肯定应用了

当前那个块的重做，但是结果是，这个两个块除了scn不相同，其他没有区别。原因是这两个块的copy都是来源于

最初的那个在block buffer中的block，因为前面的一个session删除操作没有提交，因此不需要用undo来产生一致性

读，如果我们并没有在实现select，即block没有事先放到buffer中，两个结果应该完全不同：

f.重新启动数据库，检查一下buffer中没有该块：

g.直接启动一个session开始删除操作：

该块被缓存在buffer中有两个块，状态一个为xcur，一个为cr。猜想：xcur为当前修改产生的块，一个为consistent

block，即为cr块。在该session中dump第20块：

我们看到dump出来的肯定是状态为xcur的块，因为这里有一个没有提交的tx。

h.我们开始一个新的session，然后dump这个块：

我们看到这两个块的dump完全一样的。在该session中我们执行一个select操作，然后dump该块，这时我们看到这里

多了一个cr块：

dump出来的文件看看：

我们看到scn比原来的大，但是ITL还是一样，然后对比一下这两个不同装载下块的dump，还是一样。

因此虽然我们看到了block buffer中有两个cr块，但是无论你从哪个session中去dump这个块，dump的永远是第���次产生

的cr块。oracle为后来的select产生的cr块，不可会dump出来。

i.我将那个session中的delete提交，因为如果不提交则其他的删除动作因为行被锁住而不能执行，然后执行了一个动作

这个时候cr减少了一个同时，dump出来的块已经到了delete被应用得块了，所以这个cr应该将原来最先的delete执行的

时候的那个cr去掉了，因为提交了一个交易在原始的块上，因此同时产生了一个新的cr块。否则如果所有的交易都不提交

那么cr块永远在增加。

另外对于最后的undo entries上是否有ITL存在，我没有模拟出环境，在原始block上有几个ITL但是，这些已经都是提交的

所以，并不是说上面有几个ITL就要回滚几个，而是根据当前块的scn去检查相应的ITL是否提交，如果小于当前的scn，这

些交易回滚又有什么用呢？

因此还是没有知道最后这个undo entries怎么来的ITL。

以下是这个undo block的头部。

今天终于让我找到了这个undo entries上包含的前一个itl的信息：

首先增加一张表，设置maxtrans=2；oracle默认的maxtrans=255，因为他只用两位来记录。

连续四次对该表进行操作在不同的交易中，导致该块上的itl被重复使用过：

第一次：

第二次：

第三次：

第四次：

如此，dump出最后的itl中指示的uba地址找到了undo entries中的recored：

第三次：

因此将这个itl应用到cr块上，接着找该地址就可以undo前一个itl，当前先要对比一下scn号，

到此，consistent reader的这个过程我已经都明白了，而且在实际中显示出来，你明白没有。

今天差点走入一个误区，我老板说，rbs header中的tx table中的chd和ctl就是记录的关于这个块所有的已经提交的交易。

当时我就表示了怀疑，怎么可能在这里记录，oracle也太傻了。这里当然记录了所有的commit的交易链，那只是说这

个是最老的交易，一个流水号，记录了整个交易链中的顺序，如果重用也是按照最老的开始使用。所以他和consistent

reader用到的undo是无关的。这里也就是biti所说的undo block中也记录了itl的before image。

上面就是transaction header的格式。

dsi原文：