Quando o SQL Server escreve dados em suas unidades, ele apenas assume que está tudo bem até que precise ler os dados de volta.
Felizmente, no caso de corrupção do armazenamento, o armazenamento não é tão gentil a ponto de alertar o SQL Server. E, por vezes, o SQL Server até é conhecido por se corromper.
Precisamos de verificar periodicamente se os dados no disco ainda fazem sentido, e é aí que entra o DBCC CHECKDB. Ele verifica tanto os erros de alocação quanto os erros de consistência. Além disso, se houver algum problema, as mensagens de erro voltarão com informações sobre onde os erros existem, a gravidade do erro, bem como a opção de reparo sugerida.
É essencial executar CHECKDB regularmente para encontrar erros se eles existirem, porque se houver corrupção, precisamos corrigi-la antes que nossos últimos bons backups desapareçam.
Para encontrar o problema, verificamos cada base de dados para ter a certeza que o DBCC CHECKDB completou uma verificação bem sucedida nas últimas duas semanas.
Não Acredita?
“Mas eu corro CHECKDB o tempo todo”, você poderia dizer – bem, vamos descobrir:
|
1
|
DBCC DBINFO(‘StackOverflow’) COM TABLERESULTS
|
É isso. Mas a saída é um pesadelo. São cerca de 80 linhas de coisas que você provavelmente nunca vai se importar. Por volta da linha 50 é o que você está procurando.
Hi, eu sou um absurdo.
E isto é provavelmente o que você vai ver! Uma data de 1900-01-01, etc. Isso significa nunca. Se você executar o DBCC CHECKDB na base de dados, talvez assim:
|
1
|
>
DBCC CHECKDB(‘StackOverflow’) COM NO_INFOMSGS, ALL_ERRORMSGS
|
E depois executar novamente o comando DBCC DBINFO, a nossa data é agora actualizada para actual:
>
COMO A DIVERTIDÃO NÓS REALIZAMOS
Se a data não está a ser actualizada, isso significa uma de duas coisas: SQL Server não pode escrever no banco de dados (como se fosse somente leitura), ou está encontrando erros (hoowee, não é bom.)
Para corrigir o problema
Decida se você gostaria de usar planos de manutenção construídos, ou uma ferramenta livre como os scripts CHECKDB gratuitos de Ola Hallengren. Um par de considerações:
- Os planos de manutenção têm uma interface gráfica, caso você não saiba T-SQL.
- Os scripts livres de Ola Hallengren cuidam de opções de ajuste fino, como executar automaticamente verificações de pureza_de_dados (o que é uma coisa boa).
Como configurar a manutenção regular para verificar se há corrupção
Opção 1: Use um plano de manutenção para executar DBCC CHECKDB
Se estiver usando planos de manutenção, você pode editar planos de manutenção no SQL Server Management Studio em Management, Planos de Manutenção. Seu servidor pode ter vários planos de manutenção que executam CHECKDB para diferentes tipos de bancos de dados, como um para bancos de dados do sistema e um para bancos de dados de usuários.
Expandir o nó Administração em SSMS, clique com o botão direito do mouse em Planos de Manutenção e selecione Novo Plano.
Da janela Caixa de ferramentas, que às vezes fica oculta para a esquerda, arraste a tarefa Verificar integridade do banco de dados para o registro Plano de manutenção.
Quando clicar duas vezes na caixa Verificar tarefa de integridade do banco de dados no registro Plano de manutenção, será possível selecionar quais bancos de dados devem ser verificados durante o processo.
De lá, tudo o que resta é agendá-lo, que é como agendar um Trabalho de Agente.
Após salvar e fechar o plano de manutenção, certifique-se de encontrar o trabalho relacionado no Agente SQL Server e defina as propriedades de Notificação para que um operador saiba se ele falhar.
Opção 2: Configure os trabalhos do SQL Agent para executar o DBCC CHECKDB usando os scripts gratuitos de Ola Hallengren
E você está implementando verificações de integridade pela primeira vez, considere o uso dos scripts de manutenção gratuitos de Ola Hallengren. Eles não são tão fáceis como os planos de manutenção, mas são muito mais flexíveis. Eles também incluem a capacidade de dividir as operações do DBCC em pedaços menores para grandes bancos de dados. Em bancos de dados muito grandes CHECKDB pode levar uma quantidade significativa de tempo e recursos – a opção WITH PHYSICAL_ONLY é mais rápida, mas omite as verificações lógicas.
A partir do momento em que os trabalhos de Agente estão no lugar, você pode programá-los para rodar tão simplesmente como Planos de Manutenção, ou você pode ajustá-los com as opções adicionais documentadas aqui.