SQL Server DBCC CHECKDB Visão Geral

Por: Brady Upton | Actualizado: 2016-07-26 | Comentários (2) | Relacionado: Mais > Comandos da Consola de Base de Dados DBCCs

Problema

Corrupção da Base de Dados do ServidorSQL pode ser um problema e pode causar sérios danos a uma base de dados. Se você é um DBA experiente então você provavelmente tem salvaguardas para detectar isso, mas ao longo dos anos eu vi centenas de servidores SQL sem nenhum método de detecção e isso é um problema. Existem algumas maneiras de detectar a corrupção de bases de dados, mas esta dica focará mais no DBCC CHECKDB.

Solution

Você pode ou não ter ouvido falar de instruçõesDBCC (comandos do console do banco de dados). Essas instruções são usadas para realizar operações diferentes em seu banco de dados e podem ser divididas em quatro categorias: Manutenção, Diversos, Informações e Validação. Eu uso algumas das instruções DBCCstatements diariamente, mas nada mais que DBCC CHECKDB.

O que é o DBCC CHECKDB do SQL Server CHECKDB

DBCC CHECKDB, daMicrosoft MSDN Library, verifica a integridade lógica e física de todos os objetos no banco de dados especificado executando as seguintes operações:

• Executar o DBCC CHECKALLOC no banco de dados – Verifica a consistência das estruturas de alocação de espaço em disco para um banco de dados especificado.
• Executa o DBCC CHECKTABLE em cada tabela e visualização no banco de dados – Verifica a integridade de todas as páginas e estruturas que compõem a tabela ou visualização indexada.
• Executa o DBCC CHECKCATALOG na base de dados – Verifica a consistência do catálogo dentro da base de dados.
• Valida o conteúdo de cada vista indexada na base de dados.
• Valida a consistência em nível de linha entre metadados de tabelas e diretórios e arquivos do sistema de arquivos ao armazenar dados varbinários(max) no sistema de arquivos usandoFILESTREAM.
• Válida os dados do Service Broker no banco de dados

Se você já executou o DBCC CHECKDB você sabe que leva algum tempo para grandes bancos de dados.Agora que você sabe todos os passos que são executados, você pode ver porque leva tempo para ficar completo.

Como o DBCC CHECKDB do SQL Server pode me ajudar?

A corrupção de dados é ruim. Pode causar todo o tipo de problemas dentro do banco de dados, o que pode incluir resultados de dados incorretos, instruções SQL falhadas e, em alguns casos, pode derrubar a instância SQL inteira. O DBCC CHECKDB avisa sobre corrupção para que você possa corrigi-la antes que (esperançosamente) ela fique muito ruim.

Como eu uso o DBCC CHECKDB do SQL Server?

DBCC CHECKDB é bastante simples. Há algumas opções que você pode usar com a declaração e vamos rever algumas delas na próxima seção, mas a sintaxe básica é assim:

DBCC CHECKDB ('DatabaseName') 

Pretty simples.

Automate SQL Server DBCC CHECKDB

Obviamente, você não quer entrar todas as manhãs e executar esta declaração no eachdatabase, assim você pode automatizar este processo usando alguns métodos diferentes:

• Planos de manutenção do SQL Server -Planos de manutenção fazem parte do SQL Server fora da caixa (a menos que você esteja executando o ExpressEdition). Eu não gosto de usar planos de manutenção na maioria das vezes, mas não me importo de usá-los para este tipo de tarefa. Na caixa de ferramentas do Plano de Manutenção você precisará usar a tarefa Check Database Integrity. A única opção configurável é incluir índices para que não seja realmente fácil de usar, mas em alguns casos isso é tudo que você precisa. Novamente, falaremos sobre outras opções na próxima seção.

• Scripts personalizados – Scripts personalizados são normalmente o que eu uso e oferecem a melhor flexibilidade no que diz respeito a adicionar as opções que você deseja. Meus go-toscripts já estão criados e livres para uso do Ola Hallengren. Ele fez um trabalho maravilhoso de criá-los e compartilhá-los com o mundo. ObrigadoOla!
• Check out the scripts on MSSQLTips.com:
• Executar Manutenção com Bancos de Dados SQL Server em modo de Recuperação Total
• Planos de Manutenção de Bancos de Dados SQL Server e Gerenciamento de Arquivos de Backup
• Executar Manutenção SQL Server com Janela Sem Manutenção

>

Opções do DBCC CHECKDB Server DBCC CHECKDB doSQL

Existem algumas opções para usar com o DBCC CHECKDB e vou rever algumas delas mais populares aqui:

