Hey Luis,
if this is just a sporadic issue of a simple DML and a "manual" analysis would
be ok ... then you could use XIDUSN, XIDSLOT, XIDSQN from V$TRANSACTION
and combine this with DML via LogMiner (XIDUSN , XIDSLT, XIDSQN) from
V$LOGMNR_CONTENTS.
Best Regards
Stefan Koehler
Freelance Oracle performance consultant and researcher
Homepage: http://www.soocs.de
Twitter: @OracleSK
Luis Santos <lsantos@xxxxxxxxx> hat am 8. September 2016 um 15:57 geschrieben:
Sometimes we have some INACTIVE sessions holding another sessions due locks.
It´s easy of course to find discover the lock tree, and also the object
involved in query.
But is there a simple way (without any trace) to discover to the SQL_ID that
locked the rows related to blocker lock?
When the locker session runs the statement (usually an update) that locks
these rows this same session, generally, runs several other statements
(usually SELECTs) and after them becomes into SQL*Net message to client. So
the current (and previous) SQL_ID for the locker session is useless.
We have mainly 11.2.0.4 RDBMS versions.
--
Att
Luis Santos
