But a single transaction could be made up of multiple DML statements, and
multiple statements from the same transaction might have modified the same
table, and multiple copies of the same statement might have modified the same
table, and recursive statements (e.g. from "on delete cascade") might be
responsible for the actual block rather than the statement that the client
program ran.
If Oracle were to implement a way to track which SQL_ID was the blocking
statement they would actually need to record FOR EVERY ROW MODIFIED by a
transaction which execution of which statement blocked that row, and which
statement(s) - if any - was the parent of of the blocking statement.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
@jloracle
________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [oracle-l-bounce@xxxxxxxxxxxxx] on behalf
of Yong Huang [dmarc-noreply@xxxxxxxxxxxxx]
Sent: 09 September 2016 14:37
To: Oracle-l Digest Users
Cc: lsantos@xxxxxxxxx
Subject: Re: Holder query in lock
But is there a simple way (without any trace) to discover to the
SQL_ID that locked the rows related to blocker lock?