How to get the SQL_ID that is blocking another SQL? Well, I'm personalizing a useful script that I found and I need put in this script what is the sql_id of the SQL that is blocking another SQL.

Here is my script, if you try this, You never will get the sql_id of the blocker session, just the sql_id of the bloqued session.

col BLOCKER for a20;
col OBJ_BLOCKED for a20;
set linesize 3000;
col OWNER_OBJCT for a25;
set pagesize 0 embedded on;
select TO_CHAR(TRUNC(max(l2.ctime)/3600),'FM9900') || ':' ||
    TO_CHAR(TRUNC(MOD(max(l2.ctime),3600)/60),'FM00') || ':' ||
    TO_CHAR(MOD(max(l2.ctime),60),'FM00') AS "Tempo LOCK",
c.username "BLOCKER",c.sid "SID_BLOCKER",c.serial# "SERIAL#_BLOCKER",c.inst_id "ID_inst_BLOCKER",c.sql_id,
b.object_name "OBJ_BLOCKED",b.owner "OWNER_OBJCT", 
d.username "SES_BLOCKED" ,d.sid "SID_SES_BLOCKED",d.serial# "SERIAL_SES_BLOCKED",d.inst_id "IDinst_SES_BLOCKED",d.sql_id from gv$locked_object a, dba_objects b, gv$session c, gv$session d,gv$lock l2 where a.object_id=b.object_id and 
c.sid=a.session_id and l2.sid=c.sid and c.username is not null and c.sid in (select blocking_session from gv$session) and d.blocking_session is not null
group by c.username,c.sid,c.serial#,c.inst_id,b.object_name,b.object_type,b.owner,d.username,d.sid,d.serial#,d.inst_id,d.sql_id,c.sql_id
order by 1,3,4 asc
/


Can someone help me?
Locks belong to transactions, not SQL statements.

SQL statements do not block other SQL statements on their own. Transactions may block other transactions.

A transaction may consist of multiple SQL statements.

The database can return the current (v$session.sql_id) and previous (v$session.prev_sql_id) SQL statement for a session.

If the blocking session is idle, its sql_id will be null.

If the lock that blocks another transaction was placed by not the current and not the previous SQL, but by one before them, then you are out of luck, you will not find it in such views.

Even if the lock that blocks another transaction was placed by the current or the previous SQL of the blocking session, there is no direct evidence provided about it. You need to examine the SQLs, you need to know what they do, and using that information, decide if really those SQLs placed the lock that blocks another transaction (session).

A simple query like that may provide adequate results for simple cases, but it can not provide a guaranteed answer to what you asked generally.

You can do that with tracing and carefully reading and analyzing the trace files.