http://blog.csdn.net/wh62592855/article/details/4619233

事务和数据块

这里主要想通过试验来推断Oracle的事务在数据块（Oracle中存储的最小单位）上一些微观操作，以便于更好的理解Oracle的事务控制、一致性处理及锁冲突。

      创建测试表：

首先，看一下数据块上和记录有关的标示，dump一个数据块看看：

看看Dump出来的内容：

注意红色黑体部分和Interested Transaction Slot (ITS) 部分。

CSC:即Cleanout SCN，最后一次对该数据块进行Cleanout的SCN。

Itc: Itl count。Itl的数量。看到下面的Itl列表中有两条记录，所以是2。

Itl：Interested Transaction List。直译过来就是感兴趣的事物列表。也就是对该数据块产生影响的事物。对应的数字是序列号。

Xid :Transaction ID。事务ID号。在相应回滚段的事物信息表中对应唯一一条记录。

Uba：Undo Block Address。回滚数据块地址，该地址对应了该事务在回滚段中记录的回滚数据的地址。

分解该地址：0x0080051a.059f.34

第一段是回滚数据块的地址，包括回滚段文件号和数据块号；第二段是回滚序列号；第三段是回滚记录号。

Flag：事务标志位。这个标志位就记录了这个事务的操作，各个标志的含义分别是：

C--- = transaction has been committed and locks cleaned out

-B-- = this undo record contains the undo for this ITL entry

--U- = transaction committed (maybe long ago); SCN is an upper bound
---T = transaction was still active at block cleanout SCN

Scn/Fsc：快速提交（Fast Commit Fsc）的SCN或者Commit SCN。

每条记录中的行级锁对应Itl条目lb，对应于Itl列表中的序号，即那个事务在该记录上产生的锁。

下面再看看回滚段中是如何记录的：

更新数据（数据更新前b=115）：

查看事务信息:

UBAFIL：回滚段文件号；

UBABLK：数据块号；

UBASQN：回滚序列号；

UBAREC：回滚记录号。

这些数据就对应了数据块中的Uba。

也可以通过以下方式从数据块的Uba中获取到回滚段这些信息：

0x02c00050.0376.10

0376即回滚序列号，10即回滚记录号。它们都是16进制。

下面获取文件号和数据块号：

Dump出数据块和回滚块：

数据块dump信息：

回滚块信息：

仔细比较一下两个dump文件，数据块的事务回滚信息就很清楚了：

在数据块中：

对象号是0xe46c，即十进制的58476；

Xid是0x000f.006.00000a14；

Uba是0x02c00050.0376.10。即11号文件的第80个数据块，回滚序列号是0x0376，回滚记录号是0x10。

回滚数据块中：

Xid是0x000f.006.00000a14，与数据块中Itl中的Xid对应；

seq: 0x376，与数据块的Uba中吻合；

cnt: 0x10，此回滚数据块中有16条回滚记录，根据Uba，我们要找的是第16条记录；

找到第16条回滚记录Rec #0x10：

slt: 0x06，即第6个slot。

objn和objd是58476，与数据块中的对象号相同；

tblspc是5，也就是对象t_multiver所在的表空间号；

Layer即层次，这是一次对记录的更新，所以是11 (Row)；

Undo type:  Regular undo    Begin trans，我们这个事务是刚开始时，在没有提交或回滚时dump出来的；

Temp Object:  No，这个对象不是临时对象。

