E se você se der ao trabalho de implementar ou atualizar para um novo SQL Server para uma melhor experiência para seus clientes – e eles reclamarem que as coisas estão realmente piores?
Você não ficaria incomodado se passasse por todos esses obstáculos técnicos e de negócios para obter um melhor desempenho do SQL Server e não o fizesse?
Talvez você devesse ter realizado alguns testes de desempenho do SQL Server antes de entrar em produção. Então você saberia se seu desempenho iria melhorar, permanecer o mesmo ou, pior de tudo, diminuir.
Mas pelo menos você não ficaria desagradavelmente surpreso.
A ponte de desempenho do SQL Server que todos atravessamos
Seja mudando de algum outro banco de dados para o SQL Server ou atualizando de uma versão mais antiga do SQL Server para uma mais recente, você teve que cruzar a ponte de desempenho eventualmente.
“Será que vai realmente correr melhor do que antes?” seu chefe perguntou.
“Ah, claro”, você disse. “Com a virtualização de dados no SQL Server 2019, podemos executar consultas sem mover ou replicar dados. E há ajuste automático com o Intelligence Query Processing para ampliar as consultas. Os dados vão VOAR para fora dos servidores.” Você estava tão confiante que capitalizou “FLY”.
Então, como você poderia ter testado melhor seu desempenho?
4 maneiras de testar o desempenho . . .
Brent Ozar, especialista em SQL Server extraordinário, informa como verificar o desempenho em um novo SQL Server:
- a maneira mais fácil, comparando antes e depois de um backup completo e CHECKDB
- a maneira mais fácil, mas errada, com uma carga de trabalho sintética e TPC-C no HammerDB
- da maneira mais difícil, testando consultas individuais com sp_BlitzCache, seu script de análise de cache do plano
- da maneira mais difícil, executando as mesmas consultas que você executa na produção
Mas, como Brent deixa claro, monitorar o desempenho do servidor SQL e descobrir que ele caiu em X por cento é apenas o começo; você ainda tem que descobrir de onde o hit está vindo.
Isso significa procurar tendências nos dados de desempenho ao longo de semanas e meses inteiros, não apenas nas últimas horas.
Quanto mais pontos de dados e histórico você tiver, melhor será a imagem que você pode montar do que está acontecendo dentro, sob e ao redor de seu ambiente SQL Server.
E quanto mais computação você puder lançar em todos esses dados, mais rapidamente poderá analisá-los.
Monitoramento de desempenho do SQL Server:parece um trabalho para a nuvem
Sim. É um trabalho para a nuvem, o único lugar em que você pode expandir o suficiente para coletar e analisar todos esses dados para obter uma imagem ampla e profunda de como o SQL Server está consumindo recursos. E como vem consumindo esses recursos ao longo do tempo. Por exemplo:
- Em determinados momentos do dia ou do mês, as consultas executadas com frequência precisam ser lidas do disco em vez do cache do buffer, que é a cópia na memória das páginas do banco de dados usadas recentemente. Você precisa alocar mais memória para seu cache de buffer? Você pode poupar mais memória para ele?
- O mesmo para a expectativa de vida da página. Se estiver baixo, provavelmente é porque o SQL Server está despejando páginas do cache de buffer com muita frequência e precisando executar pesquisas do armazenamento em vez da memória. Isso prejudica o desempenho.
- O tempo máximo de espera de E/S está ficando muito alto? Como é tendência? Isso é uma dica de que o dispositivo de E/S pode estar saturado.
- Quanto tempo dura a fila do processador agora? Quanto tempo costuma ser? Muitos threads esperando constantemente podem indicar congestionamento do processador.
- A CPU está funcionando dentro dos limites que seu servidor pode suportar? E se você não puder mais escalar o servidor? Se você tiver certeza de que suas consultas estão bem ajustadas e que os outros recursos do sistema são adequados, talvez seja necessário adicionar um soquete para hardware físico ou vCPUs às suas VMs.
- Os índices fragmentados são índices lentos, mas você não sabe que eles são os culpados até verificar os níveis de fragmentação. Ver os efeitos da reorganização e reconstrução ao longo do tempo pode ajudar você a implementar um processo confiável de manutenção de índice.
Encontrar problemas como aqueles em todos os seus bancos de dados locais e na nuvem fica mais fácil e rápido quando você pode monitorar o desempenho do servidor SQL na nuvem. O melhor de tudo é que você pode monitorar de qualquer lugar da galáxia conhecida quando toda a computação, armazenamento e análise estiverem na nuvem e você estiver a apenas alguns cliques em qualquer navegador.
Comece a testar o desempenho do SQL Server na nuvem
Na Quest, ninguém precisa nos dizer duas vezes que nossos clientes querem ferramentas baseadas em nuvem, seja para migração para nuvem, monitoramento de desempenho ou Office 365. Estamos disponibilizando mais de nossos produtos como ofertas de nuvem porque as tecnologias e os mercados os estão atraindo para lá.
Então, como você executa testes de desempenho em seus SQL Servers novos ou atualizados?
- Eu corro CHECKDB.
- Eu corro o HammerDB.
- Eu corro as ferramentas de Brent Ozar.
- Eu testo com cargas de trabalho de produção.
- Jogo os dados e espero até que os usuários reclamem.
- Tenho pessoas que fazem isso por mim.
- Eu uso o Spotlight Cloud da Quest. Você também deveria.
