enq:TX-index contention等待事件

此等待事件发生的版本从10.2到11.2,在任何平台都会出现
产生的原因：在OLTP RAC系统上，高并发应用下，与表相关的索引会发生很高的TX队列的争用。这通常在所有实例并发应用大量的INNSERT或DELETE操作。因为当插入新行到index块里索引块可能需要做splits动作。
事物将会有mode 4的TX lock，直到之前的session做完index block splits为止。

index block &&split的概念：
索引的数据块分为root block、branch block、leaf block
root block：是一个索引的入口
branch block：<spearator key,leaf dba>,通过此键值来查找B-TREE的 leaf block
leaf block：存放数据的索引块，实际数据存放在leaf block中，leaf blocks hold<index key,rowid>

index block split发生在一个新的记录需要插入到索引块中不能找到free space，那么会话将开始index block split。在开始split时，这个session将会尝试清空此block的keys来检查是否有足够的空间。
splieter会有如下大概操作：
分配新块
复制一定百分比的rows到新的buffer里。
添加新的buffer到索引结构并且提交操作。
索引分裂可能原因：
a、索引所在表的应用所给的压力较大
b、表所对应的索引不正常的正常，即在B-TREE的一边增长造成不平衡。

索引分裂类型：
leaf block split 细化为 leaf node 90-10splits和leaf node 50-50 splits
Branch Block 50-50Split
Root Block 50-50Split

--可通过此语句来查询其情况
SELECT Names.Name, Stats.Value, Stats.Statistic#
  FROM V$sesstat Stats, V$statname Names
 WHERE --stats.sid = (SELECT sid FROM v$mystat WHERE rownum = 1) AND
 Names.Statistic# = Stats.Statistic#
 AND Names.Name LIKE '%split%'
 ORDER BY Stats.Statistic#;
 
leaf node 90-10splits:插入到索引leaf block叶子块中的索引键是该块中最大的键值(包括块中已删除的索引键值)。在此种情况下实施90-10split，原叶子块仍保持99%的full，
而到另一个空的叶子块中插入该条新的最大键值记录。
leaf node 50-50splits:当插入到索引叶子块中的索引键值不是该块中的最大值时(包括块中已删除的索引键值)，将发生 50/50split分裂，这意味着有一半索引记录仍存在当前块，
而另一半数据移动到新的叶子块中。
Branch Block 50-50 Split  由于不断的索引叶块分裂需要将新的leaf block的信息加入到branch block中，当branch block没有足够空间容纳新的记录时，又会引发branch block的 Split。
branch block的split50-50的，即将一半记录移动到新的branch block中。
Root Block 50-50 Split    root block 根块实际是一种特殊的branch block, 当root block 50-50split分裂发生时将分配2个新的数据块， 分裂将一半的数据移动到一个新块中，另一半数据移动到另一个新块中。
并更新原来的root block，使之指向那2个新的数据块，实际上是2个branch block了


enq:TX-index contention等待事件案例如下
Top 5 Timed Foreground Events
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                           Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
enq: TX - index contention        1,263,737     179,494    142   29.9 Concurrenc===>在top1上
db file sequential read          29,316,282     132,125      5   22.0 User I/O
buffer busy waits                 2,255,337      87,767     39   14.6 Concurrenc
DB CPU                                           51,053           8.5
log file sync                     4,144,556      26,134      6    4.4 Commit

根、枝、叶的分裂情况较为严重
nstance Activity Stats             DB/Inst: STDDB/stddb1  Snaps: 51155-51156
-> Ordered by statistic name
Statistic                                     Total     per Second     per Trans
-------------------------------- ------------------ -------------- -------------
leaf node 90-10 splits                        9,182            5.1           0.0
leaf node splits                            332,103          183.2           0.1
branch node splits                            1,632            0.9           0.0
root node splits                                  3            0.0           0.0

