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@xxxxxxxx> 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: @OracleSK
Chris Taylor <christopherdtaylor1994@xxxxxxxxx> hat am 1. April 2020 um15:38 geschrieben:
lock contention" with no blocking session.
We've got a situation where we have sessions experiencing "enq: TX - row
session.wait_class='Idle' and wait_time_micro/1000000 > 120 (seconds).
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
waiting on sqlnet.
Some of the locks are for sessions with thousands of wait seconds
sessions? How can I dump/trace the blocking session manually?
*BUT* the issue is, why isn't oracle able to find the blocking
events for the sessions waiting on "enq: TX - row lock".
In Grid Control we see stuff like: "lock deadlock retry" in the wait
blocker" .
In the session trace files, we see stuff like "unable to determine final
Any thoughts?
Chris
