Re: Holder query in lock

  • From: Stefan Koehler <contact@xxxxxxxx>
  • To: lsantos@xxxxxxxxx, ORACLE-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 8 Sep 2016 17:19:02 +0200 (CEST)

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 

--
http://www.freelists.org/webpage/oracle-l


Other related posts: