Posso descarregar o DBCC CHECKDB para outro servidor?

Posso descarregar o DBCC CHECKDB para outro servidor?


Você deseja verificar a corrupção, mas não quer desacelerar o servidor de produção principal.

Neste post, estou falando especificamente sobre descarregamento o processo de verificação de corrupção. Não estou falando de fazer verificação de corrupção ambos o primário e outros servidores – isso é maravilhoso, e se você estiver fazendo isso, deve se abraçar. Você está fazendo um bom trabalho. Quem é um bom cachorro? Tu es! Bom cachorro.

Agora, para o resto de vocês – seu servidor de produção é lento e você deseja saber quais são as desvantagens de executar o CHECKDB em outros servidores. Aqui estão as questões a serem consideradas. Vou falar em termos gerais sobre risco comercial. Eu gostaria de poder dar uma idéia do risco que você está correndo por lá, mas sem ver seus servidores e práticas, isso é difícil. Comece colocando seu RPO e RTO por escrito, e esses riscos começarão a fazer sentido com base no tamanho dos seus dados, na quantidade de dados que você deseja perder e por quanto tempo deseja diminuir:

Se você descarregar o trabalho de produção, precisará de uma licença de produção. A Developer Edition não é suficiente. Dependendo da versão do SQL Server e dos recursos do banco de dados que você estiver usando, você poderá executar o Enterprise em produção e depois o Standard no seu ambiente de descarregamento, economizando alguns custos de licenciamento. O 2016 SP1 moveu uma tonelada de recursos corporativos focados no desenvolvedor para o padrão, incluindo particionamento, compactação, índices columnstore e muito mais, e 2019 até adicionou a criptografia de dados transparente. Isso é bem legal! Você pode reduzir os custos dos seus trabalhos de manutenção, por assim dizer.

Se você não executa o CHECKDB no mesmo servidor que faz seus backups, corre um risco muito, muito sério: seus próprios backups podem estar corrompidos. O SQL Server fará backup de páginas corrompidas a noite toda sem gerar nenhum erro. Mesmo o processo de restauração não verifica se há corrupção. É essencial que você faça uma verificação de corrupção no backup o mais rápido possível. Se você estiver usando grupos de disponibilidade e transferindo backups para uma réplica diferente, execute o CHECKDB nessa mesma réplica no mínimo. Vi situações em que o backup e o CHECKDB eram executados em duas réplicas diferentes, e o CHECKDB passava uma réplica, mas os backups estavam fazendo backup de páginas de dados corrompidas em uma réplica diferente.

Leia Também  Como acessar APIs REST do Power BI programaticamente

Se você restaurar backups completos em outro lugar, estará apresentando um risco de atraso. Digamos que você esteja descarregando o trabalho porque está lidando com um banco de dados grande – isso também provavelmente significa que você está lidando com backups e restaurações lentos. Portanto, se sua linha do tempo estiver assim:

  • 18:00 – 20:00 – o backup completo é executado na produção, apontado para um compartilhamento de arquivo
  • 20h às 22h – a restauração completa é executada em outro ambiente, restaurando a partir do compartilhamento de arquivos
  • 22:00 – Início do CHECKDB
  • Meia-noite – CHECKDB termina com uma falha, indicando corrupção

Ok, e agora? Houve um problema com o backup, a restauração ou o hardware no ambiente CHECKDB? Sua solução de problemas está apenas começando e, enquanto você está solucionando problemas, a corrupção pode estar piorando. Por outro lado, se você executasse o CHECKDB diretamente na produção, saberia com confiança onde estão os problemas.

