enq: TX - index contention It s possible that we see high Index leaf block contention on index associated wi th tables, which are having high concurrency from the application. This usuall y happens when the application performs lot of INSERTs and DELETEs . The reason for this is the index block splits while inserting a new row into the index. The transactions will have to wait for TX lock in mode 4, until the se ssion that is doing the block splits completes the operations Causes Indexes on the tables which are being accessed heavily from the application. Indexes on table columns which are having values inserted by a monotonically inc reasing. Heavily deleted tables Detecting index leaf block contention There are many ways to find hot indexes Check high "enq: TX index contention" system waits from AWR report At the same time you will see high split events in the Instance avtivity s tats in the AWR report If yor system is RAC also you will see the following wait events in the AWR report gc buffer busy waits on Index Branch Blocks gc buffer busy waits on Index Leaf Blocks gc current block busy on Remote Undo Headers gc current split gcs ast xid gcs refuse xid we can find sql_id ' s from v$active_session_history select sql_id,count(*) from v$active_session_history a where a.sample_time between sysdate - 5/24 and sysdate and trim(a.event) like 'enq: TX - index contention%' group by sql_id order by 2; Or we can query the segments from V$SEGMENT_STATISTICS or from the 'Segments by Row Lock Waits' of the AWR reports. select * from v$segment_statistics where statistic_name ='row lock waits' and value>0 order by value desc; we can query dba_hist_enqueue_stat and the stats$enqueuestat or v$enqueue_s tat select * from v$enqueue_stat order by cum_wait_time; Solutions Reverse Key Indexes :Rebuild the as reverse key indexes or hash partition the i ndexes which are listed in the 'Segments by Row Lock Waits' of the AWR reports.T hese indexes are excellent for insert performance. But the downside of it is th at, it may affect the performance of index range scans Hash partitioned global indexes :When an index is monotonically growing because of a sequence or date key, global hash-partitioned indexes improve performance b y spreading out the contention. Thus, hash-partitioned global indexes can improv e the performance of indexes in which a small number of leaf blocks in the index have high contention in multi-user OLTP environments CACHE size of the sequences:When we use monotonically increasing sequences for p opulating column values, the leaf block which is having high sequence key will b e changing with every insert, which makes it a hot block and potential candidat e for a block split. With CACHE SIZE (and probably with NOORDER option), each in

stance would use start using the sequence keys with a different range reduces th e index keys getting insert same set of leaf blocks Index block size:Because the blocksize affects the number of keys within each i ndex block, it follows that the blocksize will have an effect on the structure o f the index tree. All else being equal, large 32k blocksizes will have more keys per block, resulting in a flatter index than the same index created in a 2k tab lespace. Adjusting the index block size may only produce a small effect and chan ging the index block size should never be your first choice for reducing index b lock contention, and it should only be done after the other approaches have been examined. Rebuild indexes:If many rows are deleted or it is an skewed indes rebuild ing will help for a while See Also: All Oracle enqueue waits Solving Waits on "enq: TM - contention"

Index leaf block contention is very common in busy databases and it s especially c ommon on tables that have monotonically increasing key values.