Brent Ozar sabe tudo sobre velocidade – ele corre com carros e acelera os SQL Servers com resultados de desempenho de banco de dados de tirar o fôlego diariamente. Em seu webcast "Como medir o SQL Server", para a série Database Training Days da Quest, Brent nos lembrou que o desempenho tem tudo a ver com medição.
Acelerando para o desempenho
Brent aproveitou a oportunidade para praticar o distanciamento social e vestiu a parte vestindo um traje de corrida completo e capacete. Em algumas brincadeiras pré-webcast, descobrimos que ele tinha que conectar um microfone no capacete e prender os fones de ouvido em seus ouvidos! Mas nós divagamos. O webcast foi sobre desempenho, e havia muitas analogias de carros para fazer.
Para melhorar o desempenho do SQL Server, as premissas são:
- Escolha métricas para se concentrar em melhorar
- Meça o desempenho antes e depois de fazer alterações limitadas (método científico básico)
- Entenda quando você tem o equipamento errado para o que está tentando alcançar
Métricas de ajuste de desempenho do banco de dados
Uma longa discussão sobre caminhões Ford F150, Ford Fiestas e alguns outros veículos interessantes ilustrou que existem diferentes maneiras de melhorar o tempo que leva para ir de 0 a 60 milhas por hora. Você pode diminuir o peso do veículo, adicionar um motor maior ou começar a remover itens não essenciais – como um para-brisa. Haverá um compromisso entre desempenho e utilidade. Os bancos de dados são exatamente assim – eles geralmente são carregados. É quando o ajuste de desempenho personalizado é necessário, o que requer conhecer e melhorar as métricas.
Brent afirma que existem três métricas principais que você precisa para carros de ajuste de desempenho e bancos de dados:peso, referência de velocidade (como 0 a 60) e quão duro o motor (servidor) está trabalhando.
Medindo o tamanho do banco de dados
O peso do SQL Server se traduz no tamanho total do banco de dados e na quantidade de dados que você tem. Isso geralmente é medido em gigabytes ou terabytes. De cerca de 1 a 150 GB, o SQL Server Standard Edition deve ser suficiente. De 150 a 500 GB é uma carga fácil para a Enterprise Edition. Além de 500 GB, começa a importar se são dados ativos e como são acessados. E, qualquer coisa acima de 1 TB de dados OLTP pode ser muito desafiador.
Rastreando a velocidade do desempenho
A referência de velocidade em carros é fácil – MPH. Para o banco de dados, são solicitações em lote por segundo, mas isso precisa ser atualizado a cada hora durante diferentes períodos de tempo. Obviamente, quanto mais consultas houver, mais lento será o desempenho dependendo do hardware.
Avaliando cargas de trabalho de consulta
Por fim, para entender o quanto o banco de dados está funcionando, você precisa entender quais consultas estão sendo executadas no momento e o que está esperando na fila. Isso lhe dará uma taxa de tempo de espera – basicamente quanto tempo as tarefas estão esperando para que outras sejam concluídas. Sua proporção de tempo de espera será expressa em horas de tempo de espera por hora (ou segundos de tempo de espera por segundo) – não misture suas unidades de medida. Quando você tem um bom controle sobre essas estatísticas ao longo do tempo, pode ver o que afeta o tempo de espera, por exemplo, se há mais ou menos solicitações em lote, consultas melhor ou pior ajustadas etc. Então, você pode resolver esses problemas.
Assista à gravação do webinar sob demanda para todos os sábios conselhos e humor de Brent.
