ORA-03113: End-of-file on Communication Channel — Causas e Roteiro de Diagnóstico

O ORA-03113 é, junto com o ORA-12560, um dos erros mais genéricos que o Oracle pode devolver — e por isso mesmo um dos mais mal diagnosticados. A mensagem "end-of-file on communication channel" não diz o que quebrou: só que a conversa entre cliente e servidor foi interrompida abruptamente, no meio do caminho. A causa pode estar em qualquer ponto entre o processo cliente e o processo servidor — e é justamente aí que mora o trabalho de investigação.

O que o erro significa

Segundo a documentação oficial da Oracle, a causa do ORA-03113 é descrita como: um fim de arquivo inesperado foi processado no canal de comunicação, o que pode indicar que o link de comunicação caiu (ao menos temporariamente) ou que o servidor caiu. A ação recomendada pela própria Oracle é checar o arquivo alert_sid.log no servidor e, se necessário, ajustar a contagem de retransmissão.

Ou seja: o ORA-03113 é um sintoma, não um diagnóstico. Ele aparece tanto quando o processo servidor (shadow process) morre inesperadamente quanto quando a rede entre cliente e servidor cai. O primeiro lugar a olhar é sempre o alert log da instância.

Causas mais comuns

• Processo servidor (shadow process) morreu com erro interno: se um ORA-00600 ou ORA-07445 aparece no alert log próximo do horário do ORA-03113, o processo servidor provavelmente crashou por um erro interno do banco. Nesse caso o ORA-03113 é só a consequência vista do lado do cliente.

• Esgotamento de memória compartilhada: um ORA-04031 (falha ao alocar memória no shared pool ou em outras estruturas de memória compartilhada) pode preceder o ORA-03113, deixando sessões existentes em estado errático até a queda da conexão.

• Limite de PROCESSES ou SESSIONS atingido: quando a instância se aproxima do teto configurado em PROCESSES/SESSIONS, novas tentativas de conexão e até sessões já estabelecidas podem falhar de forma inconsistente, incluindo com ORA-03113.

• Instabilidade de rede entre cliente e servidor: latência alta, perda de pacotes ou uma interrupção momentânea no link de rede derrubam o canal de comunicação.

• Firewall derrubando conexões ociosas: firewalls e balanceadores costumam ter um timeout de inatividade; se a sessão Oracle fica parada além desse tempo, o firewall fecha a conexão sem avisar nenhum dos dois lados, e a próxima operação no cliente recebe ORA-03113.

• Queda planejada ou não planejada da instância: shutdown, crash da instância ou de um dos processos de background também interrompe todas as sessões ativas com esse erro.

  
  

Diagnóstico passo a passo

1. Verificar o alert log da instância.

Em bancos com ADR habilitado (11g em diante), o alert log fica em:

$ORACLE_BASE/diag/rdbms/<db_unique_name>/<SID>/trace/alert_<SID>.log

O caminho exato é controlado pelo parâmetro DIAGNOSTIC_DEST. Para não precisar navegar manualmente pelos diretórios, consulte a view:

SELECT name, value FROM v$diag_info WHERE name = 'Diag Trace';

2. Usar o ADRCI para localizar e listar incidentes.

adrci
adrci> show homes
adrci> show alert -tail -f

Se houver um incidente registrado (típico quando há ORA-00600/ORA-07445), o ADRCI permite empacotar os arquivos de diagnóstico para abertura de SR com a Oracle:

adrci> show incident
adrci> ips create package incident incid <id>

3. Procurar ORA-00600, ORA-07445 ou ORA-04031 no horário do ORA-03113.

Se algum desses aparecer no alert log próximo ao timestamp do ORA-03113, o problema está no processo servidor (crash interno ou memória), não na rede — a investigação de rede pode ser descartada.

4. Checar PROCESSES e SESSIONS.

SELECT resource_name, current_utilization, max_utilization, limit_value
FROM v$resource_limit
WHERE resource_name IN ('processes','sessions');

Se current_utilization estiver colado no limit_value, esse é um forte candidato a causa raiz.

5. Se o alert log não mostrar nada relevante, suspeitar de rede/firewall.

Nesse cenário, o erro tende a se repetir em sessões que ficam ociosas por um tempo específico (o timeout do firewall) e não durante uso ativo. Vale revisar o timeout de inatividade do firewall/balanceador no caminho entre cliente e servidor.

Mitigação para o cenário de rede/firewall

Quando a causa é confirmada como firewall derrubando conexões ociosas, o parâmetro SQLNET.EXPIRE_TIME, configurado no sqlnet.ora do ORACLE_HOME do banco (lado servidor), faz o servidor enviar periodicamente um pacote de sondagem (probe) para o cliente durante períodos de inatividade. Esse tráfego artificial mantém o firewall enxergando a conexão como ativa, evitando que ela seja derrubada por timeout de ociosidade. Esse mecanismo é conhecido como Dead Connection Detection (DCD) e também serve para limpar, do lado do servidor, sessões cujo cliente caiu sem se desconectar corretamente.

O valor de SQLNET.EXPIRE_TIME deve ser definido abaixo da metade do timeout de inatividade do firewall — um valor comum é SQLNET.EXPIRE_TIME=10 (em minutos), mas o ideal é calibrar de acordo com o timeout real do firewall no seu ambiente. O valor recomendado pode variar por versão/ambiente — confirme com a documentação de Net Services da sua versão específica antes de aplicar em produção.

Resumo prático

O ORA-03113 nunca deve ser tratado isoladamente — ele é o efeito, não a causa. O roteiro correto é: alert log primeiro, ADRCI para detalhar incidentes, correlação com ORA-00600/ORA-07445/ORA-04031, checagem de PROCESSES/SESSIONS e, só depois de descartar o lado do banco, investigação de rede e firewall. Pular direto para "deve ser a rede" sem checar o alert log é o erro de diagnóstico mais comum nesse caso.