Oracle ITL（事务槽）

jinghefei

ITL描述：
ITL(Interested Transaction List)是Oracle数据块内部的一个组成部分，位于数据块头（block header），一个itl可以看作是一条事务记录。当然，如果这个事务已经提交，那么这个itl的位置就可以被反复使用了。如果这个事务已经提交，那么，itl槽位中还保存的有这个事务提交时候的SCN号。
ITL个数其最小值为1，由参数initrans控制（由于兼容性的原因，oracle会在对象的存储块分配两个itl，所以initrans的最小值实际上为2），最大值为255，由参数maxtrans控制，最大值参数在10g以后不能被修改，当块中还有一定的free space时，oracle可以使用free space构建itl供事务使用，如果没有了free space，那么，这个块因为不能分配新的itl，所以就可能发生itl等待。


dump一个块可以看到ITL信息类似如下：
     Itl           Xid                                    Uba                             Flag      Lck        Scn/Fsc
    0x01   0x0006.002.0000158e  0x0080104d.00a1.6e   --U-   734    fsc 0x0000.6c9deff0
    0x02   0x0000.000.00000000  0x00000000.0000.00  ----        0       fsc 0x0000.00000000
 
Xid：事务id，在回滚段事务表中有一条记录和这个事务对应
Uba：回滚段地址，该事务对应的回滚段地址
  第一段地址：回滚数据块的地址，包括回滚段文件号和数据块号
  第二段地址：回滚序列号
  第三段地址：回滚记录号
  SELECT UBAFIL 回滚段文件号,UBABLK 数据块号,UBASQN 回滚序列号,UBAREC 回滚记录号 FROM v$transaction --查看UBA
Flag：事务标志位。这个标志位就记录了这个事务的操作，各个标志的含义分别是：
----- = 事务是活动的，或者在块清除前提交事务
C--- = 事务已经提交并且清除了行锁定。
-B-- = this undo record contains the undo for this ITL entry
--U- = 事务已经提交（SCN已经是最大值），但是锁定还没有清除（快速清除）。
---T =当块清除的SCN被记录时，该事务仍然是活动的，块上如果有已经提交的事务，那么在clean ount的时候，块会被进行清除，但是这个块里面的事务不会被清除。
Lck：影响的记录数
Scn/Fsc：快速提交（Fast Commit Fsc）的SCN或者Commit SCN。
 
ITL重用后如何实现前ITL读一致性：
     ORACLE通过ITL条目中记录的回滚段地址找到回滚段,实现读一致性,如果事务已提交,ITL就可以被重用,但是若前一个ITL被重用，前一个ITL的读一致性是如何实现的呢？
     假定block只有一个itl，假定第一个事务的时候产生了 ITL-0 

     第二个事务来了，产生了 ITL-1 ,ITL-1 里面的UBA 可以找到回滚段地址，回滚段中除了记录了 block用户数据的 before image 外还记录了  ITL-0 的信息。

     第三个事务来了，产生了 ITL-2  , ITL-2 中 UBA 指向回滚段，回滚段中 也记录了 ITL-1 的信息。

     这样当一个查询若需要ITL-0时候的信息，则找到当前block，发现是 ITL-2 ,根据UBA找到回滚段进行 roll 得到  变化前 block ，这个时候发现block中是 ITL-1 . 还不能满足需求。 于是再根据 ITL-1 中的 UBA 又去回滚段中找到数据来进行roll，得到一个block 数据，这个时候block中就有了 ITL-0。
     通过根据当前ITL进行递归的方式找到数据，实现之前ITL的独一致性。


确定行是否被锁定：
　　当一个事务修改了很多个块，oracle采用只更新undo segment header的事务信息，而数据块头部的信息不更新，或者进行少量更新。可见，事务信息最具可信度的当属undo段头部的事务表了，它里面的事务信息最真实的反应了事务的状态。这也是为什么有时候select也会产生redo的原因。
　　    数据行被T1加锁，T2要修改数据行时，发现有锁定标志，就到ITL中找到T1，查看Flag，此时有两种情况：
　　    1）已提交：那么T2会把数据行的行头锁给削掉（通常锁是不会被及时清除的），这个行为会产生redo，然后再访问数据行。
　　    2）未提交：如果是未提交，T2就会怀疑了，是不是真的？因为他不相信T1,此时，他秉承“绝知此事要躬行”的良好态度，通过T1的xid找到undo段的段头的事务表，去看下事情的真实情况，此时也有两种情况：
　　      2.1）已提交：那么这下子T2就心死了，回来后，把T1的相关事务信息清空，并且，把行头的锁也给削掉，这个行为产生redo。
　　      2.2）未提交：那么T2就确定了该行确实上头有人啊...动不得哈,回来后，通过T1的xid找到回滚块，将剩余未提交的行和在回滚块中的行，重构一个CR块，然后直接读取CR块。
 
 
行锁原理：
Oracle的锁机制是一种轻量级的锁定机制，不是通过构建锁列表来进行数据的锁定管理，而是直接将锁作为数据块的属性，存储在数据块首部。这个是通过ITL来实现的，一个事务要修改块中的数据，必须获得该块中的一个itl(通过initrans预先分配的或者是通过free space构建的)。通过itl和undo segment header中的transaction table，可以知道事务处于活动阶段，还是已经完成。事务在修改块时（其实就是在修改行）会检查行中row header中的标志位，如果该标志位为0（该行没有被活动的事务锁住，这是可能要进行deferred block cleanout等工作），就把该标志位修改为事务在该块获得的itl的序号，这样当前事务就获得了对记录的锁定，然后就可以修改行数据了，这也就是oracle行锁实现的原理。
 
 
转自：http://blog.csdn.net/gybyylx/article/details/6893639
http://blog.csdn.net/linwaterbin/article/details/7819962