问题描述
enq是一种保护共享资源的锁定机制,一个排队机制
排它机制从一个事务的第一次改变直到rollback or commit 结束这个事务,
TX等待mode是6,当一个session 在一个表的行级锁定时另一个会话总是等待,一般发生在一些用户insert or update,而另一个用户同样也在insert or update 这同一批数据时发生。这种类型的等待通常就是eventenq:TX-rowlockcontention.解决方法是让第一个会话commit or rollback 结束这个事务
tx等待mode如果是4,这种一般发生在同时更新一个数据块上的数据,但不一定是同一条记录,这就是传说种的热块,这里有一个概念就是ITL(interested transaction list),有一个建表参数maxtrans ,也就是说允许一个块上有多少个active transaction, 不过到了oracle 10G,这个参数被放弃,默认最大为255,这种类型的等待通常叫eventenq:TX-allocateITLentry
专家解答
tx mode is 4 也是有可能导致那个等待,就是多次更新位图索引时,TX原因还有很多,如下:
1.不同的session更新或删除同一个记录。
2.唯一索引有重复索引
3.位图索引多次更新
4.同时对同一个数据块更新
5.等待索引块分裂
简单可以通过以下查询
#对于当前时间下 select sid,username,event,wait_class,command from v$session where state in('WAITING') and wait_class<>'Idle'; select ROW_WAIT_OBJ#,ROW_WAIT_FILE#,ROW_WAIT_BLOCK#,ROW_WAIT_ROW# from v$session where event='enq: TX - row lock contention'; # 对于过去时间的 /* col file# for 99999 col block# for 999999 col obj for a18 col type for a9 col lm for 99 col bsid for 9999 */ select count(*) cnt, session_id sid, substr(event,1,30) event, mod(p1,16) as lm, sql_id, CURRENT_OBJ# || ' ' || object_name obj , o.object_type type , CURRENT_FILE# file# , CURRENT_BLOCK# block# , blocking_session bsid from v$active_session_history ash, all_objects o where event like 'enq: T%' -- and SAMPLE_TIME between xx and xx and o.object_id (+)= ash.current_obj# group by event,session_id,p1,sql_ID,CURRENT_OBJ#,OBJECT_NAME,OBJECT_TYPE,CURRENT_FILE#, CURRENT_BLOCK#, BLOCKING_SESSION order by count(*) / #Show which segments have undergone the most row lock waits: SELECT owner, object_name, subobject_name, value FROM v$segment_statistics WHERE statistic_name='row lock waits' AND value > 0 ORDER BY 4 DESC;
Summary:
A TX lock is acquired when a transaction initiates its first change and is held until the transaction does a COMMIT or ROLLBACK. It is used mainly as a queuing mechanism so that other sessions can wait for the transaction to complete. The lock name (ID1 and ID2) of the TX lock reflect the transaction ID of the active transaction.
TX = Transaction = Wait on UNDO
Mode 6 (exclusive)
modification of a row lock
Mode 4 (share)
Index block spilt
Unique Index Key enforcement
Foreign key enforcement
ITL space waits
Bitmap chunk conflicts
Alter tablespace … read only;
Free Lists slot waits
Possible with two phase commit
TX mode 6 is straight forward, just two sessions trying to change the same data
TX mode 4 has many reasons and historically has been hard to diagnose, but now in 10g Oracle had broken down TX locks in to these sub types:
enq: TX - row lock contention pk or unique index violation fk violation bitmap chunk wait others ? enq: TX - allocate ITL entry Wait on an ITL slot enq: TX - index contention Index block split enq: TX - contention Wait for a data file extension Alter tbs read only others?
(NOTE: that “enq: TX – row lock contention” can happen in both mode 6, the typical case, or mode 4 which is shown above)
References MOS and some DBAs notes