Casos do Dia a Dia – Corrupção Banco de Dados – Índice Nonclustered

Fala pessoal,

No post de hoje, vou explicar como você pode analisar e resolver um problema de corrupção de dados em um índice nonclustered. #gogogo


Alerta Corrupção de Dados:

Estava eu em mais um plantão de DBA no final de semana feliz da vida (afinal, DBAs adoram trabalhar no FDS, certo?) e de repente recebo o ALERTA abaixo:

“Ferrou Luiz, a casa caiu! Não faço ideia de como resolver esse problema!!! E agora??? Passo direto no RH???”

A primeira DICA muito importante é: MANTENHA A CALMA!!!


DBCC CHECKDB:

“Beleza Luiz, já estou mais calmo agora. Por onde devo começar???”

Vamos lá, o primeiro passo será executar um CHECKDB para tentar identificar mais algumas informações sobre a causa raiz do nosso problema. Esse comando é utilizado para validar a integridade do seu banco de dados. Ele consome bastante I/O e pode gerar uma certa lentidão dependendo do tamanho do seu banco de dados / hardware e pode demorar um pouco também.

Recomendo que execute o CHECKDB em bases grandes na produção apenas em casos críticos como esse ou em uma janela maior para as rotinas de manutenção do banco de dados (por exemplo, durante a madrugada).

Se você nunca ouviu falar sobre o comando CHECKDB, segue abaixo um link com mais informações:

https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkdb-transact-sql?view=sql-server-ver15

Então vamos ao que interessa! Primeiro, executei o CHECKDB da seguinte forma:

OBS: Eu troquei algumas informações nas mensagens abaixo para não expor os dados do cliente.


Investigando o problema:

“OK, Luiz! Até aqui tudo bem! Agora tem um monte de mensagem em inglês que eu nunca vi na minha vida!!! O que faço agora???”

Novamente, tenha CALMA jovem!!! Vamos usar a técnica de dividir para conquistar!

Vamos começar pelo final da mensagem:

Como podemos ver, temos dois erros de consistência na tabelaNomeTabela’. Essa mensagem já ajudou bastante, porque já temos uma pista de onde está o nosso problema!

Se você conseguir apenas o ID do objeto, você também pode tentar identifica-lo da forma abaixo:

Beleza, o próximo passo será validar os detalhes desses dois erros. Com o resultado do CHECKDB, ficou bem claro também que o problema está em um índice específico ‘NomeIndice’.

“Caramba Luiz, essas mensagens em inglês já nos deram um bom caminho do que deve ser analisado!”

Pois é! Agora vamos validar qual o tipo desse índice e as colunas que ele contém. Para isso, vamos utilizar o script do link abaixo:

https://github.com/luizvitorf/SQLServer/blob/master/Scripts/Tuning/Informa%C3%A7%C3%B5es%20completas%20dos%20%C3%ADndices%20de%20uma%20tabela.txt

Ele retorna diversas informações sobre os índices de uma tabela e é muito útil no meu dia a dia.

Com isso, consegui identificar que o problema era em um ÍNDICE NONCLUSTERED. Isso também ajuda muito, pois esse tipo de índice utiliza uma estrutura separada que podemos recriar sem afetar os dados originais da tabela.

Se ele fosse um ÍNDICE CLUSTERED, aí o buraco seria mais embaixo, pois esse índice contém os dados da tabela. Esse caso específico não será tratado nesse post OK!

Se você não sabe a diferença entre um índice CLUSTERED e NONCLUSTERED, segue abaixo algumas referências:

  • Fabrício Lima – Vídeo: Breve introdução sobre índices – Heap, Clustered e Nonclustered

https://www.youtube.com/watch?v=lPwjhtHEfw0&t=14s

  • Documentação Oficial da Microsoft:

https://docs.microsoft.com/pt-br/sql/t-sql/statements/create-index-transact-sql?view=sql-server-ver15

Resumindo: Com o nosso CSI para resolver essa bendita corrupção, agora já identificamos os seguintes pontos:

  • Descobrimos o nome da tabela;
  • Descobrimos o nome do índice;
  • Descobrimos que é um índice NONCLUSTERED.

Resolvendo o problema:

Agora vamos partir para a resolução do problema!!!

Minha primeira tentativa foi tentar fazer um REBUILD para recriar o índice e ver se o problema seria resolvido. Depois executei um CHECKDB, mas o resultado foi o mesmo do início. =(

Na segunda tentativa eu tive que “apelar” um pouco e fiz o seguinte:

  • Verifiquei todas as colunas do índice e preparei o script para recriá-lo (lembrar de validar se tem alguma coluna no INCLUDE também!).
  • Dropei o índice. OBS: Aqui você precisa validar se vai conseguir fazer isso no horário de produção ou em outra janela pra não gerar muito impacto no ambiente. No meu caso, a tabela tinha poucos registros e estava sendo pouco utilizada. Com isso, consegui fazer durante o dia mesmo.
  • Recriei o índice e executei novamente o CHECKDB.
  • Dessa vez o problema finalmente foi resolvido! O CHECKDB retornou a mensagem com 0 erros!!! WOW!!! YOU WIN!!! =)

“TOOOP Luiz!!! Na próxima vez vou ficar mais calmo e seguir esses passos antes de ficar desesperado logo no início!”


Conclusão:

Como podemos ver, a Corrupção de Dados é sempre muito temida pelos DBAs, mas nem sempre ela é tão complicada como parece ser.

Existem alguns casos que são um pouco mais “simples”, como foi nesse caso do índice NONCLUSTERED, onde só precisamos dropar e recriar o índice e o problema foi resolvido.

Verifique também se os seus BACKUPs estão em dia, pois eles podem nos salvar de alguma corrupção de dados que seja mais complexa e sem volta.

Como dica final eu gostaria de reforçar que você tem que ter MUITA CALMA nesse momento e tome cuidado para não executar algum procedimento onde você possa perder dados do cliente, pois isso é muito crítico!


Espero que tenha gostado e que isso também possa ser útil no seu dia a dia. Até o próximo post!

Me siga no LinkedIn e YouTube para ficar por dentro das novidades.

Abraço,

Luiz Vitor França Lima

Consultor SQL Server

Deixe uma resposta