3 maneiras de executar DBCC CHECKDB mais rápido

3 maneiras de executar DBCC CHECKDB mais rápido

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


Em meu último post, falei sobre como você pode obter backups 43% -67% mais rápidos. Hoje, estou usando a mesma configuração do SQL Server para discutir como o lançamento de mais núcleos de CPU pode ajudá-lo a verificar se há corrupção mais rápido se você já tiver armazenamento rápido moderno. Não espero que todos cheguem a esse nível de detalhe de forma alguma, mas é o tipo de ajuste que você pode fazer quando está enfrentando vários terabytes de dados de produção por servidor e diminuindo as janelas de manutenção.

Você precisa verificar se há corrupção regularmente porque o SQL Server não está fazendo isso por você (embora eu tenha pedido à Microsoft para fazer isso, e você pode votar a favor). Todos os tipos de coisas podem causar corrupção: problemas de armazenamento, problemas de rede de armazenamento e até mesmo bugs do SQL Server como este ou isto ou isto ou isto ou isto.

No entanto, as pessoas costumam hesitar em executar DBCC CHECKDB porque ele tem a reputação de usar muitos recursos. Boas notícias, porém: existem algumas maneiras fáceis de influenciar o impacto do CHECKDB.

Ajuste de desempenho nº 1:
execute-o em mais núcleos.

Na Standard Edition, CHECKDB é de thread único. Isso porque você não precisa de uma verificação de corrupção rápida no Standard Edition porque ele não contém nenhum bug de corrupção. Não, absolutamente nenhum. Aqueles de vocês que usam a Standard Edition podem simplesmente ignorar esse ajuste e seguir direto para o próximo.

Enterprise Edition tem verificação de corrupção paralela porque é muito mais vulnerável a bugs de corrupção (certo? Deve ser o que é – certamente não pode ser uma grana) e desde o SQL Server 2016, CHECKDB aceitou um parâmetro MAXDOP que permite definir o número de núcleos de CPU envolvidos. Você também pode sugerir para cima, mais alto do que o MAXDOP no nível do servidor, para que ele possa usar mais threads, mesmo em servidores que hospedam aplicativos de thread único.

Quanto mais você usa, mais você economiza, mas a história aqui é um pouco mais complicada do que a postagem de backup de vários arquivos. Aqui, eu não apenas examinei o tempo de execução do CHECKDB, mas também a quantidade de tempo de espera gerado pelo comando e a proporção do tempo de espera. A proporção de tempo de espera significa para cada minuto no relógio, quantos minutos o SQL Server gastou esperando? Quanto mais alto for esse número, pior será o seu desempenho.

Leia Também  Contêineres do Docker e dados persistentes |
MAXDOP Minutos Tempo de espera, minutos Razão de tempo de espera
1 53 4
2 37 121 3
4 26 155 6
8 18 212 12
12 14 234 16
16 14 332 23
24 12 354 30
32 11 462 41
48 9 494 56
56 8 564 65
64 7 579 75
72 13 1.052 79
80 17 1.409 84
96 19 1.879 99

Lembre-se de que este SQL Server específico tem 48 núcleos físicos, 96 com hyperthreading ativado.

No MAXDOP 64, estamos verificando 56 GB de dados por minuto e:

  • CHECKDB executa 86% mais rápido do que quando é de thread único
  • 59% mais rápido do que MAXDOP 8 (que é o que muitas pessoas estariam se definissem MAXDOP no nível do servidor aqui)
  • 48% mais rápido do que MAXDOP 16
  • A proporção do tempo de espera é 75, ou seja, para cada minuto no relógio, estamos gerando 75 minutos de tempo de espera, a maioria dos quais é CXPACKET e CXCONSUMER
  • Os 64 núcleos de CPU envolvidos mantêm 100% na maior parte da duração (graças ao nosso incrível provisionamento de hardware)

3 maneiras de executar DBCC CHECKDB mais rápido 2

Certamente não estou dizendo que MAXDOP 64 faz mais sentido para todo o hardware, mas neste cenário, nos permitiria manter a janela de manutenção o mais curta possível, assumindo que temos 7 a 10 minutos por noite para suportar cargas pesadas.

MAXDOP 96 funciona mais lento, não mais rápido, e o uso da CPU faz com que a caixa pareça inutilizável:

3 maneiras de executar DBCC CHECKDB mais rápido 3

Ajuste de desempenho nº 2:
verifique se há menos (ou mais) problemas de corrupção.

Por padrão, CHECKDB verifica os problemas mais comuns, mas você pode torná-lo muito mais rápido se apenas solicitar que verifique as somas de verificação em cada página. Isso não detecta problemas lógicos, como estatísticas corrompidas, mas pelo menos fornece os primeiros sinais de aviso de corrupção de armazenamento.

Leia Também  Os internos das instruções SQL Truncate e SQL Delete
cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br

