【IT168 技术文档】 我们知道，事务在对数据块中的记录加锁时，需要首先在数据块头部记录下该事务的相关信息，这样一个记录就是一条ITL槽(slot)。ITL TX等待发生在事务请求对数据块中记录加锁时，数据块上没有足够ITL槽。

　　导致发生ITL不足的原因有3种：

　　INITRANS太小，没有保留足够的ITL空间，当数据块被数据记录占满(或接近满)后，数据块上没有足够空间创建新的ITL槽位(尽管数据块上ITL数量没有达到MAXTRANS的限制)，这时，新的事务向其申请加锁时，就会发生ITL争用等待。

　　注：尽管有PCTFREE为数据块预留了空间，但是，UPDATE操作可能会将其占用，导致空间不足。

　　注2：INITRANS不足的问题不会出现在索引数据块上，当发现没有足够空间分配ITL slot时，无论是枝点块还是叶子块，数据块会发生分裂(Index Block Split)。

　　MAXTRANS不足。当受到MAXTRANS限制时，也会发生此类等待。MAXTRANS的默认值是255(10g以后则不能修改这一参数)，但是其实际大小是受到块的大小的限制的。ITL Slot占用的空间不会超过块大小的50%(实际上，如数据块为2K，则ITL最多为41，4k数据块的ITL最大数为83,8K数据块则为169)。

　　索引块上的递归事务的ITL slot争用。这一类等待比较特殊。在索引的枝节点上，有且只有一个ITL slot，它是用于当发生节点分裂的递归事务(Recursive Transaction)。在叶子节点上，第一条ITL Slot也是用于分裂的递归事务的。在一个用户事务中，如果发生多次分裂，每一次分裂都是由一个单独的递归事务控制的，如果下层节点分裂导致其父节点分裂，它们的分裂则由同一个递归事务控制。当2个事务同时需要分裂一个枝节点或者叶子节点时，或者枝节点下的2个子节点分别被2个事务分裂，就会造成这种ITL等待。

　　下面的代码模拟第一种情形导致的TX锁(继续使用之前的表进行演示)——表创建时，INITRANS默认值为1：

　　通过dump出数据块，可以看到数据块上空闲空间已经极少了：

　　仅够容纳1个ITL了(24字节)，加上数据块上原有了2条ITL slot，这个数据块上只能容纳最多3个事务：

　　等待队列分析

　　当发生ITL等待时，锁的请求模式是共享(4)模式，此时，通过V$ENQUEUE_LOCK就可以观察到TX锁等待：　

　　但是，除了ITL等待之外，还有其它几种等待也是共享模式，因此我们不能仅仅通过其请求模式来判断是ITL等。我们可以通过session event来鉴定这类等待队列，其对应的事件为“enq: TX - allocate ITL entry”：　　

　　这里有一点要注意，当请求模式为共享模式时，v$session中ROW_WAIT_*字段信息是并不准确，你可以将其作为参考，但是它可能并不是实际请求的对象。以ROW_WAIT_OBJ#为例，它可能为持锁会话中最后一次加锁的对象(如上例，为T_TEST5，并非真正导致等待的对象TX_LOCK_TAB)，大多数情况下其值为-1或0。

　　和记录锁不同，ITL等待可能发生在表上，也可能发生在索引上。要精确定位导致发生这一等待事件的对象，分析过程就相对复杂一些。

　　首先，通过被阻塞事务的请求锁的ID1、ID2找到事务的回滚段信息：

　　被阻塞事务使用到UNDO数据块为文件2上4197，UNDO开始记录为1，且只用到一个回滚块。我们将该UNDO块dump出来：

　　找到对应的回滚记录。可以看到，从第1(0x1)条记录开始，slot为7(0x07)的记录有4条：

　　事务对象分别是T_TEST5(objn: 198062)、TX_LOCK_TAB_IDX(objn: 198176)和TX_LOCK_TAB(objn: 198074)，其中，对于索引TX_LOCK_TAB_IDX来说，一个UPDATE操作实际是是一个INSERT操作加DELETE操作，因此存在2条记录。那么，哪个才是导致ITL等待的对象呢?我们可以先找到被阻塞会话当前正在执行的语句(即被阻塞的语句)：　

　　可以看到，被阻塞事务正在执行对TX_LOCK_TAB的UPDATE操作，而T_TEST5与其没有任何关联(没主外键关系)，因而可以被排除。

　　我们先确认是不是索引数据块引起的。从UNDO记录中找到索引数据块地址(block=0x01415c05)，dump出来：　

　　可以看到，itc为4，且空闲空间(kdxcoavs)为684字节，不会造成ITL不足等待。此外，其第一条ITL Slot(分裂事务使用)没有被占用，说明不存在对该ITL slot的争用。用同样方法，可以确认另外一个索引块没有造成ITL等待。

　　然后，再次确认表的数据块。同样还是将其(bdba: 0x0141072a)dump出来：

　　可以发现itc为3，没有达到max trans的限制，但是其空闲空间只有0xd=13(avsp)，不足以容纳1条ITL slot(24字节)了，因此判定是表TX_LOCK_TAB的数据块上空间不足导致的ITL等待。

