Enviar o trace de um deadlock (ORA-00060)

Quando duas sessões esperam uma pela outra, o Oracle desfaz o comando de uma delas, devolve a ela o ORA-00060 e grava o trace do deadlock sozinho, sem nenhum trace ligado. O WaitScope lê esse arquivo e mostra quem esperava por quem, em que linha e com qual comando.

Antes de começar

• Acesso ao sistema operacional do servidor do banco, ou alguém que copie o arquivo para você.
• O horário aproximado do erro e a instância, para achar a linha certa no alert log.
• Nada para ligar: o arquivo já foi gravado quando o erro aconteceu. Copie logo, porque a limpeza do ADR apaga traces antigos.

Achar o arquivo pelo alert log

1. Ache a pasta de trace da instância:

   select value
   from v$diag_info
   where name = 'Diag Trace';

2. Nessa pasta, procure o ORA-00060 no alert log em texto, o arquivo alert_<SID>.log:

   grep -n 'ORA-00060' alert_ORCL1.log

3. Leia a linha do erro: ela traz o caminho do arquivo de trace com o deadlock, na mesma pasta.
4. Copie esse .trc. O .trm de mesmo nome não é necessário.

Resultado: um arquivo com o bloco DEADLOCK DETECTED ( ORA-00060 ), seguido do grafo (Deadlock graph) e das informações das sessões envolvidas.

Enviar o arquivo

Envie o .trc como qualquer trace, pelo navegador ou pelo app Android: o WaitScope reconhece o tipo pelo conteúdo. No Histórico, a coluna Tempo total da análise mostra deadlock.

Um mesmo arquivo pode ter mais de um deadlock, quando o processo recebeu o erro mais de uma vez: o relatório mostra um cartão para cada bloco DEADLOCK DETECTED.

O que o relatório mostra

O trace só de deadlock não tem perfil de tempo. O relatório tem três partes:

• Resumo: quantos deadlocks, Detectado em com a hora e a linha do trace, Sessões envolvidas com o ciclo de espera, e o diagnóstico pelo tipo de lock.
• Diagnóstico: um achado de severidade alta por deadlock, com o tipo de lock e as sessões, e o link Ver deadlock (o achado de deadlock).
• Deadlocks: o ciclo de espera, o Grafo de espera com o recurso, o tipo e os modos de quem espera e de quem segura, as Sessões envolvidas com usuário, PDB, máquina, programa, módulo, ação, linha esperada e SQL de cada uma, e a Pilha PL/SQL da sessão que recebeu o erro (seção Deadlocks).

O relatório de exemplo vem de um trace sem deadlock, por isso não tem essa seção.

Deadlock dentro de um trace 10046

Se a sessão estava com o trace 10046 ligado quando recebeu o erro, o bloco do deadlock vai para o mesmo arquivo. O relatório traz o perfil completo e mais:

• a seção Deadlocks, igual à do trace só de deadlock;
• o tempo esperando o lock no perfil, numa espera como enq: TX - row lock contention;
• o ORA-00060 na seção Erros, com o comando que recebeu o erro (seção Erros).

Assim dá para ver quanto do tempo total a sessão perdeu esperando antes do erro (espera por bloqueio).

Problemas comuns

• O alert log não mostra o ORA-00060. Em RAC, o erro pode ter acontecido em outra instância: procure no alert log de cada uma.
• O arquivo apontado não existe mais. A limpeza do ADR apagou o trace. Da próxima vez, copie o arquivo logo depois do erro.
• Deadlock entre instâncias do RAC. O WaitScope lê o deadlock pelo bloco DEADLOCK DETECTED. O deadlock entre instâncias é detectado pelo processo LMD (processos de fundo do Oracle), e o trace dele, com _lmd no nome, tem outro formato, que o WaitScope não lê: a análise desse arquivo termina com erro, porque ele não tem as linhas do evento 10046. Para medir o tempo perdido com o lock, ligue o 10046 nas sessões da operação: a espera aparece no perfil e o ORA-00060, na seção Erros.

Próximos passos

• Leia a seção Deadlocks campo a campo.
• Veja causas e correções em deadlock.
• Para medir o tempo perdido com o lock, ligue o 10046 na sessão (ligar o trace com o DBMS_MONITOR).