Você acabou de criar um novo SQL Server, e aí você precisa verificar se ele vai funcionar tão bem quanto o seu servidor existente. Veja 4 maneiras de verificar o desempenho em um novo SQL Server.
1. Testar os trabalhos de manutenção
O caminho mais fácil para verificar o desempenho em um novo SQL Server é testar seus trabalhos de manutenção da seguinte maneira:
- Restaure seus backups de produção no novo servidor
- Faça um backup completo e tempo
- Execute o DBCC CHECKDB e o tempo
Este será seu primeiro teste! Se os tempos de execução de backup e CHECKDB estiverem mais lentos do que o servidor de produção atual, então você está com problemas.
Esse caminho não é perfeito porque:
- Os horários de início dos trabalhos podem ser diferentes. Por isso, se as tarefas de backup de produção forem executadas no meio da noite e ao mesmo tempo que as tarefas de ETL, os backups de produção poderão ser artificialmente mais lentos.
- Sua carga de trabalho simultânea pode ser diferente. Sendo assim, talvez todas as suas tarefas de backup de produção apontem para o mesmo destino de arquivo compartilhado à meia-noite, tornando-a lenta. Quando você testa seu novo servidor às 13h da tarde, quando nada está acontecendo no destino do arquivo compartilhado, elas podem ser artificialmente rápidos.
- Seu destino de backup pode ser diferente. Ou seja, os servidores de produção podem estar gravando seus backups no armazenamento local. E isso, obviamente é uma péssima ideia.
- Sua nova versão do SQL Server pode ser diferente. Desse modo, se você estiver migrando de 2014 para 2016, e descobrir que o CHECKDB é executado mais rapidamente, talvez sejam as melhorias do CHECKDB em 2016.
Mas dito tudo isso, se você descobrir que os trabalhos de manutenção do seu novo servidor de produção estão mais lentos do que os servidores de produção atuais, é hora de desativar os alarmes.
2. Testar uma carga de trabalho sintética
Você pode baixar o HammerDB, uma ferramenta de teste de carga de código aberto, e executar a carga de trabalho TPC-C kinda-sorta em seu SQL Server.
Não é um benchmark oficial do TPC. Mas é uma carga de trabalho repetível que você pode executar em vários servidores. Assim você verá se um é mais rápido do que o outro.
3. Testar consultas individuais
Use o sp_BlitzCache para criar uma lista de suas consultas de pior desempenho. Em seguida, execute essas mesmas consultas no novo servidor de produção para comparar:
- Suas leituras lógicas
- Sua duração
- Seu tempo de CPU
- Seus planos de execução (para entender por que os números acima são diferentes)
Apenas executar as mesmas consultas não é tão difícil. Mas a razão pela qual esse método é o “mais difícil” é que você precisa ter conhecimento suficiente de ajuste de desempenho do SQL Server para entender por que os números são diferentes e que controle você tem sobre eles.
4. Testar sua carga de trabalho real
Outra maneira de verificar o desempenho em um novo SQL Server é executar as mesmas consultas executadas na produção. Isso envolve:
- O mesmo ponto de partida. Afinal, você não pode executar a mesma instrução de exclusão duas vezes seguidas para obter o mesmo efeito. E cada instrução de inserção afeta as execuções de teste subsequentes.
- A mesma distribuição de carga de dados. É fácil executar uma consulta idêntica em 1.000 sessões. Mas se todas estiverem tentando bloquear a mesma linha, você estará apenas reproduzindo problemas de bloqueio que você não tem na vida real.
- As mesmas cargas de trabalho. Pois desde que seu aplicativo e seu banco de dados estejam em constante mudança, os rastreamentos de consulta que você reuniu não fazem sentido hoje. Então você deve continuar reconstruindo essa roda toda vez que quiser fazer um projeto de teste de carga.
Verificando o desempenho em um novo SQL Server
Comece com as coisas fáceis primeiro para obter o máximo de dados valiosos em menos tempo. E lembre-se que mesmo quando você encontrar diferenças entre os servidores, ainda é apenas o começo de sua jornada.
Você precisa descobrir porque as coisas não estão indo tão bem quanto você esperava. Portanto, volte a etapa anterior, comparando os planos de consulta e fazendo a análise da causa raiz.
E uma última dica, antes de verificar o desempenho em um novo SQL Server é começar com a consulta de pior desempenho sozinha.
Clique aqui se você precisa de uma consultoria SQL Server Remoto para análise no seu banco de dados.
Wesley Mota
Latest posts by Wesley Mota (see all)
- Discover the Enjoyment of Free Port Gamings Offline - abril 17, 2024