查看一下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:

2) Then re-organize the table using move (alter table <table_name> move;)

3) Then rebuild all the indexes of this table as below

 

Increase PCTFREE

If the issue is not resolved by increasing INITRANS then try increasing PCTFREE. Increasing PCTFREE holds more space back and so spreads the same number of rows over more blocks. This means that there are more ITL slots available overall :
B)

1) Spreading rows into more number of blocks will also helps to reduce this wait event.

2) Then re-organize the table using move (alter table service_T move;)

3) Rebuild index

 

A Combination of increasing both INITRANS and PCTFREE

1) Set INITRANS to 50  pct_free to 40

2) Re-organize the table using move (alter table <table_name> move;)

3) Then rebuild all the indexes of the table as below

                             
在这个基础上更近一步，我查找产品部的文档，发现在项目开始已经对initrans的设置做了建议，但是对于这个问题，不知道什么原因最后给漏掉了。这样下来需要对一些重要的表都需要做initrans的改动。本来从awr报告中得到的
的信息显示4个对象（表&索引）可能存在initrans设置不足的情况，如果结合项目的情况来看，需要做的变更可能就是上百个对象。需要好好评估。
以下的标准可以参考以下。
对于大表，数据千万级以上的表，initrans建议设置为8~16
对于中级表，数据量在百万到千万级，initrans建议设置为4~8
对于普通的表，initrans建议设置为1~4