Recently I had to research a “enq: TM contention” wait event. I queried active session history (ASH) an found blocking session’s id.
I queried ASH again and found what the blocking session was doing right at the time when the other session was waiting on the “enq: TM contention” lock. At this time there was a long running select statement active in the blocking session.
How is that possible? Can a select create a lock? What must have happened ? Would it actually help to tune the select?
For a further hint you might wat to read Arup Nanda’s blog on transaction locks.
Oracle Riddle Blog 
What the session is doing right now doesn’t need to have any relation with what the session did to obtain the lock.
It may have:
updated one row from a table
run intensive query
(whilst the query is running, the original updated row is still locked)
then do something else?
then commit?
Speeding up the query could potentially mean that the process to release the lock (committing) gets hit sooner, but we don’t know what comes next in the process (if anything)… if it’s causing problems blocking other sessions then the whole process should be looked at.
LikeLiked by 1 person