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

Msg 8951, Level 16, State 1, Line 1
Table error: table 'NomeTabela' (ID XXXX). Data row does not have a matching index row in the index 'NomeIndice' (ID YYYY). Possible missing or invalid keys for the index row matching:

Msg 8955, Level 16, State 1, Line 1
Data row (Z:ZZZZZ:ZZ) identified by (NomeColuna1 = valor1) with index value '...'

CHECKDB found 0 allocation errors and 2 consistency errors in table 'NomeTabela' (object ID XXXX).
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Msg 8951, Level 16, State 1, Line 1

Table error: table 'NomeTabela' (ID XXXX). Data row does not have a matching index row in the index 'NomeIndice' (ID YYYY). Possible missing or invalid keys for the index row matching:

Msg 8955, Level 16, State 1, Line 1

Data row (Z:ZZZZZ:ZZ) identified by (NomeColuna1 = valor1) with index value '...'

CHECKDB found 0 allocation errors and 2 consistency errors in table 'NomeTabela' (object ID XXXX).

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

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:

USE master
GO
DBCC CHECKDB('NomeDatabase')

USE master

DBCC CHECKDB('NomeDatabase')

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

DBCC results for 'NomeTabela'

Msg 8951, Level 16, State 1, Line 1
Table error: table 'NomeTabela' (ID 610101214). Data row does not have a matching index row in the index 'NomeIndice' (ID 4). Possible missing or invalid keys for the index row matching:

Msg 8955, Level 16, State 1, Line 1
Data row (1:59380:31) identified by (NomeColuna1 = valor1) with index value '...'

Msg 8951, Level 16, State 1, Line 1
Table error: table 'NomeTabela' (ID 610101214). Data row does not have a matching index row in the index 'NomeIndice' (ID 4). Possible missing or invalid keys for the index row matching:

Msg 8955, Level 16, State 1, Line 1
Data row (1:59380:32) identified by (NomeColuna1 = valor2) with index value '...'

There are 1294 rows in 33 pages for object 'NomeTabela'

CHECKDB found 0 allocation errors and 2 consistency errors in table 'NomeTabela' (object ID 610101214).
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC results for 'NomeTabela'

Msg 8951, Level 16, State 1, Line 1

Table error: table 'NomeTabela' (ID 610101214). Data row does not have a matching index row in the index 'NomeIndice' (ID 4). Possible missing or invalid keys for the index row matching:

Msg 8955, Level 16, State 1, Line 1

Data row (1:59380:31) identified by (NomeColuna1 = valor1) with index value '...'

Msg 8951, Level 16, State 1, Line 1

Table error: table 'NomeTabela' (ID 610101214). Data row does not have a matching index row in the index 'NomeIndice' (ID 4). Possible missing or invalid keys for the index row matching:

Msg 8955, Level 16, State 1, Line 1

Data row (1:59380:32) identified by (NomeColuna1 = valor2) with index value '...'

There are 1294 rows in 33 pages for object 'NomeTabela'

CHECKDB found 0 allocation errors and 2 consistency errors in table 'NomeTabela' (object ID 610101214).

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

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:

CHECKDB found 0 allocation errors and 2 consistency errors in table 'NomeTabela' (object ID 610101214).

1	CHECKDB found 0 allocation errors and 2 consistency errors in table 'NomeTabela' (object ID 610101214).

Como podemos ver, temos dois erros de consistência na tabela ‘NomeTabela’. 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:

USE NomeDatabase

SELECT * 
FROM sys.objects
where object_id = 610101214

USE NomeDatabase

SELECT *

FROM sys.objects

where object_id = 610101214

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’.

Msg 8951, Level 16, State 1, Line 1
Table error: table 'NomeTabela' (ID 610101214). Data row does not have a matching index row in the index 'NomeIndice' (ID 4). Possible missing or invalid keys for the index row matching:

1 2	Msg 8951, Level 16, State 1, Line 1 Table error: table 'NomeTabela' (ID 610101214). Data row does not have a matching index row in the index 'NomeIndice' (ID 4). Possible missing or invalid keys for the index row matching:

“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. =(

ALTER INDEX [NomeIndice] ON [dbo].[NomeTabela] REBUILD

1	ALTER INDEX [NomeIndice] ON [dbo].[NomeTabela] REBUILD

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.

USE NomeDatabase

CREATE NONCLUSTERED INDEX [NomeIndice]
ON [NomeSchema].[NomeTabela]([NomeColuna1],[NomeColuna2],[NomeColuna3],...)
INCLUDE(ColunaInclude1, ColunaInclude2, ...)
WITH(FILLFACTOR = 90, DATA_COMPRESSION = PAGE)
GO

USE master
GO

DBCC CHECKDB('NomeDatabase')

USE NomeDatabase

CREATE NONCLUSTERED INDEX [NomeIndice]

ON [NomeSchema].[NomeTabela]([NomeColuna1],[NomeColuna2],[NomeColuna3],...)

INCLUDE(ColunaInclude1, ColunaInclude2, ...)

WITH(FILLFACTOR = 90, DATA_COMPRESSION = PAGE)

USE master

DBCC CHECKDB('NomeDatabase')

Dessa vez o problema finalmente foi resolvido! O CHECKDB retornou a mensagem com 0 erros!!! WOW!!! YOU WIN!!! =)

CHECKDB found 0 allocation errors and 0 consistency errors in database 'NomeDatabase'.
DBCC execution completed. If  DBCC printed error messages, contact your system administrator.

1 2	CHECKDB found 0 allocation errors and 0 consistency errors in database 'NomeDatabase'. DBCC execution completed. If DBCC printed error messages, contact your system administrator.

“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

Alerta Corrupção de Dados:

DBCC CHECKDB:

Investigando o problema:

Resolvendo o problema:

Conclusão:

Compartilhe isso:

Deixe uma respostaCancelar resposta