Se você executar o CHECKDB em um servidor em que os backups de log foram aplicados, você está testando diferentes páginas de dados do que as que estão no primário. Você pode executar o CHECKDB em um secundário de envio de logs, por exemplo, mas apenas as alterações registradas estão passando do primário para o secundário, e não a página de dados. Isso significa que é possível que o primário fique cheio de porcas ao mesmo tempo em que o log enviado secundário está bom. Qual é o grande problema? Bem, imagine dois problemas:

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
  • Se o principal encontrar corrupção, com certeza, você pode efetuar failover no log enviado secundário. Yay! Limpe as páginas de dados.
  • Se você precisar restaurar algo do backup, como para fins de conformidade ou para relaxar uma exclusão “oops”, pense em onde seus backups completos foram realizados: isso mesmo, o principal! Esses backups completos estavam fazendo backup de páginas de dados corrompidas e são inúteis. Você não fez backups completos no log enviado secundário, portanto, embora ele tenha páginas de dados limpas, ele só possui páginas de dados limpas a partir de agora.
Leia Também  Manuais recomendados do SQL Server, 2020 Edition

Se você estiver executando o CHECKDB em algum lugar em que não fará o failover, você está ainda mais exposto. Nos nossos cenários acima, digamos que transferimos o CHECKDB para um servidor de restauração com menos núcleos e memória, executando o Standard Edition mais barato. Se o nosso primário relatar subitamente corrupção, não adianta muito procurar o servidor de restauração e dizer: “Tudo bem, amigo, é hora de promovê-lo para a função principal”. Lembre-se de que já estamos transferindo o CHECKDB porque o primário em si não foi rápido o suficiente para acompanhar nossas cargas de trabalho e nossos trabalhos de manutenção: as chances são de que nosso amigozinho também não será capaz de fazê-lo. Nesse ponto, quando você atinge a corrupção no primário, você já precisa limpá-la e restaurá-la, e espero que a corrupção não volte – mas sem fazer uma análise da causa raiz do motivo pelo qual a corrupção ocorreu, bem, provavelmente ela voltará . Por isso, não sou fã de ter apenas um grande primário e de descarregar o CHECKDB para um pequeno servidor de restauração. Nesse ponto, todos os nossos ovos estão em uma cesta e tudo o que é bom para o CHECKDB é confirmar que sim, a cesta está quebrada. O negócio está em baixa.

Mas se você estiver usando AGs, não restaurações, e quiser fazer failover dessa réplica, o risco é mais tolerável. Se você transferir o CHECKDB e os backups para uma réplica na qual você se sentirá à vontade para efetuar o failover, se o principal encontrar corrupção, não haverá um risco de atraso. Você só precisa de mais de 2 servidores no AG neste momento, assim:

  • Réplica1: normalmente nosso principal, super ocupado, não tolera lentidão na manutenção
  • Replica2: não consultado, usado apenas para backups e CHECKDB
  • Replica3: assíncrona, pronta para entrar em serviço, se necessário
Leia Também  Atualizado First Responder Kit e Consultant Toolkit para dezembro de 2019

Em seguida, se a Réplica1 começar a relatar corrupção, você poderá realizar o failover para a Réplica2, tornar a Réplica3 a nova réplica de backup / CHECKDB e remover a Réplica1 enquanto soluciona os problemas de IO ou SQL Server.

O reparo automático de página não é uma correção a longo prazo. No cenário acima, as pessoas podem dizer: “Tudo bem se a Réplica1 encontrar corrupção – ela apenas buscará automaticamente cópias limpas das páginas da Réplica2 e Réplica3 e se recuperará em tempo real”. A TAEG é como um colete à prova de balas: é ótimo para proteção temporária em muitas partes do corpo, mas se você levar um tiro em lugares que o colete não cobre, você terá um dia ruim. A APR não pode curar a corrupção em todos os tipos de páginas, em todos os bancos de dados. Depois de começar a levar um tiro, você precisa evacuar a área o mais rápido possível, e um colete à prova de balas o comprará. O mesmo acontece com a APR – seu subsistema de E / S ou o próprio SQL Server está destruindo suas páginas de dados e você precisa evacuar seus dados dessa área o mais rápido possível para fazer a análise de causa raiz.

tl; dr – se suas únicas opções não estiverem executando o CHECKDB ou descarregando o CHECKDB em outro local, obviamente você deverá descarregá-lo. Prefiro que você faça isso na réplica primária, mas, se não puder, não pode – fique atento às dicas acima.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br