相关segment的等待情况
Segments by Row Lock Waits          DB/Inst: STDDB/stddb1  Snaps: 51155-51156
-> % of Capture shows % of row lock waits for each top segment compared
-> with total row lock waits for all segments captured by the Snapshot
                                                                     Row
           Tablespace                      Subobject  Obj.          Lock    % of
Owner         Name    Object Name            Name     Type         Waits Capture
---------- ---------- -------------------- ---------- ----- ------------ -------
TRSEN      TS_IDX_YTE IDX4_E_TRSEN_DIG _2014_11_2 INDEX    1,115,929   75.76==>发生争用的索引
TRSEN      E_HIS_11 T_E_OP_RECORD_HAND 2014_11_17 TABLE       42,574    2.89
TRSEN      TS_IDX_YTE IDX04_T_E_EXT_IS            INDEX       27,442    1.86
TRSEN      TS_IDX_YTE IDX03_T_E_EXT_IS            INDEX       26,256    1.78
TRSEN      TS_TRSEN   T_SMS_SS_1_LOCKS                TABLE       24,796    1.68
          -------------------------------------------------------------

Segments by ITL Waits                DB/Inst: STDDB/stddb1  Snaps: 51155-51156
-> % of Capture shows % of ITL waits for each top segment compared
-> with total ITL waits for all segments captured by the Snapshot
           Tablespace                      Subobject  Obj.           ITL    % of
Owner         Name    Object Name            Name     Type         Waits Capture
---------- ---------- -------------------- ---------- ----- ------------ -------
TRSEN      TS_IDX_YTE IDX4_E_TRSEN_DIG _2014_11_2 INDEX        7,219   81.36==>伴随的ITLwaits信息
TRSEN      E_HIS_11 T_E_EXTREME_ISSUE_ 2014_11_14 TABLE        1,161   13.08
TRSEN      TS_IDX_YTE IDX_WK_BIZ_CONTAINER 2014_11_17 INDEX          147    1.66
TRSEN      TS_IDX_YTE IDX_T_E_WK_BIZ_SIG 2014_11_17 INDEX           81     .91
TRSEN      TS_IDX_YTE IDX_WK_BIZ_HANDON    2014_11_17 INDEX           49     .55
          -------------------------------------------------------------

Segments by Buffer Busy Waits        DB/Inst: STDDB/stddb1  Snaps: 51155-51156
-> % of Capture shows % of Buffer Busy Waits for each top segment compared
-> with total Buffer Busy Waits for all segments captured by the Snapshot
                                                                  Buffer
           Tablespace                      Subobject  Obj.          Busy    % of
Owner         Name    Object Name            Name     Type         Waits Capture
---------- ---------- -------------------- ---------- ----- ------------ -------
TRSEN      TS_IDX_YTE IDX4_E_TRSEN_DIG _2014_11_2 INDEX    1,986,465   83.67===>伴随的buffer busy waits信息
TRSEN      TS_IDX_YTE IDX04_T_E_EXT_IS            INDEX       45,572    1.92
TRSEN      STL_HIS_11 IDX1_STL_E_OPS_A   2014_11_17 INDEX       43,749    1.84
TRSEN      TS_IDX_YTE IDX03_T_E_EXT_IS            INDEX       42,478    1.79
TRSEN      TS_IDX_YTS IDX2_STL_E_OPS_A   2014_11_17 INDEX       40,138    1.69
          -------------------------------------------------------------
          
从上面的并发信息来看，由于应用压力很大加上索引非平衡split导致了enq:TX-index contention事件。虽然有enq: TX - allocate ITL等待，但是可通过buffer busy waits可确定是做split导致，因为在
做index split时，会写index数据到new buffer里，故有此等待的出现来佐证确实是索引分裂导致

解决方案：
1.将索引重新创建为反向索引，反向索引可能会导致不必要的问题，不建议使用
2.Hash（散列）分区索引
3.如果索引关键字是从序列（sequence）生成的，则增加序列的高速缓存大小，在应用程序支持时，使用“无序”序列
4.定期rebuild索引来减轻这样现象