Neste artigo, compartilho um caso interessante que atendi há alguns meses. Um cliente abriu um chamado no nosso help desk relatando um problema crítico: ao tentar realizar o backup de uma base de dados, um erro indicava que o arquivo estava corrompido. Diante desse cenário, decidi abordar neste artigo os detalhes dessa situação, como identificamos a causa do problema e as lições aprendidas para evitar erros semelhantes.
Nota: Todos os dados e informações utilizados neste artigo são fictícios e têm o único propósito de ilustrar o caso descrito e compartilhar conhecimento técnico.
Utilizando uma base de dados que eu tinha para testes, simulei o problema. Uma das primeiras ideias que tive foi realizar o backup da utilizando a função CHECKSUM, como opção de verificação de páginas. Durante o processo de backup o SQL Server calcula as somas de verificação (Checksums) das páginas de dados enquanto elas são carregadas para o arquivo de backup. Durante esse processo, valores de hash são gerados, e comparados com os checksums armazenados nas páginas. Se houver qualquer discrepância entre os valores calculados e esperados a operação de backup é interrompida com falha, indicado uma possível corrupção nos dados.
Também utilizei a opção RESTORE VERIFYONLY, um comando T-SQL que verifica a integridade do backup e simula se ele pode ser restaurado, validando os checksums presentes nas páginas de dados.
Na imagem anterior, é possível observar que, embora o processo de backup avance até os 90%, um erro é apresentado antes da conclusão, mais especificamente na página (3:6908140). Onde 3 Representa o número do DataFile que contém a página corrompida, enquanto 6908140 representa o número da página que está corrompida dentro desse arquivo.
Com essas informações, já era possível avançar na análise e planejar um troubleshooting detalhado. No entanto, decidi aprofundar a investigação utilizei a trace flag 3604 em conjunto com o comando DBCC PAGE para obter mais detalhes sobre os erros.
É importante destacar que, em versões mais recentes do SQL Server, o comando DBCC PAGE já retorna diretamente os detalhes necessários, sem a necessidade de habilitar a trace flag.
Analisando o erro exibido na imagem abaixo, é possível obter mais informações, como o ID da unidade de alocação, o ID do índice e o ID do objeto, que corresponde à tabela relacionada.
O DBCC TRACEON, foi utilizado para habilitar o trace (3604), e exibir mais detalhes sobre o erro, o DBCC PAGE(6, 3, 6908140, 3) onde o número 6 representa o ID do banco de dados que estou verificando, o número 3 representa o número do DataFile, o número 6908140 representa a página que está corrompida dentro do DataFile, enquanto o número 3 que está na última posição do comando DBCC PAGE, exibe uma quantidade maior de detalhes, mostrando informações internas como dados, índices, e outros componentes, e por fim DBCC TRACEOFF para desabilitar o trace.
Utilizando a Dynamic management view (DMV) sys.objects em conjunto com a sys.indexes, e aplicando como filtro o Object ID identificado através do comando DBCC PAGE, foi possível localizar o nome da tabela associada ao erro. Nesse caso, tratava-se da Tabela1, como evidenciado na coluna ObjectName:
Utilizando as DMVs sys.objects em conjunto com sys.indexes, sys.partitions e sys.allocation_units, e aplicando filtros baseados no Object ID e Partition ID obtidos através do comando DBCC PAGE, foi possível identificar informações mais detalhadas, como o nome da tabela, o nome do índice e o ID do índice associado ao erro. Por fim, consegui localizar exatamente onde estava o problema, como podemos observar na imagem a seguir:
Com todas as informações em mãos, apliquei filtros na base de dados para localizar a tabela e o índice relacionado ao erro. Utilizei a interface do SQL Server Management Studio (SSMS), para filtrar o nome da tabela identificada e o nome do índice associado a tabela, como podemos observar na imagem a seguir:
Na etapa de troubleshooting, foi executado o comando REBUILD no índice. No entanto, essa abordagem não foi eficaz neste cenário, pois a operação de REBUILD apenas reconstrói a estrutura do índice, mas não resolve corrupções presentes nas páginas de dados que o índice utiliza como referência. O erro identificado está relacionado a uma corrupção lógica, mais especificamente no checksum de uma página de dados associada ao índice. O checksum é uma verificação de integridade dos dados, e, neste caso, o valor esperado não corresponde ao valor retornado, indicando inconsistência, como mostrado na imagem a seguir:
De imediato, optei pela segunda abordagem: gerar o script do índice utilizando a interface do SQL Server Management Studio (SSMS), salvar o script do índice existente, remover o índice corrompido e, em seguida, recriá-lo. Esta abordagem é útil para corrigir corrupções lógicas, reconstituir a estrutura física do índice e, assim, resolver problemas relacionados à integridade de dados.
Recriar o índice pode corrigir certos tipos de corrupção lógica, pois ele gera uma nova estrutura física para o índice, baseada nos dados disponíveis. Durante a recriação, o SQL Server cria novas páginas de índice, ignorando as corrompidas ou com erro de checksum. Esse processo elimina a corrupção existente, gerando uma estrutura consistente e corrigindo o erro apresentado via checksum. A seguir, podemos observar na imagem que o índice foi criado com sucesso:
Após a recriação do índice, o problema foi resolvido. Aproveitando uma janela de manutenção no final de semana, validei a integridade da base de dados executando o comando: DBCC CHECKDB('CorruptTABLE') WITH NO_INFOMSGS, ALL_ERRORMSGS. O parâmetro NO_INFOMSGS suprime mensagens informativas, enquanto ALL_ERRORMSGS exibe apenas as mensagens de erro relevantes. Com isso, foi possível confirmar que a base de dados está íntegra.
O problema foi inicialmente identificado durante o processo de backup, que, apesar disso, foi concluído com sucesso após realizadas as devidas tratativas. Todas as alterações necessárias foram aplicadas primeiro na base de testes e, posteriormente, na base de produção do cliente, resolvendo o problema do arquivo corrompido.
Recomendações e boas práticas:
- Durante o processo de backup é recomendado utilizar CHECSUM, garantindo a verificação da integridade dos dados.
- Utilizar o CHECKDB para fazer a verificação da integridade dos dados, preferencialmente durante uma janela de manutenção ou no final de semana, para evitar impacto em ambientes concorridos.
- Utilizar o RESTORE VERIFYONLY, para validar os checksums, e verificar se o backup pode ser restaurado.
- Habilitar a opção Page Verify = CHECSUM, a nível de base de dados.
Dicas:
- Análise criteriosa acelera o troubleshooting. Por exemplo, ao enfrentar um problema de corrupção em uma base de 400 GB, rodar um CHECKDB de imediato poderia identificar o erro, mas também exigiria uma janela apropriada para evitar impacto em um ambiente de produção com alta concorrência.
- Pesquisar as mensagens de erro no Google, ler artigos, consultar a documentação oficial da Microsoft e compartilhar dúvidas com outros profissionais são estratégias valiosas para resolver problemas complexos. Além disso, aprofundar-se na arquitetura do banco de dados, conhecer também DMVs, Hints, o básico de Internals, poder ajudar muito na identificação de soluções, e melhora o conhecimento.
Para automatizar e garantir a consistência dessas rotinas de manutenção em ambientes híbridos, veja também como configurar o Backup do SQL Server no Azure Storage usando a rotina do Ola Hallengren.
Referências:
Comentários
Postar um comentário
Deixe seu comentário, sua opinião é muito importante para aprendermos juntos, Obrigado!!!