　　有一点要注意，只有当阻塞事务的ITL或者其ITL表之前事务的释放ITL空间时，被阻塞进程才能继续。例如，如果导致阻塞的事务在数据块中ITL序号为0x02，那么如果没有其它事务等待0x01事务的ITL的话，无论是0x01还是0x02的事务被释放，被阻塞的事务都能分配到释放的ITL空间，从而继续;而如果是0x03的事务被释放，被阻塞事务仍然被阻塞。如上例中，从v$transaction找到XID信息得知，导致阻塞的事务的ITL序号是0x01，而此时如果释放第二个事务。

　　注意：因为ITL空间分配后不会被回收，当这种情况发生时，并不会影响到之前的分析。

　　递归事务对ITL slot请求分配是在递归事务内部完成，因此因为递归事务的ITL等待出现的时间周期很短暂，我们通过性能视图观察到的这一类等待基本上是由于INITRANS或MAXTRANS引起的。大量ITL等待的出现会影响系统和应用的性能，我们可以通过以下查询观察到在哪个对象上发生ITL等待等待最多，并依此对相应的对象或应用进行调整：

　　死锁分析

　　当死锁事务中存在ITL等待时，我们可以按照以下思路进行分析。之前说过，ITL等待不是一个经常出现的事件，偶尔的导致的死锁问题我们或许可以忽略。但是如果经常出现由此导致的死锁就应该引起注意了。判断死锁等待是否涉及ITL等待，可以通过从Trace文件中找到关联会话的详细Trace部分，可以发现以下等待事件信息：　

　　然而，和v$session中ROW_WAIT_*字段一样，如果死锁中存在共享锁，那么trace文件中Rows waited on部分的信息可能并不正确。我们需要一个更加详细的deadlock trace来做深入分析。　

　　以下的代码模拟了Index的Maxtrans限制而导致死锁(为了减少事务量，我将模拟ITL等待的索引建立在块大小为2k的表空间上)：　

　　然后，我们对生成的TRACE文件进行深入分析。

　　首先看到死锁链：

　　被阻塞会话是311，发生死锁时正在运行的语句是：　

　　找到被阻塞的语句对于我们确定发生ITL等待的对象很重要。

　　阻塞会话是295，找到其事务地址：

　　其事务地址为1C7B729C，然后由此地址在Trace文件中找到这个事务下面的队列信息，其中TX队列(type: 39)是我们感兴趣的：　

　　可以看到，这里列出了事务所作用到的所有数据块。结合之前找到的被阻塞的语句，我们知道等待是发生在tx_test_itl或者其索引上。我们看下这些数据块分别是属于哪些对象：　

　　最终得知0x1401e0d是表tx_test_itl的数据块，0x3c00199是索引tx_test_itl_idx1的数据块，0x2402b88是索引tx_test_itl_idx2的数据块，这3个数据块是我们感兴趣的块。我们之前说过，数据块上的ITL slot被分配就不会被回收了，而索引数据块如果发生分裂也会继承原有数据块上ITL slot。因此我们可以通过将这3个数据块dump出来判断是哪个数据块上发生的ITL等待(按照先索引再表的顺序，因为索引只有达到最大限制和分裂事务ITL slot争用时才发生ITL等待，如果索引块这两个条件都没有满足，可以判断是表的数据块发生ITL等待)。最终，我们会发现是0x3c00199上达到ITL slot上限(2k数据块，上限为41)：

　　此外，还有一个思路：通过被阻塞事务的队列信息找到其TX队列中的加锁数据块：

　　可以看到，这2个数据块分别属于表T_TEST5和tx_test_itl，而被阻塞的语句是对tx_test_itl插入一条数据，而此时表中已经插入数据并产生了UNDO数据，说明表tx_test_itl上并没有发生等待，再比较阻塞事务中的数据块信息，可以判断ITL等待是发生在索引上面。

　　解决方法

　　系统中存在少量的ITL等待是正常的，只有当其对系统造成了影响(如awr report中，在top 5 events中发现该事件)，或者对应用造成了直接影响(如死锁，再如发现某一会话存在大量等待ITL)，我们才需要采取相应手段进行处理。针对导致ITL等待不同原因，我们要采取不同的手段来处理。

　　INITRANS不足

　　这种情况只会出现的表的数据块上，如我们上述的例子：数据块上的ITL数量并没有达到MAX TRANS的限制，可用空间小于24字节。发生这种情况的表通常会被经常UPDATE，从而造成预留空间(PCTFREE)被填满。如果我们发现这类ITL等待对系统已经造成影响，可以通过增加表的INITRANS或者PCTFREE来解决(视该表上的并发事务量而定，通常，如果并发量高，建议优先增加INITRANS，反之，则优先考虑增加PCTFREE)。

　　要注意的一点是，如果是使用ALTER TABLE的方式修改这2个参数的话，只会影响新的数据块，而不会改变已有数据的数据块——要做的这一点，需要将数据导出/导入、重建表。

　　MAXTRANS不足

　　这一情况是由高并发引起的：同一数据块上的事务量已经超出了其实际允许的ITL数(如前所述，ITL slot所占空间不能超过数据块大小的一半，如8K的限制为169)。因此，要解决这类问题就需要从应用着手，减少事务的并发量;长事务，在保证数据完整性的前提下，增加commit的频率，修改为短事务，减少资源占用事件。而对于OLAP系统来说(例如，其存在高并发量的数据录入模块)，可以考虑增大数据块大小。

　　递归事务ITL争用

　　这一类等待通常是系统存在并发事务频繁插入、修改数据导致，其往往伴随"enq: TX - index contention"事件出现。根本解决方法就是要减少索引分裂，如使用大数据块、减少索引中效率低、使用率低的字段等。