Para fazer isso, use a opção WITH PHYSICAL_ONLY – que não faz tanto trabalho de CPU, portanto, também vemos resultados de desempenho diferentes aqui:

MAXDOP Minutos Tempo de espera, minutos Razão de tempo de espera
1 17 1
2 12 35 3
4 8 41 5
8 6 47 8
12 5 61 12
16 5 74 15
24 5 113 24

Para este servidor em particular, conforme eu jogava mais núcleos nele, as únicas coisas que aumentaram foram minhas esperas de paralelismo. O ponto ideal aqui era cerca de 8-12 núcleos.

Mas isso leva a uma comparação interessante:

  • PHYSICAL_ONLY com 12 núcleos: leva 5 minutos, verifica apenas as somas de verificação da página
  • FULL CHECKDB com 64 núcleos: leva 7 minutos, verifica tudo

Neste servidor em particular, enquanto eu estiver executando o Expensive Edition, eu simplesmente não acho que faria sentido usar a configuração PHYSICAL_ONLY porque, enquanto eu estiver tomando uma lentidão de 7 minutos, se eu tiver Núcleos de CPU disponíveis (e não estão funcionando de outra forma), então é melhor verificar tudo. Se este fosse realmente um ambiente 24 horas por dia, 7 dias por semana, onde eu não poderia lidar com uma lentidão de 7 minutos, então … Provavelmente estou transferindo CHECKDB para outra réplica AG de qualquer maneira, especialmente dadas as maravilhosas mudanças de licenciamento de 2019 que o tornam gratuito.

Além disso, eu posso até querer usar o parâmetro EXTENDED_LOGICAL_CHECKS. Ele captura ainda mais culpados de corrupção, embora ao custo de tempos de execução mais elevados:

MAXDOP Minutos Tempo de espera, minutos Razão de tempo de espera
1 53 4
2 40 130 3
4 29 175 6
8 17 198 11
12 16 292 17
16 14 321 22
24 10 327 31
48 9 492 57
56 11 731 60
64 15 1.047 69
96 19 1.880 99

É interessante notar que o ponto ideal da CPU para esta caixa em particular era de 64 núcleos para o CHECKDB regular, mas cerca de 24 núcleos para EXTENDED_LOGICAL_CHECKS, produzindo o melhor equilíbrio entre tempos de execução curtos e um servidor sobrecarregado e sem resposta. (Estou abreviando alguns dos resultados aqui.) Esse ponto ideal vai depender não apenas do seu hardware, mas também do conteúdo do seu banco de dados e de quais recursos do SQL Server você está usando, o que me leva a …

Leia Também  Anunciando uma nova classe: fundamentos do Columnstore

Ajuste de desempenho nº 3:
tornar seu banco de dados menor.

O número de tabelas que você tem E o número de índices nelas afetam a velocidade de CHECKDB. Todos os testes acima envolveram o banco de dados Stack Overflow de 390GB 2020-06, que não vem com nenhum índice não clusterizado.

Para tornar o banco de dados mais complexo, adicionei:

  • 80 índices de 3 colunas
  • 2 visualizações indexadas
  • 2 índices columnstore não clusterizados
  • Trazendo o banco de dados de 390 GB para 560 GB (aumento de cerca de 44%)

E então executei alguns dos testes novamente:

  • Physical_only, 16 núcleos: 7,2 minutos – até cerca de 60% de 4,5 minutos, maior do que o crescimento de 44% do tamanho do banco de dados, mas eu não interpretaria muito em testes únicos – eu não usaria esses resultados para dizer definitivamente que o desempenho físico_only não é escalonado linearmente com o tamanho do banco de dados.
  • CHECKDB regular, 64 núcleos: 30,4 minutos – aumentou drasticamente de 7,5 minutos sem índices, e a proporção de tempo de espera permaneceu em torno de 75, então o servidor estava realmente agitado o tempo todo.
  • Verificações lógicas estendidas, 64 núcleos: 35,3 minutos – acima de 14,9 minutos, mas a penalidade de tempo de execução de verificações estendidas (em comparação com CHECKDB regular a 30,4 minutos) não era tão grande aqui quanto era para o teste sem nenhum índice não clusterizado. Isso se alinha com o que vejo no campo: verificações lógicas estendidas não são um grande problema em bancos de dados da vida real com índices e valem totalmente a pena se você estiver apostando em visualizações indexadas.

Esses tempos são por que muitas vezes faz sentido executar CHECKDB com a opção PHYSICAL_ONLY durante a semana para obter aquele tempo de execução extremamente rápido com quase nenhum uso de CPU e, em seguida, atualizar para o CHECKDB completo e intensivo de recursos com EXTENDED_LOGICAL_CHECKS no fim de semana, jogando muito de núcleos de CPU para terminar o trabalho o mais rápido possível.

Não sabia sobre isso? Você pode ter perdido algumas das outras coisas sobre as quais falamos em nossa aula de Fundamentos de Administração de Banco de Dados.

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