0% found this document useful (0 votes)
761 views2 pages

LATCH - Enq TX - Index Contention

Index leaf block contention often occurs on indexes associated with tables that experience high concurrency from applications performing many INSERTs and DELETEs. This is because index block splits are required during inserts, locking transactions until the splits complete. Indexes on heavily and frequently accessed tables, especially those with monotonically increasing key values, are most prone to this contention. Symptoms can be identified by monitoring index wait events in AWR reports and resolving the issue involves techniques like reversing key indexes, hash partitioning indexes, adjusting sequence cache sizes, and potentially rebuilding indexes.

Uploaded by

cotosilva
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
761 views2 pages

LATCH - Enq TX - Index Contention

Index leaf block contention often occurs on indexes associated with tables that experience high concurrency from applications performing many INSERTs and DELETEs. This is because index block splits are required during inserts, locking transactions until the splits complete. Indexes on heavily and frequently accessed tables, especially those with monotonically increasing key values, are most prone to this contention. Symptoms can be identified by monitoring index wait events in AWR reports and resolving the issue involves techniques like reversing key indexes, hash partitioning indexes, adjusting sequence cache sizes, and potentially rebuilding indexes.

Uploaded by

cotosilva
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 2

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.

You might also like