enq: TX - row lock contention(二)

[转]等待事件---enq:TX - row lock contention

找到的一篇不错的解释enq:TX - row lock contention的文章放在这里分享一下。

enq是一种保护共享资源的锁定机制，一个排队机制，先进先出(FIFO)

发生TX锁的原因一般有几个

1.不同的session更新或删除同一个记录。

2.唯一索引有重复索引

3.位图索引多次更新

4.同时对同一个数据块更新

5.等待索引块分裂

通过数据系统视图检查果然是多个update的sql

select sid,username,event from v$session where stat in('WAITING') and wit_class!='Idle';

sid从上面的sql获得

select sid,sql_text from v$session a,v$sql b where sid in(282,496) and (b.sql_id=a.sql_id or b.sql_id=a.prev_sql_id);

-----------------------------------------------------------------------------------------------------

These are acquired exclusive when a transaction initiates its first change and held until the transaction does aCOMMITorROLLBACK.

Waits for TX in mode 6: occurs when a session is waiting for a row level lock that is already held by another session. This occurs when one user is updating or deleting a row, which another session wishes to update or delete. This type of TX enqueue wait corresponds to the wait eventenq:TX-rowlockcontention.

The solution is to have the first session already holding the lock perform. aCOMMITorROLLBACK.

Waits for TX in mode 4 can occur if the session is waiting for an ITL (interested transaction list) slot in a block. This happens when the session wants to lock a row in the block but one or more other sessions have rows locked in the same block, and there is no free ITL slot in the block. Usually, Oracle dynamically adds another ITL slot. This may not be possible if there is insufficient free space in the block to add an ITL. If so, the session waits for a slot with a TX enqueue in mode 4. This type of TX enqueue wait corresponds to the wait eventenq:TX-allocateITLentry.

The solution is to increase the number of ITLs available, either by changing theINITRANSorMAXTRANSfor the table (either by using anALTERstatement, or by re-creating the table with the higher values).

Waits for TX in mode 4 can also occur if a session is waiting due to potential duplicates inUNIQUEindex. If two sessions try to insert the same key value the second session has to wait to see if anORA-0001should be raised or not. This type of TX enqueue wait corresponds to the wait eventenq:TX-rowlockcontention.

The solution is to have the first session already holding the lock perform. aCOMMITorROLLBACK.

Waits for TX in mode 4 is also possible if the session is waiting due to shared bitmap index fragment. Bitmap indexes index key values and a range of ROWIDs. Each 'entry' in a bitmap index can cover many rows in the actual table. If two sessions want to update rows covered by the same bitmap index fragment, then the second session waits for the first transaction to eitherCOMMITorROLLBACKby waiting for the TX lock in mode 4. This type of TX enqueue wait corresponds to the wait eventenq:TX-rowlockcontention.

Waits for TX in Mode 4 can also occur waiting for aPREPAREDtransaction.

Waits for TX in mode 4 also occur when a transaction inserting a row in an index has to wait for the end of an index block split being done by another transaction. This type of TX enqueue wait corresponds to the wait eventenq:TX-indexcontention.

from:http://www.unix-center.net/bbs/viewthread.php?tid=15059