Temos uma política bastante restritiva em relação a anúncios no site. Eles nunca irão te atrapalhar!
Além disso, usamos banners para lhe informar de assuntos importantes. Os bloqueadores de anúncios impedem que esses banners sejam visualizados.
Sendo assim, para continuar, é importante que você desligue o bloqueador de anúncio e recarregue a página. Obrigado!

1. Qual é o sintoma?

Um backup executado com o gbak usando a opção de paralelismo (-PAR n) inicia normalmente, processa várias tabelas e, ao chegar em determinada tabela, é interrompido retornando ResultCode = 1. No firebird.log, no mesmo horário, aparece uma entrada semelhante a:

INET/inet_error: read errno = 10053, server host = 127.0.0.1, address = 127.0.0.1/3050

Sem a opção -PAR, o mesmo backup conclui sem erros. E, ao tentar restaurar também com -PAR, o processo parece travar.

2. Isso é um crash (falha) do engine do Firebird?

Não. A mensagem INET/inet_error ... errno = 10053 apenas informa que a conexão TCP foi encerrada abruptamente pelo outro lado. Ela é uma consequência do erro, não a causa. O servidor não caiu.

3. Onde está a mensagem real do erro?

Na saída do próprio gbak (stdout/stderr), que costuma ser ignorada quando o comando é disparado por um agendador ou por uma aplicação. Ela traz o motivo exato:

gbak: ERROR:database NOMEDOBANCO.FDB shutdown
gbak: Exiting before completion due to errors

Sempre capture e leia essa saída antes de investigar o log do servidor.

4. Qual é a causa raiz?

O banco de dados está em shutdown no modo single-user (modo de manutenção mono-usuário). Nesse estado, o Firebird permite apenas uma conexão simultânea ao banco.

O backup paralelo funciona abrindo vários workers, e cada worker precisa de sua própria conexão com o banco. A primeira conexão é aceita; as demais são recusadas com o erro de banco em shutdown, e o gbak aborta a operação.

5. Por que sem -PAR o backup funciona?

Porque o gbak, em modo serial, utiliza uma única conexão — exatamente o limite que o modo single-user permite. Ou seja, remover o -PAR não corrige nada: apenas mascara o estado incorreto do banco.

6. Como confirmar o estado do banco?

Consulte o cabeçalho do banco e observe a linha de atributos:

gstat -h C:\caminho\banco.fdb -user SYSDBA -password ******

Se aparecer algo como Attributes: single-user maintenance (ou multi-user maintenance / full shutdown), o banco não está online. Estando conectado, também é possível verificar via SQL:

SELECT MON$SHUTDOWN_MODE FROM MON$DATABASE;

O valor 0 indica online; qualquer valor diferente indica algum nível de shutdown.

6.1. E se o banco estiver em multi-user maintenance?

Nesse modo o Firebird aceita várias conexões simultâneas, desde que sejam de SYSDBA, do owner do banco ou de usuários com a role RDB$ADMIN. Como o gbak já exige um desses perfis para operar, um backup paralelo tende a funcionar mesmo com o banco nesse estado.

A diferença entre os modos está no que cada um restringe:

• multi — várias conexões, apenas para perfis administrativos.
• single — uma única conexão, apenas para perfis administrativos.
• full — nenhuma conexão.

É justamente por isso que o problema descrito neste FAQ se manifesta apenas com -PAR: o modo single não barra o backup por falta de permissão, e sim por esgotar o limite de uma conexão assim que o segundo worker tenta se conectar. Ainda assim, nenhum modo de manutenção é estado adequado para um banco em produção — devolva-o para online com gfix -online.

7. Como resolver?

Devolva o banco ao estado online normal:

gfix -online C:\caminho\banco.fdb -user SYSDBA -password ******

Depois disso, repita o backup com -PAR normalmente. Confirme com o gstat -h que o atributo de manutenção desapareceu antes de reexecutar.

8. Como o banco foi parar nesse estado?

Quase sempre por uma rotina de manutenção que colocou o banco em shutdown (por exemplo gfix -shut single -at 0, usado antes de um -mend, de uma cópia física ou de uma atualização de metadados) e não o devolveu para online — seja por falha no meio do script, seja por interrupção manual. O estado é persistente: sobrevive ao restart do serviço.

9. Checklist rápido

1. Leia e registre a saída do gbak; não diagnostique apenas pelo firebird.log.
2. Verifique o estado do banco com gstat -h.
3. Se houver atributo de manutenção, execute gfix -online.
4. Nos scripts de manutenção, sempre coloque o gfix -online em bloco de finalização, inclusive em caso de erro.
5. Não use a remoção do -PAR como solução definitiva — ela apenas esconde o problema.

Resumo: o erro de rede no log e a falha do backup paralelo são sintomas; a causa é o banco estar em shutdown mono-usuário, o que impede mais de uma conexão simultânea.

Ao contrário dos guias tradicionais de otimização de desempenho, este e-book foca no raciocínio por trás de um diagnóstico bem-sucedido. Ele introduz uma estrutura sistemática que ajuda os profissionais de Firebird a irem dos sintomas observados até explicações fundamentadas, classificando problemas, selecionando estratégias de investigação adequadas, interpretando evidências Corretamente e utilizando ferramentas de diagnóstico com um propósito claro.

O livro abrange todo o processo de diagnóstico, desde a compreensão do porquê de algumas investigações falharem até a interpretação de tabelas de monitoramento, sessões de trace, saídas de profiler, relatórios do gstat, métricas do sistema operacional e o comportamento do hardware moderno no contexto do desempenho do Firebird.

Seja você um administrador de banco de dados, desenvolvedor, consultor ou engenheiro de suporte, este e-book oferece uma metodologia prática para abordar problemas complexos de desempenho com maior confiança e consistência.