Performance Tuning #2

Fala pessoal, nesse post vou continuar a serie sobre performance tuning, hoje vou trazer algumas ferramentas que você pode usar para coletar dados para realizar um tuning.

No post anterior vimos que o tuning é um conjunto de ações que você executa para manter o bom desempenho de um ambiente SQL Server, com o passar do tempo, o aumento do volume de dados, as aplicações tendem a ficar mais lentas, e é justamente ai onde entra o tuning, otimizar recursos de hardware, ajustar configurações do SQL server, otimizar querys com índices, manutenção preventiva de índices e estatísticas ou até mesmo mudar a estrutura de um comando na aplicação.

Podemos dividir os tunings em duas categorias: os que você realiza de forma pro ativa, sem ter um problema acontecendo e os que fazem parte da resolução de um problema, ou seja, alguém reclamou de lentidão e você verifica o ambiente e vê a necessidade de realizar um tuning.

Mas como eu consigo definir onde esta o problema para atuar diretamente nele?

Você precisa de informações, geralmente um bom indicador é o próprio usuário da aplicação.

Quando esta com algum tipo de lentidão, por padrão eu sempre faço alguns questionamentos, qual a ação tomada, qual a tela, em que botão clicou. Isso na maioria das vezes já ajuda e muito a direcionar a analise e entender o problema, que é a primeira etapa do tuning.

Tanto para o tuning pro ativo quanto para uma resolução de problemas, por experiência, eu monto uma espécie de checklist na cabeça eu sempre analiso por camadas. Inicio pelos fatores externos, rede, cpu, memória e disco. Alguns desses indicadores já irão sinalizar algum possível problema, as vezes alto consumo de cpu ou até gargalo de rede por exemplo. Se o problema é de cpu, quando eu vou pra segunda camada que é dentro do SQL server eu já consigo canalizar minha analise focando no contador de cpu, quais querys estão consumindo mais, ou se uma query esta executando repetidas vezes seguidas e consumindo bastante cpu.

Para realizar toda essa análise você pode usar algumas ferramentas do próprio windows e outras do SQL Server.

Na camada externa

De maneira mais simples e rápida podemos observar o Task Manager(gerenciador de tarefas), ele é simples, mas de uma forma muito direta e sem muito esforço você já consegue ver informações importantes de memória, cpu e disco. Através dele você consegue notar de cara se tem alguma coisa errada no ambiente que possa estar precisando de um tuning.

Aprofundando um pouco mais nos recursos do servidor temos o Performance monitor (perfmon), em linhas gerais você consegue aprofundar mais em contadores não somente do windows mas também em paralelo algumas informações da instância do SQL Server e do banco de dados.

Essas informações te darão base e direcionamento em um possível problema que esteja acontecendo, se esta atuando de forma pro ativa, existem tantas possibilidades de analise, por onde começar ou focar? Esses indicadores podem te ajudar com isso.

Passando para dentro do SQL Server, onde começamos a avaliar também as querys temos o Monitor de atividades.

Eu particularmente não costumo utilizar essa ferramenta, mas ela é bem bacana também, reúne muitas informações de maneira bem intuitiva. Nela você pode ver os processos em execução no ambiente, informações sobre os tipos de esperas que estão ocorrendo, leitura e escrita de disco por arquivo do banco de dados, e um histórico recente das querys que mais consumiram recursos.

O que mais costumo utilizar é o SQL Server Profiler, através dele executamos o que chamamos de 'trace', um rastreamento do que esta sendo executando no banco de dados. Ela é fácil de configurar e reúne informações importantes para realizar um tuning.

Faça o logon na ferramenta escolhendo a instância que deseja rastrear.

Defina um nome, escolha um template (conjunto de eventos que serão rastreados), você pode optar por salvar o resultado em um arquivo ou em um a tabela em um banco de dados, por último pode configurar uma data/hora para que o rastreamento pare de executar automaticamente.

Na aba eventos, você pode escolher quais deseja rastrear e também definir quais informações deseja coletar como a query que executou, consumo de cpu, leituras e escritas dessa query, qual a aplicação e maquina que rodou o comando no banco, dentre outras tantas opções. Clicando em Columns Filters, você pode refinar o rastreamento com algum parâmetro (é altamente recomendado que filtre).

Boa pratica é executar o profiler em uma maquina a parte, nem sempre isso é possível, mas se tiver a possibilidade faça isso.

Uma outra ferramenta( se é que podemos chamar assim) que é ainda mais completa que o SQL Profiler são os Extend Events. Eles te permitem rastrear tudo o que o profiler faz e ainda te da mais informações relevantes mesclando com contadores do sistema operacional. A forma de configurar e visualizar é diferente do profiler mas você tem muitas possibilidades a mais.

O SQL Profiler pode ser descontinuado em breve, por conta dos XE. Eu utilizo o XE em alguns momentos para coletar dados para tuning, mas hoje o que mais uso é o Profiler mesmo, é mais rápido e simples de configurar e atende ao que eu preciso.

Estou acostumado com a ferramenta também, atuando com ela a 10 anos. Se de fato ela for descontinuada, passarei a focar 100% nos XE para essas atividades.

Uma outra possibilidade que tenho usado recentemente é o Query store. Como o próprio nome diz, é um repositório de comandos executados que te permite ver os planos de execução dessas querys para de uma forma gráfica e que te ajuda a ranquear, por maior consumo de cpu, maior consumo de memória, duração. Assim como o profiler e XE o Query store precisa ser configurado e habilitado.

Independente da forma e ferramenta que você optar para coletar, o importante é que com essas informações em mãos você já tem condições de começar a avaliar as querys que estão tirando performance do ambiente ou que estão lentas para otimiza-las.

O DBA que atua com tuning precisa conhecer essas ferramentas mais a fundo, para saber quando usar cada uma delas.

A partir de agora, você já entendeu o problema e montou um diagnostico usando as ferramentas. Chegou o momento de começar a execução, no próximo post dessa serie vou falar sobre o plano de execução das querys.

Nos acompanhe em nossas redes sociais!

Youtube(vídeos novos todas as quartas): https://www.youtube.com/channel/UChFeqc-m7HZNdkoP0CshMGQ

Face & Instagram(conteúdo diário): dba on boarding

Até a próxima, tchau!

#CG_Performance