Um ponto que muitos não tem aprofundamento de conhecimento, é o tunning de querys. O tunning de um ambiente é fundamental para garantir performace, consistência e durabilidade em um ambiente.
Há diversos meios de realizar tunning em ambientes, e há diversos pontos a serem focados. Nosso foco aqui será realizar tunning em bases SQL Server.
Para isso, o primeiro ponto que temos avaliar: em seu ambiente atual, qual o problema mais visível e que mais impacta nos serviços? Há diversas hipóteses, diversos itens a serem avaliados: Querys lentas, excesso de conexões, time out, alto consumo de memória, alto consumo de disco, etc.
Neste post, o foco são as querys, onde encontramos a maioria dos problemas e poucos sabem como atuar.

O SQL Server dispõe de uma ferramenta que chama “Tunning Advisor”. Esta ferramenta tem como função ‘destrinchar’ sua query apontando suas falhas, e melhorias que possam ser realizadas.

Além da ferramenta, você pode realizar o tunning na mão. Para realizar, você deve prestar atenção em diversos pontos que irão te representar custos e necessidades de mudanças em sua query.

1° passo: Execution Plan
> Como rodar: Colete a query que te apresenta problemas de performace e abra uma nova query de teste em seu management studio. Ao invés de executa-la, solicite o execution plan:

2° Passo: Avaliando os resultados

Este processo irá ‘destrinchar’ sua query, destacando cada etapa. Nesta hora é importante olhar:
Indicação de índice ->  Ao executar, ele te indica a criação de um índice para suprir sua consulta. Este índice irá refletir na performace direta de sua query. Com esta dica, o SQL te dá o script completo da criação, basta, em cima do texto verde pressionar botão direito do mouse e escolher a opção “Missing Index Details…”
Etapas com maiores porcentagens -> Nestas etapas começamos a analizar onde podemos melhorar a query. Com o execution plan, ao pararmos o mouse sobre uma etapa, ele abre uma janela de informações. Esta, temos que avaliar principalmente: Estimated I/O cost, Estimated CPU cost e Estimated Operator Cost. Caso estes valores estejam acima de 1%, será necessário avaliar, pois há custo alto para sua query. Nesta etapa avaliamos também Object (qual índice esta etapa utiliza) e output list (saida de dados). Se comparado ao índice usado, supri o output?

OBS1 : Sempre haverá uma etapa com um valor alto. A execução total deve somar 100%, não é porque esta porcentagem é alta, que esta operação é o ‘problema’ da query
OBS2: seja coerente ao criar índices. Índices colaboram para o desempenho, mas geram consumo e em excesso não são bons.

3° Passo: Avaliação das estatísticas da query

Ao realizar as alterações, podemos pegar estatísticas da query que irão auxiliar caso sejam necessários mais ajustes.
Para isso, antes de sua query, você deve ‘ligar’ algumas opções e após ela, desliga-las.

Ao executar a query, na aba de mensagens, ele lhe apresentará informações importante das estatísticas que devem ser avaliadas:
cpu time -> tempo real de execução
elapsed time -> tempo de espera no servidor
scan -> é quantas vezes ele precisou passar pelo arquivo clustered, pelos dados mesmo.
logical reads -> é as leituras que ele fez em índices
physical reads -> (o problema das querys) quando usado é que ele está precisando ir na HD. Pode ser por falta de espaço no cache, falta de memória ou consulta bem ruim mesmo.

Estes números são sua base. É interessante rodar esta consulta antes mesmo de rodar o execution plan, para ter números comparativos. Observe que em alguns casos, pode até mesmo passar por problemas de hardware. Um bom desempenho do banco também depende de um bom hardware. SQL não faz milagre.

See you amiguinhos!