查看一下session的明细信息。可以看到这个session都是来自同一个客户端。

       SID    SERIAL# USERNAME        OSUSER          MACHINE              PROCESS         TERMINAL        TYPE       LOGIN_TIME
---------- ---------- --------------- --------------- -------------------- --------------- --------------- ---------- -------------------
       5592      25063   APPC         pappwrk01         prod_client_db              1234            unknown         USER       2014-11-26 13:03:45
     11533      51179   APPC          pappwrk01        prod_client_db              1234            unknown         USER       2014-11-26 13:03:46

查看这个session正在执行的sql语句，发现都是对同一个表的update。语句类似
UPDATE DIRECT_DEBIT_REQUEST SET DIRECT_DEBIT_REQUEST.ACCOUNT_ID=..........

到这个地方，问题似乎很清晰了，就是由于表DIRECT_DEBIT_REQUEST的ITL的设置不能够满足并发事务的需求而导致的等待。数据块是oracle能够发出的最小I/O单位。在数据块中，数据块头部的ITL信息是至关重要的。
每当一个事务需要修改一个数据块时，需要在数据块头部获得一个可用的ITL槽，其中记录了当前事务的id，使用的undo数据块地址，还有对应的scn,事务是否提交等信息。如果一个新的事务发现ITL槽已经被使用，会重新
申请一个新的ITL槽，这个过程是动态的，进一步来说，ITL槽的设置是由ini_trans,max_trans来决定的，在10g之后，max_trans参数被忽略了。
SQL> create table trans_test(id number,name varchar2(100)) initrans 1 maxtrans 1;
Table created.

SQL> set linesize  100
SQL> col table_name format a30
SQL> select ini_trans,max_trans,table_name from user_tables where table_name='TRANS_TEST';
 INI_TRANS  MAX_TRANS TABLE_NAME
---------- ---------- ------------------------------
         1        255 TRANS_TEST
对于initrans,maxtrans的默认值，表级为1,索引级为2.  一般来说不需要做特别的设置。可以根据业务的需要来配置。
来继续回到awr报告。可以在"Segments by ITL Waits"里面得到一个全面的信息。

Owner	Tablespace Name	Object Name	Subobject Name	Obj. Type	ITL Waits	% of Capture
APPO	INDXH01	MST_LOG_1IX	I2	INDEX PARTITION	12	66.67
APPO	DATAS01	DIRECT_DEBIT_REQUEST		TABLE	3	16.67
APPO	INDXS01	PAYMENT_2IX	A23_B2	INDEX PARTITION	1	5.56
APPO	INDXH01	ACTIVITY_HISTORY_1IX	C90	INDEX PARTITION	1	5.56
SYS	SYSAUX	WRH$_SQL_PLAN_PK		INDEX	1	5.56

从上面的列表我们可以清晰的看到对于ITL wait的情况，可以说明两点。
首先是我们在发现问题的时候，可能有些操作已经结束了，我们分析的结果不一定是最全面的信息。就如我们上面所做的分析。定位到问题的是表DIRECT_DEBIT_REQUEST,其实在问题时间段内，一个大的分区索引占用了高达
67%左右的ITL wait。
其次是我们通过awr报告得到了一些详细的信息。但是还是不能够对问题做最终的结论，不能头痛医头，脚痛医脚，如果能够以点带面来排查问题，可能最后的效率要高很多。

对于这个等待事件，处理的思路在metalink上也给出了详尽的解释。可以参见
解决思路有3种

Increase INITRANS

A)

1) Depending on the number of transactions in the table we need to alter the value of INITRANS. here it has been changed to 50: