If one is seeing waits for enq: TX – row lock contention then there could be a lot of reasons. One distinguishing factor is the lock mode. If the lock mode is exclusive (mode 6) then it’s most likely a classic row lock where two sessions are trying to modify the same row. On the other hand if the lock mode is share (mode 4) it’s typically going to be
Primary/Unique Key: inserting a unique key when someone else has already inserted that key but not committed
Foreign Key: Inserting a foreign when then parent value has been inserted but not committed or deleted and not commited (not to be confused with locks due to un-indexed foreign key which cause a “enq: TM – contention” wait not a TX wait)
Bitmap Index: bitmap index chunk contention
Now how to tell which of these is happening? Well here is a query on ASH (I’ve commented out some of the useful fields to limit the output) that will generate output to help us distinguish between the 3 different cases
col object for A15
col otype for A10
select
substr(event,0,20) lock_name,
--ash.session_id waiter,
--mod(ash.p1,16) lmode,
--ash.p2 p2,
--ash.p3 p3,
o.object_name object,
o.object_type otype,
CURRENT_FILE# filen,
CURRENT_BLOCK# blockn,
--ash.SQL_ID waiting_sql,
BLOCKING_SESSION blocker
--,ash.xid
from
v$active_session_history ash,
all_objects o
where
event like 'enq: TX%'
and mod(ash.p1,16)=4
and o.object_id (+)= ash.CURRENT_OBJ#
/
Here is the output from the 3 different cases
Unique Index
OBJECT OTYPE FILEN BLOCKN BLOCKER
------ ------ ----- ------ -------
-1 0 0 158
-1 0 0 158
-1 0 0 158
-1 0 0 158
Foreign Key
OBJECT OTYPE FILEN BLOCKN BLOCKER
------ ------ ----- ------ -------
CHILD TABLE 1 60954 1
CHILD TABLE 1 60954 1
CHILD TABLE 1 60954 1
Bitmap Index
OBJECT OTYPE FILEN BLOCKN BLOCKER
------ ------ ----- ------ -------
I1 INDEX 0 0 144
I1 INDEX 0 0 144
I1 INDEX 0 0 144
I1 INDEX 0 0 144
Each case has a different footprint.
Unique key index issue object of “-1″
Foreign key case has a blocker of “1″
Bitmap index case as filen and blockn “0″
These cases were run on 10.2.0.3 thus the “footprint” could change on other versions.
The above ASH query and many other useful ASH queries are maintained on GitHub at
Comments