Re: Weird Situation (12.1.0.2 Exadata Cloud @ Customer) - Blocking locks with no blocker

  • From: Stefan Koehler <contact@xxxxxxxx>
  • To: christopherdtaylor1994@xxxxxxxxx, ORACLE-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 1 Apr 2020 16:12:33 +0200 (CEST)

Hello Chris,

How can I dump/trace the blocking session manually?

Essentially a systemstate dump :-)

However your described scenario ("enq: TX - row lock contention" without 
blocker) sounds familiar to me. Is there any chance that you use distributed 
transactions in some way?

Best Regards
Stefan Koehler

Independent Oracle performance consultant and researcher
Website: http://www.soocs.de
Twitter: @OracleSK
Chris Taylor <christopherdtaylor1994@xxxxxxxxx> hat am 1. April 2020 um 15:38 
geschrieben: 


We've got a situation where we have sessions experiencing "enq: TX - row lock 
contention" with no blocking session.
 
GV$SESSION.BLOCKING_SESSION is null
DBA_WAITERS is empty
DBA_BLOCKERS is empty
 
I've gotten around this by joining gv$locked_object to gv$session where 
session.wait_class='Idle' and wait_time_micro/1000000 > 120 (seconds).
 
Some of the locks are for sessions with thousands of wait seconds waiting on 
sqlnet. 
 
*BUT* the issue is, why isn't oracle able to find the blocking sessions?  How 
can I dump/trace the blocking session manually?
 
In Grid Control we see stuff like: "lock deadlock retry" in the wait events 
for the sessions waiting on "enq: TX - row lock".
 
In the session trace files, we see stuff like "unable to determine final 
blocker" . 
 
Any thoughts?

Chris
--
//www.freelists.org/webpage/oracle-l


Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 04-2020