Erros

Erros 823, 824 e 825 no SQL Server: como diagnosticar problemas de I/O

26 de agosto de 2026 · 5 min de leitura

As três aparecem juntas com frequência, mas não são o mesmo problema: 823 é um erro do sistema operacional repassado pelo SQL Server, 824 é uma inconsistência que o próprio SQL Server detectou ao ler a página, e 825 é um aviso — uma leitura que falhou e teve sucesso na tentativa seguinte.

Erro 823 — o disco (ou o SO) reportou falha

"The operating system returned error X to SQL Server during a read/write at offset Y in file 'Z'." — Msg 823, Level 24 (severo, a conexão é encerrada). O sistema operacional recusou ou falhou a operação de I/O — a causa está abaixo do SQL Server: disco, controladora, cabo, driver, ou o antivírus travando o arquivo.

Erro 824 — corrupção lógica detectada pelo próprio SQL Server

"SQL Server detected a logical consistency-based I/O error." — Msg 824, geralmente Level 24. Diferente do 823, aqui a leitura do disco funcionou, mas o conteúdo da página não bate com o esperado (checksum incorreto, page ID errado, torn page). A causa mais comum é um desligamento abrupto sem write-cache protegido, ou corrupção que já estava silenciosamente no arquivo.

Erro 825 — o aviso que ninguém deveria ignorar

"A read of the file succeeded after failing N time(s)..." — Msg 825, Level 10 (informativo, não derruba a conexão). A leitura falhou e funcionou de novo na tentativa seguinte. Isso não é normal: é o sintoma clássico de um disco em array/SAN começando a degradar, muitas vezes semanas antes de uma falha real. É o único dos três que não interrompe nada — e por isso é o mais fácil de passar despercebido.

Onde ver o histórico

SELECT database_id, file_id, page_id, event_type, error_count, last_update_date
FROM msdb.dbo.suspect_pages
ORDER BY last_update_date DESC;

Toda página que gerou 823, 824 ou 825 fica registrada aqui — não é preciso vasculhar o ERRORLOG pra saber se já aconteceu antes.

Ação imediata

Rode DBCC CHECKDB pra dimensionar o dano. Se for corrupção pontual em poucas páginas e existir um backup íntegro, RESTORE PAGE resolve sem precisar restaurar o banco inteiro. Qualquer um dos três é motivo pra revisar a saúde física do storage, não só o banco.

Antes de precisar restaurar: confirme que o backup está íntegro e em dia →

Artigos relacionados

Veja como a codeDB mede a disponibilidade real do ambiente

Estados UP/DOWN/UNKNOWN, sem métrica inventada — 30 dias grátis.

Começar gratuitamente
codeDB

Monitoramento inteligente de SQL Server com agente local seguro e diagnósticos em tempo real.

Produto

RecursosPreçosComparativoscodeDB Lens (grátis)

© 2026 codeDB. Todos os direitos reservados.

Powered by codeDB

codeDB Informática Ltda — CNPJ 18.953.756/0001-10 — Florianópolis/SC