Performance no SQL Server: guia completo de diagnóstico

"O sistema está lento" é o chamado mais comum e o mais vago que um DBA recebe. Antes de sair mexendo em índices ou reiniciando serviço, existe uma sequência de checagens que localiza a causa raiz em minutos — usando só DMVs (Dynamic Management Views), sem instalar nada.

1. Existe alguém bloqueando alguém?

Bloqueio (blocking) é a causa mais comum de lentidão percebida pelo usuário — não é o servidor que está lento, é uma sessão esperando outra liberar um recurso. Rode:

SELECT
  blocking_session_id, session_id, wait_type, wait_time, wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

Se essa query retornar linhas, o problema não é performance geral — é uma sessão específica (a que aparece em blocking_session_id) travando outras. Investigue essa sessão antes de qualquer outra coisa.

2. O que as sessões ativas estão esperando?

Se não há bloqueio, olhe os wait types agregados — eles dizem por qual recurso as queries estão esperando (disco, CPU, memória, rede):

SELECT TOP 10 wait_type, wait_time_ms, waiting_tasks_count
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('SLEEP_TASK','BROKER_TASK_STOP','CLR_SEMAPHORE')
ORDER BY wait_time_ms DESC;

• PAGEIOLATCH_* alto → gargalo de I/O em disco.
• CXPACKET / CXCONSUMER alto → paralelismo, geralmente ligado a estatísticas desatualizadas ou MAXDOP mal configurado.
• RESOURCE_SEMAPHORE alto → pressão de memória, queries pedindo mais memória do que o servidor consegue dar.
• LCK_M_* alto → voltando ao bloqueio do passo 1.

3. Quais queries estão consumindo mais agora?

Com o tipo de espera identificado, encontre a query específica:

SELECT TOP 10
  qs.total_elapsed_time / qs.execution_count AS avg_elapsed_us,
  qs.execution_count,
  SUBSTRING(qt.text, qs.statement_start_offset/2 + 1,
    (CASE WHEN qs.statement_end_offset = -1
      THEN LEN(CONVERT(nvarchar(max), qt.text)) * 2
      ELSE qs.statement_end_offset END - qs.statement_start_offset)/2 + 1) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
ORDER BY qs.total_elapsed_time / qs.execution_count DESC;

4. Automatizando essa checagem

Essas três queries cobrem 80% dos diagnósticos de "tá lento". O trabalho manual é rodá-las toda vez que alguém reclama e nem sempre pegar o momento exato do pico. É exatamente esse o motivo do codeDB existir: ele roda essas mesmas DMVs a cada 30 segundos e guarda o histórico, então quando alguém reportar lentidão às 14h32 de ontem, você não precisa ter estado logado às 14h32 de ontem pra saber o que aconteceu.

5. Quando não é um pico isolado

O passo a passo acima resolve o "está lento agora". Um padrão diferente é quando a lentidão volta toda semana, ou piora gradualmente ao longo de meses — aí o snapshot de um momento não basta, porque a causa não está mais ali quando você olha. Isso é regressão de performance, e a única forma confiável de pegar é ter histórico: comparar o tempo médio de execução de uma query hoje contra a semana passada, não só olhar o que está rodando neste segundo.

Mapa de causas por sintoma

• Wait type dominante mudou ou cresceu ao longo do tempo → aprofunde nos wait stats, não só no snapshot pontual.
• Uma query específica ficou mais lenta depois de um deploy ou de uma atualização de estatísticas → provavelmente regressão de plano de execução, não falta de recurso.
• CPU consistentemente alta, não só em pico → vale isolar se é uma query específica monopolizando ou distribuído entre várias.
• Mesma query, mesmo volume de dados, ficando mais lenta com o tempo → suspeite de índice ausente ou fragmentado, não do servidor.