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索引來減輕這樣現象