Introdução
A manutenção regular do banco de dados é uma parte importante do trabalho de um administrador de banco de dados que ajuda a garantir que os sistemas de importância crítica estejam funcionando normalmente. Uma das maneiras mais fáceis de fazer isso será automatizar tarefas relacionadas ao DBCC CheckDB. Não importa qual versão do SQL Server você esteja executando, nunca haverá um banco de dados que não exija manutenção. Você terá que planejar a manutenção regularmente para que possa cobrir suas costas, especialmente no momento de um cenário de desastre real.
DBA é sempre o culpado
Sempre que houver um problema no banco de dados, todos os olhos estarão no DBA. Se o problema foi causado por chuva ou devido a algum desenvolvedor escrever código desagradável resultando em lentidão no banco de dados, o DBA sempre deve corrigir a bagunça. E você pode imaginar o tipo de pressão que você precisa lidar se for solicitado a restaurar rapidamente um banco de dados usando o último backup disponível que, como você descobre no processo, não é válido e a integridade do banco de dados já foi comprometida há alguns meses atrás. Aqui reside a diferença entre um DBA proativo e um DBA reativo. Na realidade, sua estratégia de recuperação é muito mais crítica em comparação com a estratégia de backup. Para que servem os backups diários de banco de dados se não forem úteis no momento da restauração?
Por que a manutenção é importante?
Com o crescimento sem precedentes das tecnologias de banco de dados e com novos recursos aparecendo a cada lançamento, é imperativo que você, como DBA, fique à frente do resto e certifique-se de seguir as práticas recomendadas do setor em manutenção do banco de dados.
DBCC CheckDB e como podemos executá-lo
DBCC CheckDB – este nome é bastante descritivo da funcionalidade. Simplificando, ele verifica bancos de dados. Isso é importante para garantir que o banco de dados esteja funcionando conforme o esperado. Basicamente, o DBCC CheckDB verifica a integridade lógica e física de todos os objetos no banco de dados. Isto é o que o DBCC CheckDB faz sob o capô de acordo com o oficial Documentação da Microsoft:
Executa DBCC CHECKALLOC no banco de dados – a consistência das alocações de espaço em disco
Executa DBCC CHECKTABLE em todas as tabelas e visualizações no banco de dados – isso é a integridade de todas as páginas e estruturas que compõem a tabela ou visualização indexada.
Executa DBCC CHECKCATALOG no banco de dados – isso verifica a consistência do catálogo no banco de dados especificado.
Valida o conteúdo de cada exibição indexada no banco de dados.
Valida a consistência em nível de link entre metadados de tabela e diretórios/arquivos do sistema de arquivos ao armazenar dados varbinary(max) no sistema de arquivos usando FILESTREAM.
Valida os dados do Service Broker no banco de dados.
Quando você executa o comando DBCC CheckDB explicitamente ou por meio de um trabalho, ele basicamente faz todas as opções acima.
Executando o DBCC CheckDB diretamente em um banco de dados
Você pode executar o comando DBCC CheckDB diretamente em um banco de dados e verificar os resultados. Verifique a saída do comando conforme mostrado na captura de tela abaixo. A saída mostra os detalhes sobre as linhas nas tabelas e o número de páginas usadas por essas linhas.
Se você observar atentamente, verá mais detalhes específicos dos objetos de banco de dados. Por exemplo, no banco de dados “VLDB”, posso ver a seguinte saída:
“ID do objeto 1179151246 (objeto 'Warehouse.ColdRoomTemperatures'):A operação não é suportada com tabelas com otimização de memória. Este objeto foi ignorado e não será processado.”
Como esta saída mostra, DBCC CheckDB não é compatível com tabelas com otimização de memória. As tabelas com otimização de memória foram introduzidas pela primeira vez no SQL Server 2014 como um recurso somente para empresas. No entanto, ao longo dos anos, eles se tornaram uma funcionalidade popular e difundida no SQL Server.
Você também notará que o DBCC Check validou os dados do service broker no banco de dados conforme mostrado abaixo.
“Resultados DBCC para 'VLDB'.Service Broker Msg 9675, State 1:Tipos de mensagem analisados:14.Service Broker Msg 9676, State 1:Service Contracts analisados:6.Service Broker Msg 9667, State 1:Services analisados:3.Mensagem do Service Broker 9668, Estado 1:Filas de serviço analisadas:3.Mensagem do Service Broker 9669, Estado 1:Pontos de extremidade de conversa analisados:0.Mensagem do Service Broker 9674, Estado 1:Grupos de conversa analisados:0.Mensagem do Service Broker 9670, Estado 1:Ligações de serviço remoto analisadas:0.Service Broker Msg 9605, Estado 1:Prioridades de conversa analisadas:0.”
Finalmente, quando o comando DBCC CheckDB for concluído com êxito, você verá a seguinte saída:
O que acontece se os erros forem relatados após a execução do DBCC CheckDB?
No exemplo acima, você pode ver que DBCC CheckDB foi concluído sem erros. No entanto, se você não tiver tanta sorte, poderá encontrar erros de consistência – e esse será o momento em que você precisará tomar algumas decisões críticas. Se você se deparar com problemas em um banco de dados de produção, é melhor informar os proprietários da empresa ou seu gerente de operações para colocar suas cartas na mesa. Você pode dar a eles a opção de restaurar o banco de dados do último backup disponível ou experimentar a execução de comandos DBCC CheckDB com opções adicionais.
As mensagens de erro do DBCC podem ser parecidas com a abaixo:
Erro de tabela:ID do objeto 36, ID do índice 1, ID da partição, ID da unidade de alocação (digite dados na linha). Chaves fora de ordem na página (1:107), slots 6 e 9.CHECKDB encontrou 0 erros de alocação e 1 erro de consistência na tabela 'sys.syk' (ID do objeto 36).CHECKDB encontrou 0 erros de alocação e 1 erro de consistência no banco de dados 'VLDB'.repair_rebuild é o nível mínimo de reparo para os erros encontrados por DBCC CHECKDB (VLDB).Na mensagem de erro, você pode ver uma mensagem de erro cuidadosamente redigida – “repair_rebuild é o mínimo nível de reparo para os erros encontrados pelo DBCC CHECKDB ” – sugerindo que você execute o DBCC CheckDB com a opção repair_rebuild. Basta olhar para a palavra destacada – ‘mínimo’. Isso significa que, com a opção repair_rebuild, não há possibilidade real de perda de dados e o SQL Server faz algumas correções rápidas sob o capô. Consulte o comando abaixo para executar o DBCC CheckDB com a opção repair_rebuild. Certifique-se de colocar o banco de dados no modo de usuário único.
De acordo com a documentação da Microsoft, a opção REPAIR_REBUILD é a versão mais inofensiva, pois não pode haver perda de dados. No entanto, se REPAIR_REBUILD ainda não corrigir os erros de consistência, há uma outra opção – habilitar REPAIR_ALLOW_DATA_LOSS. Olhando para o nome, sabemos que haveria a possibilidade de alguma perda de dados se ativarmos essa opção. Devido a isso, a Microsoft nos alerta para usar isso com extrema cautela, pois pode haver consequências inesperadas na execução do DBCC CheckDB com REPAIR_ALLOW_DATA_LOSS. O comando DBCC CheckDB neste caso terá a seguinte aparência:
Pontos a serem considerados antes de usar a opção Reparar com DBCC CheckDB
Qual a importância do banco de dados em questão?
O banco de dados está em produção ou é um ambiente de teste?
Qual é o tamanho do banco de dados?
Você tem uma boa estratégia de recuperação caso apareçam problemas?
Você validou seus backups de banco de dados?
Com base na situação e nas respostas às perguntas acima, tente tomar uma decisão tendo em mente os melhores interesses do cliente.
Automatizando as tarefas DBCC CheckDB no SQL Server usando planos de manutenção de banco de dados
Bem, você não precisa executar todos esses comandos manualmente em seus servidores. É por isso que temos planos de manutenção em vigor. Certifique-se de agendar um ciclo de manutenção regular para todos os seus bancos de dados usando os planos de manutenção de banco de dados. É uma tarefa bastante simples e direta. Em “Tarefas do Plano de Manutenção”, selecione a “Tarefa de Verificação da Integridade do Banco de Dados”.
Isso adicionará uma subtarefa ao seu plano de manutenção para agendar verificações de integridade para seus bancos de dados. Certifique-se de selecionar os bancos de dados necessários conforme mostrado.
Certifique-se de executar todas as verificações do banco de dados durante um horário fora de pico da semana. Normalmente, as janelas de manutenção são nos finais de semana, quando o servidor está menos ocupado em comparação aos outros dias da semana. No entanto, isso varia de servidor para servidor e depende do aplicativo. Em sistemas de banco de dados críticos, os alertas geralmente são exibidos sempre que há verificações de integridade ou DBCC CheckDB ausentes. Dessa forma, os DBAs podem verificar proativamente e garantir que as verificações de integridade sejam concluídas para evitar surpresas mais tarde.
Automatizando tarefas DBCC CheckDB no SQL Server usando scripts personalizados ou outros scripts populares
Os planos de manutenção do SQL Server não precisam ser usados o tempo todo para executar tarefas de manutenção em sua instância do SQL Server. Existem outros scripts personalizados disponíveis que você pode usar. Uma das ferramentas de manutenção gratuitas populares é a solução de manutenção da Ola Hallengren. Você pode instalar toda a solução de manutenção que inclui tarefas de backup, otimização etc., ou pode baixar apenas os scripts relevantes relacionados a verificações de integridade. Nesta demonstração, tentaremos instalar os scripts específicos para verificações de integridade do banco de dados.
Clique na opção DatabaseIntegrityCheck.sql conforme mostrado para baixar os procedimentos armazenados que verificam a integridade do banco de dados. Depois de executar esses procedimentos armazenados no banco de dados mestre, me deparei com estas mensagens de aviso:
“O módulo 'DatabaseIntegrityCheck' depende do objeto ausente 'dbo.CommandExecute'. O módulo ainda será criado; no entanto, ele não pode ser executado com sucesso até que o objeto exista.”
Se você executar o procedimento armazenado para realizar verificações de integridade, receberá o seguinte erro:
Como o erro indica, você pode baixar o código ausente aqui. Feito isso, você pode começar a experimentar as verificações de integridade do banco de dados.
Você pode ajustar várias opções usando os parâmetros de comando DBCC adicionais. Você pode encontrar mais detalhes e exemplos deles aqui.
No entanto, nesta demonstração, verificaremos alguns exemplos para ver como esses scripts são realmente fáceis e fáceis de usar.
Para executar DBCC CheckDB em todos os bancos de dados de usuários , você precisará executar o seguinte:
EXECUTAR dbo.DatabaseIntegrityCheck@Databases ='USER_DATABASES',@CheckCommands ='CHECKDB'
Você pode ver o comando que foi executado e o status do resultado que confirma que o DBCC CheckDB foi concluído com êxito.
Para executar a Verificação DBCC apenas para os bancos de dados do sistema, execute este comando:
EXECUTAR dbo.DatabaseIntegrityCheck@Databases ='SYSTEM_DATABASES',@CheckCommands ='CHECKDB'
Na captura de tela, você pode ver que o DBCC CheckDB foi concluído com êxito para os bancos de dados do sistema.
Para executar DBCC CheckDB apenas para um banco de dados específico, execute o seguinte:
EXECUTAR dbo.DatabaseIntegrityCheck@Databases ='VLDB', -- seu nome de banco de dados específico@CheckCommands ='CHECKDB'
No exemplo acima, você viu algumas maneiras de usar parâmetros. No entanto, existem vários outros filtros que você pode selecionar com base em suas preferências. Além disso, como já mencionado, você pode consultar este link para uma melhor compreensão dos roteiros de Ola Hallengren. Apenas para reiterar, estou usando os scripts de Ola Hallengren nos servidores que gerencio e é altamente recomendado e reconhecido na comunidade SQL Server. Você pode agendar os procedimentos armazenados com base em seus parâmetros preferidos e executá-los como um trabalho SQL fora do horário de pico. Dessa forma, você realmente não precisa executar nenhum desses scripts manualmente, para poder se concentrar em outras tarefas importantes.
Conclusão
- A partir deste artigo, você aprendeu sobre o DBCC CheckDB e como ele pode ser usado
- Você também entendeu a importância de executar o DBCC CheckDB regularmente em todos os seus bancos de dados importantes
- Você também aprendeu sobre a importância de ter uma estratégia de backup testada – é recomendável restaurar seus bancos de dados usando um bom backup em vez de resolver erros de consistência usando as opções de reparo de DBCC
- Você também viu como é fácil configurar e automatizar scripts usando planos de manutenção do SQL Server ou scripts personalizados, por exemplo, o de Ola Hallengren
- Você também aprendeu os riscos de não agendar o DBCC CheckDB em sua infraestrutura compatível
- Você também aprendeu que, não importa em qual servidor você esteja ou em qual infraestrutura você execute, não pode haver banco de dados que não exija manutenção
- Por fim, certifique-se de manter seus bancos de dados íntegros e, em qualquer caso, esteja pronto para os dias de folga que podem não estar sob seu controle
