«

»

jun 15

Verificando e corrigindo a integridade dos dados

 

É possível encontrarmos problemas nos dados armazenados pelo SQL em seus arquivos de dados, tanto logicamente quanto fisicamente.

 

Neste artigo vamos conhecer melhor o DBCC CHECKDB do SQL Server que verifica e corrige possíveis problemas lógicos ou físicos, de acordo com os parâmetros aplicados.

 

A utilização pode ser bem simples:
DBCC DHECKDB(AdventureWorks2008R2)
GO


Se for executado desta forma e não houver problemas, o retorno será uma mensagem enorme, cheia de informações não muito úteis, exceto no final:

 

Começo do resultado

 

Final do resultado

 

Se houver um ou mais problemas, você poderá vê-los tanto na linha referente ao objeto com problema quanto no final da mensagem. Veja um exemplo de DBCC CHECKDB com problema. Com o programa XVI32 consegui alterar blocos do arquivo mdf que então ficou corrompido, veja que quando chegou no objeto DatabaseLog o SQL encontrou erros (em vermelho):

 

 

No final, uma informação importante: “repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (AdventureWorks2008R2)”.

Infelizmente é o que realmente significa. Só será possível reparar a base com perda de dados ou restaurando um backup anterior.

Vamos agora corrigir o problema que propositalmente causamos. Para começarmos, devemos alterar a base para SINGLE USER:

 

USE AdventureWorks2008R2
GO
ALTER DATABASE AdventureWorks2008R2
SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
DBCC DHECKDB(AdventureWorks2008R2,repair_allow_data_loss)
GO

 

Resultado da correção:

 

Com o DBCC CHECKDB podemos observar que o problema realmente foi corrigido, porém, houve perda de dados e não sabemos precisar quais dados foram perdidos (somente que são da tabela DatabaseLog):

Agora vamos rodar novamente para ver se realmente não há mais problemas no mdf:

 

 

Problema resolvido, zero allocation errors e zero consistency errors. Pena que perdeu dados 🙁

 

Não esqueça de voltar a base para MULTI USER:

 

ALTER DATABASE AdventureWorks2008R2
SET MULTI_USER
GO

 

Considere colocar em sua rotina no Maintenance Plan a execução do DBCC CHECKDB, assim você acompanha diariamente e não descobre que há erros na base só quando ela fica indisponível.

 

Se quiser saber mais sobre o DBCC CHECKDB, acesse o MSDN da Microsoft clicando aqui.

 .

1 comentário

  1. Ricardo Leka

    Olá,
    muito legal o post, só complementando o final, existem algumas alternativas para não perder essa massa de dados após o repair allow data loss:
    Se esta base estiver em mirror e o SQL for 2k8/2k8r2/2k12 e a página não for de meta dados, o SQL vai pedir para o mirror verificar se a mesma página não esta corrompida do lado dele, se ela não estiver, ele vai substituir esta página com a cópia do lado do mirror, na próxima operação que envolver esta página o usuário nem vai notar que havia um problema, neste caso a base fica online durante esta operação.
    Se possuirmos um backup válido, podemos restaurar apenas a página de dados que estava com problemas, não esquecendo que após o restore temos que fazer um backup de tail do log de restaurar esse log para a base conseguir ficar online, neste caso se for apenas um file group, vai tudo ficar offline, se a base possuir mais de 1 file group e a página corrompida não estiver no Primary e a versão do SQL Enterprise da pra tentar ficar online durante o restore.
    E na pior opção, se esta tabela é replicada de alguma forma, P2P, Log Shipping, etc., poderiamos utilizar um insert select de um lugar que tenha essa massa de dados válida não esquecendo de usar um set identity_insert on para não gerar outra atribuição de valores de identity.

    — ricardo leka

Deixe uma resposta