在*-----------------------------以下的就是记录的旧数据镜像了：记录了它的Uba、最大控制Scn（ctl max scn）、上一次事务scn（prv tx scn）等信息，如果我们做了事务开始前的数据dump，就能一一找到对应关系了。最下面就是修改前的数据记录了。

      当一个事物访问一个数据块时，它会占用数据块Itl中的一个条目，记录下事务ID（Xid）、该事务对该数据块操作时使用的回滚块地址（Uba）和在该数据块上产生的行级锁的数量，并在对应数据行上打上行锁标志，与Itl对应。当提交时，设置Itl中的事物标志为U，并写入一个快速提交SCN（Fsc），但并不清除锁标志。这就是快速提交。

      看下面的一个试验。

      先对数据块进行修改，然后dump出数据块：

      看看dump出来的内容：

      可以看到，事务在Itl中记录下了Xid、Uba、Flag（U）、锁、Fsc；并且记录上的锁标志没有清除。

      从上面内容可以知道，事务在数据块上作的操作并没有清除产生的锁标志和其他标志（检测锁冲突），这些标志的清除需要留到下一个访问该数据块的事务去做清除。下一个访问到该数据块的事务会先检查自己要访问的数据行上有没有锁，如果都没有，就继续作自己的操作，如果记录上有锁，就做一次清除(Cleanout)。看下面的试验：

      这个试验是接着上面的，但是这修改的是数据块中的另外一条记录：

      看看dump出的数据块：

      这个事务并没有清除上一事务的锁标志，并且还产生了自己的锁标志，因为他们之间没有锁冲突。从这个试验，我们还可以得出以下结论：事务是按照数据块中的记录处理的，不是按照Itl中的条目处理的。

而块清除可以分为两种情况。一种是针对快速提交的。如果快速提交后，脏数据回写到磁盘上，此时数据块的锁标志还没有清除，后面访问该数据块的事务（只是产生数据更新的事务，不包括读事务），会先清除（Cleanout）上一个快速提交事务留下的锁标志（同时也是做锁判断），然后开始事务操作。看看试验：

      这里继续接着上面的试验，再对数据块做一次修改操作，并且修改的记录上已经有锁标志，看看后面事务是否清除了前面事务的标志：

      看看dump出的内容：

      可以看到，这个事务对前面的事务作了一次Cleanout，所有相关标志都被修改。

另一种情况是，事务开始后，会给数据块打上锁标志。但是事务标志和SCN号是在事务提交后写入的，如果在事务提交前，DBWn进程已经将数据回写到磁盘，那么数据块上就没有这些信息。后面访问该数据块的事务（包括所有读写事务）需要先根据Xid和Uba从回滚段的事务信息表中获取到这些信息，然后作一次Cleanout。再看试验：

事务提交前回写数据块：

看看数据块内容：

可以看到，Flag和scn没有被记录，而Xid、Uba和锁标志都已经被记录。这里还可以推断出：Xid和Uba在事务开始，获取到空闲Itl后是最先被记录的；锁标志是针对记录一一被记录的；Flag和Scn是事务提交后被记录的。

看看这种情况下，是如何做Cleanout的。我们这不再选用更新事务，而是做一个读操作：

看Dump内容：

可以看到，前面事务的标志都被Cleanout了。

如果事务一旦回滚，则会清除数据块上的所有标志，就不存在延迟块清除了。

还是看看试验吧，回更清楚一些。

先做更新操作，在提交/回滚前dump：

看看数据块上的变化：

注意到Xid、Uba和Lck标志已经被打上，但是Flag和SCN还没有。

然后回滚事务：

再看数据块内容：

所有锁标志被清除，Itl都已经被还原（这个测试是接着前面的进行的，可以对比前面dump出来的内容，发现Xid、Uba和Scn是一样的，所以说是“还原”）。

当一个读操作读到某一个数据块上，发现该数据块有被修改过的痕迹（事务标志、锁标志），会需要通过SCN来检查是读取当前数据还是修改前的数据，以保证读取到的所有数据都是读操作开始发生那一时刻（快照）的数据来保证数据的一致性。如果数据块上事务的SCN<读操作的SCN，说明数据块上的更改是发生在读操作之前的（所有SCN是唯一的，并且是累加的），就可以直接读取数据块上修改过的数据；否则，就需要从回滚段中读取修改前的数据，以保持数据的一致性。这就是一致性读。

下面是一个一致性读的例子：

从这个例子可以看到，读取操作只会读取读取查询开始时那一时刻的数据，如果数据在读取操作以后发生了变化，则从回滚段中读取老数据镜像。如果修改事务已经提交，并且在读取操作读到该数据块时，回滚段中的信息已经被覆盖，则会发生1555错误。我另外一篇文章介绍了1555错误，这就不再赘述了。