Análise de ambiente com o Power Alerts

por David Styveen
em Performance Tuning, PostgreSQL, Power Alerts, Power BI, Power Embedded, Power Pilot, Sem categoria, SQL Server
on 5 de junho de 2025

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.

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

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:

SELECT *
FROM vwPowerRoutine_Log_Counter
WHERE Nm_Counter = 'CPU'
AND Dt_Log BETWEEN '2025-01-26 14:00' AND '2025-01-26 16:00'

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:

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'

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:

SELECT *
FROM vwPowerRoutine_Log_Counter
WHERE Nm_Counter = 'BatchRequests'
AND Dt_Log BETWEEN '2025-01-26 14:00' AND '2025-01-26 16:00'

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:

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'

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:

SELECT *
FROM PowerRoutine_Log_WhoIsActive
WHERE Dt_Log BETWEEN '2025-01-26 14:00' AND '2025-01-26 16:00'
ORDER BY Dt_Log

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”:

SELECT *
FROM PowerRoutine_Queries_Profile
WHERE StartTime BETWEEN '2025-01-26 14:00' AND '2025-01-26 16:00'
ORDER BY StartTime

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:

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

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).

Tags: ambiente SQL Server, análise de desempenho, análise de instância, análise de lentidão, análise de performance, banco de dados, Batch Requests, bloqueios SQL, conexões SQL, CPU alta, indicadores de performance, lentidão em sistemas, monitoramento de SQL, otimização de consultas, Page Life Expectancy, performance sql server, PLE, Power Alerts, power tuning, PowerRoutine, queries demoradas, queries lentas, queries pesadas, SCAN SQL, SQL performance troubleshooting, SQL SERVER, SQL tuning, stpPowerReport_SQL_Performance, TempDB, tuning de queries, tuning de SQL

Análise de ambiente com o Power Alerts