“Doc, estou preocupado com o desempenho do meu SQL Server.”
Não era o tipo de coisa que você ouve da maioria dos pacientes. Mas então, como profissional pago, fui treinado para lidar com tudo – até mesmo os tempos difíceis de ser um administrador de banco de dados.
"Sério? Vamos explorar isso, certo?”
“Claro, doutor. Quero dizer, às vezes parece tão esmagador. Eu pensei que tudo iria se resolver por conta própria uma vez que eu me comprometesse com isso. Mas antes que eu percebesse, comecei a ter problemas de desempenho no SQL Server 2012, depois em 2014 e depois em 2017. Não quero nem pensar no SQL Server 2019.”
"Eu vejo. Bem, um bom relacionamento com o SQL Server não acontece sozinho. Você tem que trabalhar nisso. Diga-me, você trabalhou em suas técnicas de ajuste de desempenho do SQL Server?”
“Er, não, doutor. Eu realmente não conheço nenhuma dessas técnicas.”
"Não se preocupe. Podemos trabalhar neles. Seu SQL Server provavelmente está se sentindo negligenciado. Você tem que ficar de olho nele para ter certeza de que está ficando à frente do jogo. Isso requer monitoramento do SQL Server.”
“Monitoramento? Como você faz isso?"
“Você tem que mostrar ao SQL Server que você se importa. Você tem que prestar atenção a certas métricas. Podemos trabalhar nisso também.”
“Tudo bem, doutor. Qualquer coisa que você diga. Estou disposto a tentar qualquer coisa neste momento. As coisas não poderiam ficar muito piores do que estão agora.”
"Bom então. Vamos começar."
Métricas de desempenho do SQL Server — muitas partes móveis
O paciente estava certo:monitorar o desempenho do SQL Server pode parecer difícil. Você não pode parar de prestar atenção a ele uma vez que está em funcionamento. Você tem que continuar mostrando que se importa.
O SQL Server tem muitas partes móveis que geram métricas constantemente. Saber quais assistir e, em seguida, tirar um tempo do seu dia atarefado para monitorá-los pode ser muito trabalhoso para um DBA.
Então passei por algumas das principais áreas de métricas de desempenho do SQL Server com o paciente.
Índices
Um dos primeiros lugares a serem observados quando você está tendo problemas de desempenho com o SQL Server são os índices. Seus dados estão sempre crescendo, então seus índices estão sempre crescendo também. Mas eles estão sujeitos a condições como fragmentação e divisões de página que podem retardar a resposta às consultas.
O que está acontecendo em um banco de dados dia após dia? Os usuários estão criando, editando e excluindo registros. Os índices acompanham onde estão todas as partes dos registros, mas com o tempo, a fragmentação do índice prejudica o desempenho.
Depois, há o fator de preenchimento de índice, um parâmetro que você pode configurar no SQL Server para controlar o número de divisões de página e aumentar a eficiência da consulta. Mas o equilíbrio entre mais e menos divisões de página afeta o desempenho de outras maneiras.
Observando métricas no fator de preenchimento , E/S e fragmentação é uma boa maneira de manter seus dedos no pulso da integridade do índice do SQL Server.
Cache de buffer
Vamos simplificar:Disco, lento; cache de buffer, rápido. O cache de buffer é uma cópia na memória de páginas de banco de dados usadas recentemente. Se o SQL Server não encontrar o que está procurando, ele precisará ir para o disco, o que diminui o desempenho.
O SQL Server permite especificar a quantidade de memória do sistema a ser alocada ao cache do buffer, mas você troca a memória restante para outras tarefas. Seu objetivo é alocar o máximo possível sem prejudicar o desempenho do SQL Server em outras áreas.
Também importante é a expectativa de vida da página, a quantidade de tempo que uma página de informações do banco de dados passa no buffer sem ser acessada novamente. O SQL Server está continuamente despejando páginas do cache de buffer para liberar espaço para as usadas mais recentemente. Mas quanto menos páginas úteis ele encontrar lá, mais ele terá que ler do disco, o que diminui o desempenho.
Métricas como expectativa de vida útil da página e proporção de ocorrências bem-sucedidas no cache do buffer ajudam você a tomar decisões sobre despejar páginas com menos frequência ou aumentar o tamanho do cache.
T-SQL
O SQL Server usa uma linguagem de consulta chamada T-SQL. Em vez de executar instruções SQL ad hoc, o SQL Server tenta melhorar o desempenho agrupando-as em lote, compilando-as como um plano de execução e armazenando-as em cache. Ele também tenta minimizar a frequência de compilação e reutilizar os planos de execução com a maior frequência possível. Se não puder reutilizar o plano de execução - digamos, porque o banco de dados mudou muito - ele recompilará o plano. É melhor manter o número de recompilações de instruções SQL o mais baixo possível, porque o processo pode consumir grandes quantidades de CPU e prejudicar o desempenho.
A necessidade de compilar e recompilar é uma função de boas práticas de codificação, como usar procedimentos armazenados e parametrizar consultas. DBAs que monitoram métricas como a taxa de compilações SQL e recompilações SQL pode modificar as dicas de consulta do SQL Server para melhorar o desempenho.
Bloqueios, esperas e processos bloqueados
É frustrante descobrir que outra pessoa está modificando algo ao mesmo tempo que você. Assim, os bancos de dados bloqueiam automaticamente coisas como linhas e mesas para manter vários cozinheiros fora da cozinha. A compensação para essa proteção, é claro, é que todos os outros usuários devem esperar até que o recurso seja desbloqueado. E é difícil garantir que o bloqueio esteja ocorrendo apenas no nível necessário.
Com métricas que mostram com que frequência e quão amplamente os bloqueios estão afetando outras operações, os DBAs podem determinar a necessidade de mais recursos físicos do sistema para processar transações mais rapidamente. Também pode ser que o SQL Server esteja travando em um nível desnecessariamente baixo. A frequência de esperas de bloqueio e, mais amplamente, o número de processos bloqueados pode ajudar na localização de gargalos.
Elimine gargalos com o ajuste de desempenho do SQL
“Puxa, doutor, você está certo sobre todas as partes móveis. Agora vejo como não posso simplesmente instalar o SQL Server, configurá-lo e esquecê-lo. Eu preciso nutrir o relacionamento. Mas tudo isso ainda parece esmagador. Como vou manter tantas coisas diferentes em ordem e ficar à frente do jogo?”
“Essa é a melhor parte. Existem ferramentas que podem ajudar no desempenho do SQL Server. Você não precisa fazer isso sozinho”.
“Uau! Isso é reconfortante. Eu não sabia disso.”
"Está certo. As ferramentas monitoram o desempenho do seu servidor SQL e relatam todas essas métricas para que você possa aplicar suas técnicas de ajuste e eliminar gargalos.”
"Sério?"
"Certo. E podemos trabalhar nisso direito - oh, que coisa, estamos sem tempo para esta semana. Por favor, marque uma consulta com minha recepcionista e vamos pegar na próxima semana.”
“Cara, essas quatro horas passaram rápido, doutor! O tempo certamente voa quando você está resolvendo problemas de desempenho em torno de fragmentação, uso de recursos e taxa de acertos do cache de buffer , não é?”
“Sim, e tenho certeza de que, uma vez que você se comunique abertamente sobre esses problemas com seu SQL Server, todos os seus problemas de desempenho serão históricos.”
Animado com a nossa sessão, o paciente foi embora. Da próxima vez, trabalharemos no monitoramento de gargalos de desempenho do SQL Server. Vou postar sobre isso, então fique de olho.
Enquanto isso, confie em mim. Sou um profissional pago e encorajo você a experimentar essas coisas em seu próprio relacionamento com seu banco de dados. Faça seu SQL Server se sentir desejado. Preste atenção às suas métricas de desempenho.
Nunca é tarde para tentar.
