É 2020, eu realmente preciso do DBCC CHECKDB? – BLOG DE TECNOLOGIA SQL

É 2020, eu realmente preciso do DBCC CHECKDB? – BLOG DE TECNOLOGIA SQL

É 2020, eu realmente preciso do DBCC CHECKDB? - BLOG DE TECNOLOGIA SQL 1


Começo dizendo que juro que publiquei isso em algum momento no passado, mas não vejo isso em posts antigos. Isso é de 19 de agosto; no entanto, eu não vi nenhuma nota de versão sobre corrupção no Azure.

Digamos que você veja uma solicitação para restaurar um backup do banco de dados em uma Instância Gerenciada do Azure. Você faz essa tarefa e, alguns dias depois, a equipe que solicitou a restauração diz que está tendo problemas para se conectar ao backup restaurado recentemente.

Você abre o SSMS e o banco de dados não aparece no Pesquisador de objetos. Você descobre que o banco de dados existe consultando sys.databases; mas, por que não aparece no Pesquisador de objetos? Isso é estranho, mas não se preocupe. Você tenta se conectar ao banco de dados com “USE”, mas obtém o seguinte erro:

Msg 40863, Nível 14, Estado 2, Linha 1

As conexões com esse banco de dados não são mais permitidas.

Isso é loucura! E agora? Abrir no ticket com o MSFT? Essa parecia a única escolha e qual era a causa raiz? Aparentemente, nas Instâncias Gerenciadas do Azure, a Microsoft verifica os bancos de dados quanto à corrupção e coloca o banco de dados offline se detectado.

Quando nesse estado off-line especial, não há como acessar o banco de dados e a Microsoft deve ser contatada. Você não pode definir o banco de dados no modo de recuperação ou alterá-lo para ONLINE. A Microsoft entra em contato com alguém para notificar que o banco de dados foi colocado offline devido a corrupção, mas se você trabalha em uma empresa maior, essa notificação pode nunca chegar às pessoas certas.

Leia Também  [Video] Atualizado Kit Primeiro Respondente e Kit de Ferramentas do Consultor para maio de 2020

Quando o banco de dados estiver on-line novamente, parece que você tem um tempo limitado para solucionar problemas, porque a mesma verificação de corrupção desativará o banco de dados quando ele for executado novamente.

Para piorar as coisas, existem opções limitadas para corrigir o banco de dados.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
  • Você pode executar o CHECKDB em uma instância gerenciada, mas eles não permitem o modo SINGLE_USER, o que significa que você não pode usar a opção REPAIR com o CHECKDB. Idealmente, você deseja corrigir a corrupção encontrada, mas nesse cenário o CHECKDB levaria muito tempo e o banco de dados se desconectaria ou falharia devido à falta de recursos; então, eu não conseguia descobrir qual era a corrupção como suspeita: as páginas não tinham linhas.não pode reparar
  • Você não pode restaurar com REPLACE, porque isso não é permitido.
  • Descartar banco de dados existente? Provavelmente não. Nesse caso, houve um processo bloqueado porque a cauda do backup do log estava falhando e o banco de dados não pôde ser descartado. Isso teve que ser corrigido em segundo plano pela Microsoft.

É 2020, o DBCC CHECKDB é relevante? Para migrações absolutamente! Imagine entrar em prod por 3 dias e depois não conseguir usar esses 3 dias de dados. Felizmente, este foi um banco de dados de teste. Ao longo dos anos, tenho visto muitos clientes que dizem “Não podemos fazer o CHECKDB porque ele não está completo ou o banco de dados é muito grande”. Lembre-se de que você pode executar o CHECK ALLOC, CHECKTABLE e CHECKCATALOG individualmente.

O que aprendemos hoje?

  1. SEMPRE execute o CHECKDB como uma etapa de pré-migração. Se você recebeu um backup, restaure-o e execute o CHECKDB.
  2. As soluções de banco de dados PaaS podem ser dolorosas em alguns cenários, porque você perdeu o controle sobre algumas tarefas de gerenciamento (mais fácil nem sempre é melhor).
  3. Você pode executar o CHECKDB em uma instância gerenciada, mas não pode usar o reparo.
  4. O CHECKDB pode consumir muitos recursos, portanto, execute CHECKALLOC, CHECKCATALOG e CHECKTABLE independentemente diariamente.
  5. A Microsoft executa verificações de corrupção em segundo plano com seus backups (isso não significa que o CHECKDB não é necessário. Você ainda deve estar executando as tarefas do DBA 101).
Leia Também  Scripts Python para tabelas dinâmicas no SQL Server

Nota lateral: os Grupos de Disponibilidade oferecem “Reparo Automático de Página”, o que poderia ser útil se isso tivesse ocorrido no Azure ou estivesse no local de onde veio esse backup do banco de dados.