Análise de ambiente com o Power Alerts

Como analisar a performance do ambiente com o Power Alerts?
Olá, pessoal!
Este post tem como objetivo demonstrar um passo a passo para analisar a performance da sua instância utilizando as coletas do Power Alerts.
Se ainda não tem o Power Alerts na sua instância, você pode fazer o seu Trial de 30 dias para conhecer melhor a ferramenta.
Iniciando a análise:
Geralmente temos dois principais pontos de partida para uma análise de performance:
- Usuário informando dificuldade para realizar alguma atividade no momento;
- Alguma ocorrência ou chamado informando que em tal dia e horário teve algum problema de lentidão;
Em ambos os casos, temos a notificação da ocorrência porém não temos detalhes do problema.
Então, pode onde começar?
Para isso podemos executar a procedure “stpPowerReport_SQL_Performance” que irá nos apresentar alguns indicadores que nos darão o norte para nossa análise.
Para fins didáticos, vamos imaginar que houve um relato de lentidão no dia 26/03/2025 por volta das 15h.
Portanto, iremos pedir a análise de 14 as 16 horas, para iniciar a investigação.
1 2 3 4 5 6 7 |
DECLARE @email VARCHAR(1000) = 'mail@powertuning.com.br' , @Dt_Start DATETIME = '2025-03-26 14:00' , @Dt_End DATETIME = '2025-03-26 16:00' EXEC Traces.dbo.stpPowerReport_SQL_Performance @Ds_Email=@email ,@Dt_Start=@Dt_Start ,@Dt_End=@Dt_End,@Ds_Query = null |
Será enviado para o seu e-mail os gráficos de análise do período informado.
Abaixo iremos falar mais sobre eles.
-
CPU
Em CPU podemos verificar que o consumo é relativamente linear, porém as 15h00 de fato teve uma elevação.
Esse poderia ser o primeiro ponto de análise: identificar o que fez o consumo de CPU aumentar e analisar as possíveis aplicações de tuning.
Para realizar essa análise podemos consultar as tabelas observando as colunas CPU e CPU_Delta:
- PowerRoutine_Log_WhoIsActive
- PowerRoutine_Queries_Profile
- PowerRoutine_CPU_Query_Use
Para verificar o consumo de CPU por determinado período podemos utilizar o comando abaixo:
1 2 3 4 |
SELECT * FROM vwPowerRoutine_Log_Counter WHERE Nm_Counter = 'CPU' AND Dt_Log BETWEEN '2025-01-26 14:00' AND '2025-01-26 16:00' |
-
PLE
No gráfico do PLE podemos notar uma queda significativa às 15h00. Isso pode significar pressão de memória.
Então, entra aqui nosso segundo ponto de análise: identificar o que ocorreu para ocasionar a queda do PLE.
Pode ser alguma ou algumas queries com SCAN gigantes gerando pressão na memória e derrubando o PLE, ou também pode ser alguma ação externa ao SQL.
Para realizar essa análise podemos consultar as tabelas, observando as colunas Reads, Reads_Delta, Writes, Writes_delta e used_memory:
- PowerRoutine_Log_WhoIsActive
- PowerRoutine_Queries_Profile
Para verificar os indicadores de PLE podemos utilizar o comando abaixo:
1 2 3 4 |
SELECT * FROM vwPowerRoutine_Log_Counter WHERE Nm_Counter = 'Page Life Expectancy' AND Dt_Log BETWEEN '2025-01-26 14:00' AND '2025-01-26 16:00' |
-
Batch Requests
No gráfico de Batch Requests irá nos mostrar a quantidade de requisições.
É possível notar que às 15h00 houve um aumento significativo de requisições, até as 15h30, voltando normalizar às 15h35.
O aumento de requisições pode demonstrar uma necessidade de melhoria tuning ou hardware, para comportar melhor horários de picos.
Para verificar como estão os Batch Request de determinado período podemos utilizar o comando abaixo:
1 2 3 4 |
SELECT * FROM vwPowerRoutine_Log_Counter WHERE Nm_Counter = 'BatchRequests' AND Dt_Log BETWEEN '2025-01-26 14:00' AND '2025-01-26 16:00' |
-
Quantidade de Conexões
As quantidades de conexões se manteram estáveis no período.
Um desbalanceamento nesse gráfico poderia mostrar o comportamento dos usuários, se há picos em determinandos dias, horários, etc.
Para verificar as quantidade de conexões podemos utilizar o comando abaixo:
1 2 3 4 |
SELECT * FROM vwPowerRoutine_Log_Counter WHERE Nm_Counter = 'User_Connection' AND Dt_Log BETWEEN '2025-01-26 14:00' AND '2025-01-26 16:00' |
-
Bloqueios
Analisando o gráfico de bloqueios podemos identificar um ligeiro aumento na quantidade de bloqueios no período informando. Tanto em quantidade como em tempo.
Isso pode sinalizar que o ambiente esteja enfrentando concorrência por objetos e a lentidão, na verdade, é a espera pela liberação dos recursos e não por uma query lenta ou falta de recursos.
Como ponto de análise seria identificar as queries e analisar o plano de execução em busca de melhorias.
As vezes será necessária uma reescrita por parte da aplicação para evitar essas concorrências.
Para realizar essa análise podemos consultar a tabela “PowerRoutine_Log_WhoIsActive”, observando as colunas session_id, blocking_session_id, wait_info e wait_resource:
1 2 3 4 |
SELECT * FROM PowerRoutine_Log_WhoIsActive WHERE Dt_Log BETWEEN '2025-01-26 14:00' AND '2025-01-26 16:00' ORDER BY Dt_Log |
-
Queries Demoradas
Podemos observar que houve um aumento na quantidade de queries demoradas (maiores que 3 segundos) no horário informado. Devemos analisar a situação procurando duas principais ocorrências:
- Repetições da mesma query: caso identifiquemos esse cenário, devemos atuar na melhoria dessa query para otimizar o consumo da instância
- Alto consumo: identificar queries que possam estar recrutando muitos recursos e penalizando as demais, gerando o aumento do tempo.
Aqui é importante ter em mente que cada caso é um caso.
Por isso a importância de analisar e identificar os dois cenários descritos anteriormente mas não se ater somente à eles.
Nem sempre teremos uma query “bomba” ou várias da “mesma consulta” sendo executados no momento.
As vezes teremos cenários homogênios e precisaremos ir priorizando por ordem de importância e impacto.
Ao identificar as query ofensoras devemos verificar seu impacto no negócio, pois uma query isolada pode resolver a dor do usuário ou do negócio no momento. Ou seja, deixar o ambiente mais rápido mas, esse processo específico lento, não estaremos resolvendo o “problema de lentidão” do usuário em um faturamento de folha, por exemplo.
Para realizar essa análise podemos consultar a tabela “PowerRoutine_Queries_Profile”:
1 2 3 4 |
SELECT * FROM PowerRoutine_Queries_Profile WHERE StartTime BETWEEN '2025-01-26 14:00' AND '2025-01-26 16:00' ORDER BY StartTime |
Nessa visão temos o mesmo conceito do item anterior, porém ela nos mostrará as concorrências desse período.
Portanto, podemos ver que a consulta 1304757 iniciou próximo às 15h00 e já haviam algumas outras rodando.
Por ser um horário bem próximo da reclamação, podemos verificar essa consulta para analisar se ela pode estar relacionada ao ocorrido no ambiente.
A análise também poderá ser feita na tabela “PowerRoutine_Queries_Profile” informando o ID da consulta:
1 2 3 4 5 |
SELECT * FROM PowerRoutine_Queries_Profile WHERE StartTime BETWEEN '2025-01-26 14:00' AND '2025-01-26 16:00' AND Id_Part_Query = 1304757 ORDER BY StartTime |
-
TempDB
Pelo gráfico, podemos notar um aumento no período informado no consumo da TempDB.
A utilização da tempdb está atrelada a utilização de tabelas temporárias, organização de ordem das consultas (order by), spill de memória, além de concorrência dentro de seus próprios arquivos.
Como ela utiliza o disco, o fator hardware poderá pesar nessa análise.
Para realizar essa análise podemos consultar as tabelas, observando as colunas tempdb_allocations, tempdb_current, tempdb_allocations_delta e tempdb_current_delta:
- PowerRoutine_Log_WhoIsActive
- PowerRoutine_Tempdb_Query_Use
- PowerRoutine_Tempdb_File_Used
Conclusão
Essas foram as principais análise de performance que podemos fazer em nossa instância em busca de melhorias e identificar ofensores de performances.
Há muitos mais outros dados coletados que podem ajudar em análises mais aprofundadas de ocorrências do dia a dia.
Se interessou? Entre em contato com o comercial e solicite já o seu.
Artigo desenvolvido por David Styveen (Tech Leader).