等待队列分析

　　当发生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等待等待最多，并依此对相应的对象或应用进行调整：