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

Nope, but I saw a blog or oracle support document on that issue as well.

I cannot figure it out and its driving me a bit bonkers. It only started in the last couple of weeks and the db has been bounced since it was first noticed.

I really don't want to take a system state dump on this crazy system and was hoping there was a way to debug a session individually.

Chris

On Wed, Apr 1, 2020 at 10:12 AM Stefan Koehler <contact_at_soocs.de> wrote:

> 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