Em meu artigo anterior sobre Alertas do SQL Server Agent, forneci instruções passo a passo sobre como configurar e configurar alertas do SQL Agent para erros de alta gravidade 19-25, bem como para o erro 825. Neste artigo, vou discuta esses erros em detalhes e compartilhe o que você deve fazer se eles ocorrerem em seu ambiente.
Erros com um nível de gravidade de 19 ou superior impedem a conclusão do lote atual. Erros com uma gravidade de 20 e superior são erros fatais e encerram a conexão do cliente atual. Esses erros também podem afetar todos os processos no banco de dados. Erros fatais são exatamente o que o nome indica:o processo em execução é encerrado e a conexão do cliente é fechada.
Erros de gravidade 19
Um erro de gravidade 19 é um erro devido à falta de um recurso. Isso significa que um limite interno (que você não pode configurar) foi excedido e fez com que o lote atual terminasse. Esses erros raramente ocorrem e há pouco que você pode fazer para corrigir o problema. Se ocorrer um erro de gravidade 19, você deve entrar em contato com seu provedor de suporte principal; normalmente, seria a Microsoft.
Em todos os meus anos de trabalho com o SQL Server, não consigo me lembrar de nenhum incidente em que um erro de gravidade 19 tenha sido gerado. Mesmo pesquisando no Bing, tive problemas para encontrar ocorrências do erro; as poucas referências que encontrei estavam relacionadas a uma versão inicial do SQL Server e referenciavam um bug dentro do próprio SQL Server.
Erros de gravidade 20
Um erro de gravidade 20 é um erro fatal no processo atual. Isso indica que uma instrução encontrou um problema e foi encerrada. Como isso afeta apenas o processo atual, é muito improvável que o próprio banco de dados tenha sido danificado. Esses erros estão vinculados a uma instrução individual, portanto, você precisará coletar toda a mensagem de erro e entrar em contato com a pessoa ou equipe responsável por esse pedaço de código. Isso pode ser interno ou possivelmente o fornecedor do aplicativo. Um exemplo de erro é:
Erro:18056, Gravidade 20, Estado:29
O cliente não pôde reutilizar uma sessão com SPID 123, que foi redefinida para pool de conexões.
Para esse erro, eu entraria em contato com o desenvolvedor ou fornecedor do aplicativo, pois o erro está relacionado a uma conexão em pool que encontra um erro ao tentar redefinir. Eu também revisaria os logs do SQL Server, que podem ter uma mensagem de erro mais detalhada sobre o que realmente está acontecendo para causar o erro.
Erros de gravidade 21
Um erro de gravidade 21 é um erro fatal no banco de dados que afeta todos os processos que usam esse banco de dados.
Eu vi esse erro ocorrer ao tentar restaurar um banco de dados usando recursos Enterprise para uma instância do Standard Edition, bem como quando um banco de dados está corrompido e o usuário tenta acessar uma página corrompida. Um exemplo de mensagem de erro desse tipo é:
Erro:605, Gravidade:21, Estado 1
Tentativa de buscar página lógica (1:8574233) no banco de dados 'DB_NAME' pertence ao objeto '0', não ao objeto 'Table01'.
Ao tentar restaurar um banco de dados que está usando recursos Enterprise para uma instância Standard Edition, você terá que primeiro remover os recursos Enterprise. Por exemplo, se você estiver usando compactação de dados ou captura de dados alterados, primeiro será necessário parar de usar e remover esses recursos do banco de dados, fazer backup do banco de dados e restaurá-lo na instância Standard Edition. Você pode usar o DMV
sys.dm_db_persisted_sku_features para verificar se você tem algum recurso exclusivo do Enterprise em uso. Para os erros de corrupção, você precisará executar
DBCC CHECKDB determinar a extensão da corrupção e partir daí. Se você tiver sorte, o erro estará em um índice não clusterizado que você pode reconstruir e resolver o problema. Se a corrupção for mais grave, você pode estar analisando uma operação de restauração. Para entender melhor a corrupção e como resolver vários aspectos da corrupção, encorajo você a revisar as várias postagens do blog de Paul Randal. Paul tem uma categoria inteira sobre corrupção que você pode ver aqui:- http://www.sqlskills.com/blogs/paul/category/corruption/
Executando
DBCC CHECKDB como parte de um trabalho agendado regularmente em seus bancos de dados, é altamente recomendável detectar a corrupção o mais cedo possível. Se você não estiver verificando regularmente se há corrupção, corre um grande risco de não conseguir recuperar os dados corrompidos. Erros de gravidade 22
Um erro de gravidade 22 é um erro fatal devido à suspeita de integridade da tabela, basicamente indicando que a tabela ou o índice especificado na mensagem está danificado. A corrupção acontece e acontece com frequência. Nossa experiência é que a maioria da corrupção ocorre devido a um problema relacionado ao subsistema de E/S. Se você encontrar um erro de gravidade 22, precisará executar
DBCC CHECKDB para determinar a extensão do dano. Um exemplo de erro é:Erro:5180, Gravidade:22, Estado:1
Não foi possível abrir XYZ para ID de arquivo inválido ## no banco de dados. Tabela ou banco de dados pode estar corrompido.
Se o erro estiver em um índice não clusterizado, você poderá reconstruir o índice e corrigir a corrupção. Se a corrupção estiver em um heap ou índice clusterizado, você precisará restaurar o banco de dados para um estado consistente.
Eu vi relatórios em que a corrupção estava na memória, mas não no disco. Nesse caso, uma reinicialização da instância ou a configuração do banco de dados offline e depois online deve eliminar o erro.
Erros de gravidade 23
Um erro de gravidade 23 é outro erro fatal que informa que o próprio banco de dados tem um problema de integridade. A resolução é muito parecida com a de um erro de gravidade 22, onde você precisa executar imediatamente
DBCC CHECKDB para encontrar a extensão total do dano ao banco de dados. Esse nível de corrupção é detectado como afetando todo o banco de dados. Isso pode ser corrupção no próprio arquivo de dados ou corrupção no arquivo de log. Os detalhes do erro o direcionarão para a raiz do problema. Por exemplo, o erro a seguir indica que precisaríamos restaurar nosso banco de dados ou tentar reconstruir o log. Para consistência, eu restauraria do meu backup mais recente e de todos os backups de log de transações disponíveis.
Erro:9004, Gravidade:23 Estado:6
Ocorreu um erro ao processar o log do banco de dados 'db_name'. Se possível, restaure a partir do backup. Se um backup não estiver disponível, pode ser necessário reconstruir o log.
Erros de gravidade 24
Um erro de gravidade 24 é um erro fatal relacionado a um hardware. Esta mensagem ocorreria devido a algum tipo de falha de mídia. O mais comum desses tipos de erros que vi estão relacionados a problemas com erros de memória e de E/S. Por exemplo:
Erro:832, Gravidade:24, Estado:1
Uma página que deveria ser constante foi alterada (soma de verificação esperada:
Quando ocorrerem erros como esse, você deve entrar em contato com a equipe de suporte do sistema para executar o teste de memória em seu servidor e fazer uma boa verificação de integridade do servidor. Esse erro pode ser memória ruim ou um scribbler de memória (um processo do kernel ou algo que está alterando a memória do SQL Server).
Outro exemplo:
Erro:824, Gravidade:24, Estado:2
O SQL Server detectou um erro de E/S baseado em consistência lógica:ID de página incorreto (esperado 1:123; real 0:0). Ocorreu durante uma leitura de página (1:123) no ID do banco de dados
Este erro indica um erro de consistência no arquivo de dados primário do banco de dados. Você precisaria executar imediatamente
DBCC CHECKDB para determinar a extensão da corrupção e tomar as medidas apropriadas para reparar ou restaurar o banco de dados. Erros de gravidade 25
Um erro de gravidade 25 é um erro fatal do sistema. Ouvi dizer que a gravidade 25 é mais ou menos uma pegada para erros fatais diversos. Eu só vi esse erro quando relacionado a atualizações com falha:algo impede que um dos scripts de atualização seja executado e um erro de gravidade 25 é lançado. Você receberia um erro semelhante a:
A atualização de nível de script para o banco de dados 'mestre' falhou porque a etapa de atualização 'sqlagent90_sysdbupg.sql' encontrou o erro 598, estado 1, gravidade 25. Esta é uma condição de erro grave que pode interferir na operação regular e o banco de dados será colocado offline. Se o erro ocorreu durante a atualização do banco de dados 'mestre', ele impedirá que toda a instância do SQL Server seja iniciada. Examine as entradas anteriores do log de erros em busca de erros, execute as ações corretivas apropriadas e reinicie o banco de dados para que as etapas de atualização do script sejam executadas até a conclusão.
Nesse caso, os erros anteriores a essa mensagem indicavam um caminho incorreto para o local de dados padrão do SQL Server. Depois que isso foi corrigido, a atualização foi executada com sucesso.
Erro 825
O erro 825 geralmente é chamado de aviso de repetição de leitura, mas a condição é para operações de leitura e gravação. Esse erro informa que uma nova tentativa da operação foi necessária e quantas vezes o SQL Server teve que repetir a tentativa antes de ser bem-sucedida. O SQL Server repetirá as operações até quatro vezes, após quatro tentativas, ele gerará um erro 823 ou 824. As mensagens de erro 825 serão semelhantes às seguintes:
Uma leitura do arquivo 'path to file name\db_name.mdf' no deslocamento 0x00000002000 foi bem-sucedida após falhar 2 vezes com erro:checksum incorreto (esperado:XYZ; ABC real). Mensagens adicionais no log de erros do SQL Server e no log de eventos do sistema podem fornecer mais detalhes. Essa condição de erro ameaça a integridade do banco de dados e deve ser corrigida. Conclua uma verificação completa de consistência do banco de dados (DBCC CHECKDB). Esse erro pode ser causado por vários fatores; para obter mais informações, consulte os Manuais Online do SQL Server.
Essas mensagens são importantes, pois indicam que você tem um problema maior com o subsistema de disco. Os métodos de solução de problemas seriam executar
DBCC CHECKDB para garantir que o banco de dados seja consistente, conforme recomendado pelo erro, bem como revisar os logs de eventos do Windows em busca de erros do sistema operacional ou dos dispositivos de armazenamento. Você deve fazer com que sua equipe de suporte de armazenamento e hardware revise também o subsistema de E/S subjacente em busca de erros. Resumo
Ter os alertas do SQL Agent configurados é gratuito e fácil. Ser proativo e responder a esses alertas é importante para ajudar a minimizar o tempo de inatividade para você e seus clientes. Como você aprendeu, muitas coisas podem afetar o SQL Server e a consistência de seus bancos de dados, e a melhor defesa para poder se recuperar desses erros é ter bons backups e conhecer as várias opções de reparo para
DBCC CHECKDB . É sempre recomendado executar DBCC CHECKDB regularmente em seus bancos de dados para detectar a corrupção o mais cedo possível, pois quanto mais rápido você encontrar a corrupção, maior a probabilidade de fazer backup dos dados para que você possa restaurar sem perda de dados. 
