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

From: Stefan Koehler <contact_at_soocs.de>
Date: Wed, 1 Apr 2020 16:12:33 +0200 (CEST)
Message-ID: <1661523109.689976.1585750353800_at_ox.hosteurope.de>


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: _at_OracleSK
> Chris Taylor <christopherdtaylor1994_at_gmail.com> 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

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Apr 01 2020 - 16:12:33 CEST

Original text of this message