• NOINDEX – Especifica que não devem ser realizadas verificações intensivas de índices não incluídos para tabelas de usuários. Isto diminui o tempo de execução do overallex. NOINDEX não afeta as tabelas do sistema porque as verificações de integridade são sempre realizadas nos índices de tabela do sistema.
• NO_INFOMSGS – Suprime todas as mensagens de informação.
• PHYSICAL_ONLY – Limita a verificação à integridade da estrutura física da página e cabeçalhos de registros e à consistência da alocação do banco de dados. Esta verificação é projetada para fornecer uma pequena verificação da consistência física do banco de dados, mas também pode detectar páginas rasgadas, falhas de checksum e falhas comuns de hardware que podem comprometer os dados de um usuário.
• TABLOCK – Faz com que o DBCC CHECKDB obtenha bloqueios ao invés de usar um instantâneo interno do banco de dados. Isto inclui um (X)lock exclusivo de curto prazo na base de dados. TABLOCK fará com que o DBCC CHECKDB seja executado mais rapidamente em um banco de dados sob carga pesada, mas diminui a concorrência disponível no banco de dados enquanto o DBCC CHECKDB estiver rodando.
• DATA_PURITY – Faz com que o DBCC CHECKDB verifique o banco de dados antes dos valores da coluna que não são válidos ou fora da faixa de variação. Por exemplo, o DBCC CHECKDB detecta colunas com valores de data e hora que são maiores ou menores do que o intervalo aceitável para o tipo de dados de data e hora; ou colunas do tipo decimal ou aproximado-numérico com valores de escala ou precisão que não são válidos.

Vamos rever algumas das opções REPAIR em uma seção diferente abaixo.

Quantas vezes devo verificar se há corrupção no SQL Server?

Cada minuto de cada dia. Estava a brincar.

Se você tem uma janela de manutenção diária, seria bom checar por corrupção de dados diariamente. Quanto mais rápido o conseguires apanhar, menos danos poderá causar. Reparei que um loto de pessoas correm isto no fim-de-semana, especialmente com bases de dados maiores. Não há certo ou errado com isso, apenas certifique-se de que você tenha isso agendado periodicamente.

Tenho que executar o DBCC CHECKDB no meu ambiente de Produção?

Não, bem Sim. Para verificar se há corrupção de dados, não adianta executar o DBCC CHECKDB no seu ambiente de teste…SEM a necessidade de ter uma cópia do seu ambiente de produção para testar e depois executá-lo. BRILLIANT!

Você pode estar questionando se algumas opções de HA são adequadas como AlwaysOn, LogShipping, etc.? Não, você precisa verificar seu ambiente de produção *live*.

Agora o DBCC CHECKDB está configurado e rodando, o que eu estou procurando?

Congratulações! Você tem o DBCC CHECKDB automatizado e em execução, mas e agora? Se você tem um ServidorSQLAgent Job setup então certifique-se de configurar o DBCC CHECKDB, um operador, e uma notificação sobre o trabalho. Se o trabalho for bem sucedido, então continue com o seu belo dia. Se o trabalho falhar, então temos algum trabalho a fazer.

Você pode ver um erro como este:

ou this:

First, don’t panic. Segundo, verifique os backups. Os erros do DBCC CHECKDB normalmente dizem-lhe o que precisa de ser feito.

Para o primeiro erro um DBCC UPDATEUSAGE irá corrigir as imprecisões de contagem de páginas e linhas nas visualizações do catálogo. Bastante inofensivo.

O segundo erro reporta a corrupção de dados. O erro menciona usando repair_allow_data_lossas o nível mínimo de reparação. Isto significa que você pode executar a declaração com este argumento, mas você pode perder dados. É por isso que eu sempre recomendo a restauração para um backup se você puder. Você precisa ter certeza de que o backup não contém dados corrompidos e você quer ter certeza de que não há perda de dados.

Como reparar uma base de dados do SQL Server

Se você não tiver um backup, podemos precisar usar o DBCC CHECKDB com uma opção de reparo. Estas podem ou não funcionar e precisam ser usadas como último recurso:

• REPAIR_ALLOW_DATA_LOSS – Tenta reparar todos os erros reportados. Estas reparações podem causar alguma perda de dados.
• REPAIR_REBUILD – Efectua reparações que não têm qualquer possibilidade de perda de dados. Isto pode incluir reparos rápidos, tais como reparos de linhas ausentes em índices não inclusos, e reparos mais demorados, tais como reconstruir um índice.

Como eu disse acima, é muito importante ter backups atualizados para se recuperar da corrupção. Corrupção não importa quantos dados você tem, que versão do SQL você está rodando, ou o quanto seu datacenter é chique.

Sinto-me muito bem com isso, mas o que mais posso usar para proteger minhas substâncias SQL?

DBCC CHECKDB deve ser executado em cada instância SQL que você tem, mas há algumas outras maneiras que podem ajudar a detectar/prevenir a corrupção de dados.

• Alertas de Agente SQL Server – Brian Kelley escreveu uma boa dica sobre este topichere.
• Verificação de página – Certifique-se de que seus bancos de dados estão usandoCHECKSUM verificação de página. Se você ainda estiver rodando SQL 2005 ou abaixo disso não está disponível, mas depois de atualizar, certifique-se de alterar essa configuração. Para ver as configurações de pageverificação use a seguinte instrução:

select name, page_verify_option_desc from sys.databases 

Passos seguintes

• Certifique-se de verificar a Biblioteca daMSDN para obter mais detalhes sobre o DBCC CHECKDB
• MSSQLTips.com tem uma bela coleção de dicas sobre a Verificação de Consistência de Banco de Dados que podem ser úteis também.

Última Atualização: 2016-07-26

Sobre o autor

Brady Upton é um Administrador de Banco de Dados e superstar do SharePoint em Nashville, TN.
Ver todas as minhas dicas

Recursos relacionados

• Mais Dicas DBA Server SQL…