Por que o ajuste de desempenho do SQL é tão importante para o gerenciamento de banco de dados?
Porque você pode economizar muito dinheiro. Tenha paciência comigo e você verá como.
Ajuste de desempenho SQL e gerenciamento de banco de dados — conectando os pontos
A maioria dos profissionais de banco de dados gasta seu tempo mantendo as luzes acesas. Eles investem a maior parte de seus esforços para garantir o tempo de atividade, mantendo-se atentos a recursos como memória, armazenamento e taxa de transferência da rede. Essa é uma grande parte do gerenciamento de banco de dados, mas à medida que mais empresas movem seus bancos de dados para recursos de nuvem quase ilimitados, como AWS e Azure, outros aspectos se tornam mais importantes.
O ajuste de desempenho do SQL é um desses aspectos. Uma vez que as luzes são mantidas com segurança e você sobe na hierarquia de necessidades no gerenciamento de banco de dados, a próxima coisa que você deseja é um melhor desempenho, e isso requer ajuste.
Primeiras perguntas a serem feitas ao ajustar o desempenho em SQL
Mais cedo ou mais tarde, muitos profissionais de banco de dados se encontram diante de um SQL Server que não construíram. Não há muitos guias de instruções para essa situação. O ajuste de desempenho do SQL é um exercício para investigar, descobrir o que está errado e corrigi-lo iterativamente.
Em suas primeiras correções, você pode nem mesmo tocar em instruções SQL. Alguns profissionais de banco de dados começam no nível do usuário/sessão. Eles vão até onde os usuários estão insatisfeitos, ouvem como suas reclamações soam e fazem perguntas.
- Quais telas ou páginas demoram muito para renderizar?
- O aplicativo fica mais lento quando cria um novo ticket ou abre um existente?
- Demora muito para salvar um registro?
- Quanto tempo é "muito tempo?"
Uma vez que eles tenham essas respostas, eles vão ver o que no banco de dados está causando isso.
Isso é melhor do que sentar no primeiro dia e decidir lidar com algo como fragmentação, que pode não afetar os usuários. O ponto é começar com o que os usuários se preocupam.
Pense também no nível da instância/banco de dados. No mundo da Microsoft, por exemplo, os trabalhos do SQL Server Agent são um bom ponto de partida. Eles são uma série de ações que geralmente definem uma tarefa administrativa que você pode monitorar quanto ao sucesso ou falha. Eles devem ser convenientes, mas como muitas coisas no gerenciamento de banco de dados, eles tendem a se acumular à medida que as pessoas esquecem como se originaram e o que fazem.
Você pode encontrar vários trabalhos fazendo a mesma coisa, como executar versões diferentes de um script de índice ou, pior ainda, trabalhar uns contra os outros. Examine os trabalhos já configurados à luz de duas perguntas:“O que este trabalho faz?” e, mais importante, “Se eu parar com esse trabalho, alguma coisa ruim vai acontecer?”
Quais fatores você deve procurar?
Uma vez que você chega ao nível de ajuste de desempenho do SQL, ele recebe suas dicas de comportamento de vários fatores. Conforme descrito durante nosso webcast Pergunte aos especialistas:Mesa redonda sobre desempenho de banco de dados, você pode gastar menos tempo ajustando o próprio SQL se encontrar e interpretar corretamente fatores como estes:
- Bloqueando — Se o servidor estiver bloqueando, é como uma bomba-relógio. Suponha que um script inicie uma transação e não a feche; isso pode levar a um arquivo de log que cresce e cresce até que o espaço se esgote. O bloqueio é uma má notícia para o desempenho, então procure-o logo de cara.
- Agentes — Com relação aos trabalhos do SQL Server Agent, os administradores são conhecidos por agrupar inadvertidamente tarefas que prejudicam o desempenho em trabalhos. Eles podem executar transações ou reconstruir índices em um trabalho ou reduzir o banco de dados em uma transação. Em um caso como esse, considere desabilitar o agente temporariamente para encerrar todos os trabalhos associados. É uma técnica agressiva, mas se melhorar o desempenho, você saberá o motivo.
- Estatísticas de espera — Pergunte a si mesmo:“O que o servidor está esperando agora?” Métricas como expectativa de vida da página e comprimento da fila do disco têm algumas respostas, mas oferecem apenas uma visão restrita. As estatísticas de espera mostram tudo através das lentes dos tipos de espera e categorias de espera, permitindo que você se concentre nos cinco ou mais eventos de espera que consomem mais tempo. O sp_BlitzFirst de Brent Ozar é um procedimento armazenado confiável para descobrir o que suas consultas do SQL Server estão esperando no momento. Então, quando você quiser estudar padrões de longo prazo nas estatísticas de espera do seu servidor, procure uma ferramenta de monitoramento de desempenho.
- Atividade do administrador — Isso também é conhecido como “erro do piloto”, porque alguns problemas de desempenho surgem do que você está fazendo. Suponha que você esteja executando o SQL Server Activity Monitor e o SQL Server Profiler ao mesmo tempo, tentando aprender o Query Store. Você não pode superar o efeito do observador; quando você rastreia tudo assim, está apenas pedindo que o banco de dados fique mais lento.
- Índices — Para algo que deveria ser benéfico, os índices certamente podem causar dor no pescoço. Na verdade, eles merecem mais do que apenas uma bala. Continue lendo.
O ajuste de desempenho do SQL significa examinar os índices com atenção
Em grande parte, o ajuste de desempenho do SQL se resume ao ajuste de índice. Felizmente, se você dominar isso para o gerenciamento de banco de dados local, suas habilidades serão facilmente transferíveis para o gerenciamento de banco de dados na nuvem.
O ajuste de índice está ganhando importância devido à variedade em evolução de índices:clusterizado, não clusterizado, exclusivo, filtrado, columnstore, hash, não clusterizado com otimização de memória, XML, espacial e de texto completo, para citar alguns. Mas uma coisa que nunca mudou é a primeira coluna do índice, que orienta as decisões de índice feitas pelo mecanismo de banco de dados.
Muitos fornecedores vendem e implantam aplicativos com muitos índices bem intencionados que acabam nunca sendo usados ou, pior ainda, prejudicam o desempenho. Se você examinar os scripts de índice não utilizados ou scripts de consumo de índice em alguns produtos de software, encontrará um excesso de índices em uma chave estrangeira. Se o produto usa, digamos, 20 chaves estrangeiras, os fornecedores podem enviar até 20 índices, mais dez índices de coluna única, mais outros dez índices em um índice clusterizado exclusivo e assim por diante.
Sempre que você tiver a opção, a melhor maneira de abordar a arquitetura do banco de dados é começar com um índice clusterizado que você acha que representará melhor a tabela. Em seguida, deixe o sistema funcionar sozinho por um tempo. Se e como você precisar de mais índices, crie-os. Adicionar índices é um exercício de troca de melhor desempenho aqui com problemas como preenchimento de espaço em disco e travamento ali. Torna-se difícil ver como cada índice adicional afeta o sistema como um todo.
Nesse sentido, considere eliminar índices – da mesma forma que uma pessoa com alergias eliminaria grupos de alimentos – para ver como o desempenho muda. Tente eliminar todos os índices em sua instância dev e veja quais afetam suas cinco principais consultas.
Ajuste de desempenho no SQL Server — ferramentas que o acompanham
Observe que você não está sozinho nessa empreitada. O SQL Server inclui recursos projetados para melhorar o desempenho.
Os guias de plano permitem alterar como o SQL Server executa uma determinada consulta e, embora não seja um ajuste de desempenho puro do SQL, ele afeta o desempenho. Muitos aplicativos contêm consultas SQL escritas por um fornecedor externo e, mesmo que essas consultas causem baixo desempenho, alguns profissionais de banco de dados estão compreensivelmente relutantes em alterá-las. Com os guias de plano, você pode anexar uma dica de consulta ou um plano fixo à consulta e influenciar como ela é executada.
No entanto, a desvantagem dos guias de plano é que, embora eles não mudem com o tempo, o ambiente ao seu redor muda. Como um roteiro impresso, eles podem funcionar bem no curto prazo e se tornar obsoletos em pouco tempo, então se você vai confiar neles, é melhor revisitá-los ocasionalmente.
Relacionado aos guias de plano está o Query Store, um recurso do SQL Server que ajuda a identificar e ajustar as consultas que consomem mais recursos em seu sistema. O Repositório de Consultas não está habilitado por padrão para novos bancos de dados SQL Server e Azure Synapse Analytics (SQL DW). Mas está habilitado por padrão nos novos Bancos de Dados SQL do Azure.
Em geral, não é difícil habilitar o Query Store, mas nem todo SQL Server precisa dele desde o início. Alguns administradores não conhecem o Query Store, e alguns o conhecem, mas ainda não tiveram tempo de explorá-lo adequadamente; é melhor deixá-lo desabilitado. Mais tarde, quando eles entenderem como o Repositório de Consultas funciona, eles poderão usá-lo para encontrar diferenças de desempenho causadas por alterações no plano de consulta.
Por fim, o Database Engine Tuning Advisor analisa as cargas de trabalho e recomenda índices ou estratégias de particionamento para melhorar o desempenho da consulta. Executar o Tuning Advisor em seu banco de dados é uma boa ideia; apenas não o execute tão cedo. Certifique-se de que seu banco de dados contenha dados suficientes para que as recomendações de índice sejam válidas. Quando você está construindo seu aplicativo pela primeira vez, você pode ter apenas mil linhas em cada tabela. As recomendações do Tuning Advisor são mais úteis quando o banco de dados cresce.
Mostre-me o dinheiro
Como mencionei no início, o ajuste de desempenho do SQL é importante para o gerenciamento de banco de dados porque pode economizar dinheiro. Como?
Especialmente na nuvem, onde o escalonamento por cartão de crédito é popular, as equipes de TI estão descobrindo o quanto o armazenamento mensal pode ser caro. Além disso, eles estão começando a entender que executar consultas mal escritas e permitir que AWS e Azure gerenciem seus índices aumenta seus custos de computação em nuvem. Consultas lentas e índices ruins custam dinheiro.
O ajuste de desempenho do SQL consiste em acertar todas essas coisas. Dessa forma, independentemente de você permanecer no mundo do OpEx local ou migrar para o mundo de CapEx da nuvem, você mantém o controle sobre seus gastos.
