Re: Weird Situation (12.1.0.2 Exadata Cloud _at_ Customer) - Blocking locks with no blocker
Date: Wed, 1 Apr 2020 14:30:07 +0000
Message-ID: <LNXP265MB15627E6BF7341A323A6D0C99A5C90_at_LNXP265MB1562.GBRP265.PROD.OUTLOOK.COM>
Since you're looking at gv$ does that mean you're running RAC ?
TX - Row lock contention should be reporting mode 6 I think, but could you check that in case you're waiting for mode 4.
When a session is waiting, are there other sessions also waiting for the same TX enqueue ?
Regards
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
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
Jonathan Lewis
From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of Chris Taylor <christopherdtaylor1994_at_gmail.com>
Sent: 01 April 2020 14:38
To: ORACLE-L
Subject: Weird Situation (12.1.0.2 Exadata Cloud _at_ Customer) - Blocking locks with no blocker
DBA_WAITERS is empty
DBA_BLOCKERS is empty
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Apr 01 2020 - 16:30:07 CEST