Bloqueios de banco por sessao no Winthor

No Winthor, que foi construido em Delphi, e comum acontecer conflito de acesso quando duas rotinas tentam usar o mesmo registro ao mesmo tempo ou quando uma sessao fica aberta no banco mesmo depois de um erro na aplicacao.

Um exemplo pratico acontece na rotina 336. Apos liberar o pedido, se der algum erro, o Winthor pode acabar nao fechando a sessao no banco de dados. Depois, ao tentar emitir o pedido na rotina 931, o sistema informa que aquele registro esta sendo utilizado por outra rotina.

Nesse momento ocorre o lock de banco: uma sessao fica como bloqueadora e a outra fica aguardando liberacao.

Este relatorio serve exatamente para isso: mostrar quem e o bloqueador e quem e o bloqueado.

Quando usar

Esse SQL e util para:

• identificar travamentos entre usuarios e rotinas no Winthor
• descobrir qual maquina ou programa esta segurando o lock
• agilizar o suporte quando uma rotina fica parada aguardando liberacao
• entender conflitos como o da rotina 336 com a rotina 931
• agir rapidamente quando o bloqueio paralisa operacoes do estoque

SQL sugerido

SELECT 
    s1.sid || ',' || s1.serial# AS bloqueador,
    s1.username,
    s1.machine,
    s1.program,
    s2.sid || ',' || s2.serial# AS bloqueado,
    s2.username,
    s2.machine,
    s2.program 
FROM v$lock l1
JOIN v$session s1 ON s1.sid = l1.sid
JOIN v$lock l2 ON l1.id1 = l2.id1 AND l1.id2 = l2.id2
JOIN v$session s2 ON s2.sid = l2.sid
WHERE l1.block = 1
AND l2.request > 0;

O que a consulta mostra

O retorno traz duas pontas do problema:

• bloqueador: SID e SERIAL da sessao que esta segurando o recurso
• username, machine, program: usuario, maquina e programa da sessao bloqueadora
• bloqueado: SID e SERIAL da sessao que ficou presa esperando
• username, machine, program: usuario, maquina e programa da sessao bloqueada

Na pratica, isso permite localizar rapidamente:

• quem abriu primeiro e manteve o registro travado
• quem tentou usar o mesmo recurso depois e ficou aguardando
• em qual estacao ou rotina o problema aconteceu
• qual sessao ficou aberta indevidamente apos erro no processo

Como interpretar

Se a consulta retornar linhas, significa que existe ao menos um bloqueio ativo no banco.

Em geral:

• a coluna bloqueador indica a sessao que precisa finalizar a operacao ou liberar a transacao
• a coluna bloqueado indica a sessao impactada, que nao conseguiu prosseguir
• machine ajuda a descobrir em qual computador esta o usuario
• program ajuda a entender se o lock veio do proprio Winthor, de integracao ou de outra rotina conectada ao Oracle

Como operar no dia a dia

Esse relatorio e muito util para suporte e operacao quando alguem reclama que o sistema "travou" ou que nao consegue concluir uma rotina.

No exemplo citado, a rotina 336 libera o pedido, ocorre um erro, a sessao fica aberta no banco e o registro continua preso. Quando a rotina 931 tenta emitir o pedido, encontra esse bloqueio e nao consegue seguir.

Com ele, voce consegue responder rapidamente:

• quem esta bloqueando o processo
• quem esta sofrendo o bloqueio
• em qual maquina esta o usuario que precisa liberar a operacao
• se o problema veio de uma sessao que nao foi encerrada corretamente
• por que as impressoes da rotina ficaram travadas, paralisando o estoque

Uso com QueryAlerts

Uma aplicacao interessante e usar essa consulta no QueryAlerts para monitorar bloqueios recorrentes no ambiente.

Por exemplo:

• rodar a consulta em intervalos curtos durante o expediente
• avisar algum funcionario responsavel quando houver retorno
• registrar quais usuarios, maquinas ou programas aparecem com mais frequencia nos locks

No cenario das rotinas 336 e 931, isso ajuda a avisar rapidamente quem precisa corrigir o problema, evitando que o bloqueio trave todas as impressoes da rotina e paralise o estoque.