[PowerAlerts]: Como o Power alerts nos ajudou a otimizar CPU

Veja como o PowerAlerts, aliado ao olhar atento de uma equipe dedicada 24/7, foi essencial para identificar, otimizar e reduzir o consumo de CPU em um ambiente de alta complexidade e missão crítica.
Detalhes do Alerta:
O alerta de CPU Utilization é disparado quando o consumo de CPU ultrapassa um limite que você define (totalmente personalizável), mas ele vai muito além de um gráfico simples. E é aí que o PowerAlerts se destaca! Esse alerta te dá uma foto completa do que está executando no ambiente: sessões ativas, consumo de recursos, tempos de execução e muito mais. Ou seja, antes mesmo de entrar no sistema, você já sabe quem está causando o problema. Veja um exemplo:
Foi em um domingo ensolarado qualquer que recebemos uma surpresa: começaram a chegar vários alertas de CPU. Embora para muitos isso pudesse parecer normal, nossa equipe de plantão desconfiou, especialmente porque no dia anterior tínhamos registrado apenas 1 alerta.
O que fizemos:
Antes de entrarmos no ambiente analisamos alguns dos alertas que chegaram, vide a primeira foto, e exatamente nessa foto tínhamos o culpado, notaram os INSERTs que aparecem repetidas vezes? Ele faz parte de uma procedure que até então era problemática e quando conectamos fomos olhar justamente ela.
E lá estava tão claro como o dia, a responsável consumindo tanta CPU que o ambiente mal se aguentava:
A primeira coisa que fizemos foi entender o motivo da mudança repentina no comportamento do ambiente, e isso só foi possível graças à nossa equipe 100% focada. Através dos logs, vimos que, até o dia anterior, a procedure usava um plano de execução específico, mas no dia seguinte começou a usar um plano completamente diferente e pior. O motivo? Um parâmetro que alterou seu comportamento. No print, em vermelho está o plano bom e em azul o plano ruim.
Isso acontece devido a um processo chamado Parameter Sniffing. Embora seja útil em algumas situações, ele pode levar ao que chamamos de Parameter Sniffing Problem, mas isso fica para outro momento.
Ações Tomadas:
Agora que entendemos a causa, pudemos focar na solução e atacar a raiz do problema. O primeiro passo foi conversar com o cliente sobre o parâmetro, e ele confirmou que não deveria estar sendo utilizado. Em seguida, realizamos um recompile na procedure, permitindo que o Query Optimizer (QO) refizesse o plano e escolhesse uma opção mais eficiente. O resultado foi exatamente o que queríamos: com essa alteração, conseguimos reduzir em 20% o consumo de CPU em apenas 1 minuto.
E como isso se refletiu no ambiente do cliente, saímos de 26 alertas em um dia para apenas 1, 15 dias depois:
Lições Aprendidas:
Ter uma equipe de olho no ambiente, que além de acompanhar entende o comportamento dele, é o motivo de sermos quem somos #AlwaysTuning
Agora, uma pergunta para você: Se o SQL Server, começasse a ter uma mudança de comportamento agora, em quanto tempo você saberia?
Com o Power Alerts, o tempo de resposta pode ser drasticamente reduzido, minimizando os riscos e prevenindo maiores danos.