Dica rápida: encontrando a sessão bloqueadora raiz no RAC
Uma consulta em GV$SESSION para identificar quem está no topo da cadeia de bloqueios em um ambiente Oracle RAC.
Usuários reclamando de lentidão, telas travadas e muitas sessões em enq: TX - row lock contention. Antes de sair matando sessões, descubra quem está no topo da cadeia.
Em RAC, use sempre as views GV$ — o bloqueador pode estar em outra instância. A coluna FINAL_BLOCKING_SESSION já aponta a sessão raiz:
SELECT s.inst_id,
s.sid,
s.serial#,
s.username,
s.machine,
s.program,
s.sql_id,
s.event,
s.seconds_in_wait,
s.blocking_instance,
s.blocking_session,
s.final_blocking_instance,
s.final_blocking_session
FROM gv$session s
WHERE s.blocking_session IS NOT NULL
ORDER BY s.seconds_in_wait DESC;
Depois, olhe a sessão raiz com calma — o que ela está fazendo, há quanto tempo está INACTIVE, qual o último SQL:
SELECT inst_id, sid, serial#, username, status, machine, program,
sql_id, prev_sql_id, last_call_et, logon_time
FROM gv$session
WHERE (inst_id, sid) IN (
SELECT DISTINCT final_blocking_instance, final_blocking_session
FROM gv$session
WHERE final_blocking_session IS NOT NULL
);
Uma sessão INACTIVE com LAST_CALL_ET alto segurando lock geralmente é transação aberta sem COMMIT — muitas vezes de uma ferramenta cliente esquecida aberta. Antes de encerrar, alinhe com o responsável pela aplicação. Se for preciso matar, em RAC informe a instância:
ALTER SYSTEM KILL SESSION 'sid,serial#,@inst_id' IMMEDIATE;
Leia também
Monitorando o Oracle Data Guard com SQL: status, lag e gaps
Um roteiro de consultas para verificar rapidamente a saúde de um ambiente Data Guard: papel do banco, transport e apply lag, gaps de archive e processos de recuperação.
Objetos inválidos antes e depois de uma mudança no banco
Por que registrar a contagem e a lista de objetos inválidos antes e depois de uma GMUD — e as consultas que uso para isso.