Como Investigar um SQL Server Lento: Por Onde Começar

A frase 'SQL Server está lento' parece urgente, mas ainda não é um diagnóstico. Pode significar uma query lenta, todas as queries lentas, utilizadores bloqueados, storage com latência, CPU saturada, mudança de plano depois de um deployment ou até um problema fora do SQL Server. Bom troubleshooting transforma uma queixa vaga num problema específico e mensurável.

Não comeces por mudar configurações

Alterar MAXDOP, limpar plan cache, reiniciar SQL Server ou adicionar memória pode parecer resolver um sintoma, mas também pode destruir evidências ou criar novos problemas. Primeiro recolhe factos.

1. Define o sintoma

• Qual aplicação ou query está afetada?
• Quando começou?
• É constante ou intermitente?
• Afeta um utilizador ou todos?
• O problema é leitura, escrita, ligação, blocking ou timeout?
• Qual era o tempo normal?

Uma query que normalmente demora dois segundos e agora demora dez representa uma regressão. Uma query que sempre demorou dez segundos representa outro tipo de problema.

2. Verifica se alguma coisa mudou

Procura deployments, configurações, patches, estatísticas, índices, crescimento dos dados, novos jobs, batch processes, storage ou failovers. Correlação não é prova, mas uma mudança conhecida fornece um bom ponto de partida.

3. Observa requests e sessões atuais

Requests ativos mostram se uma query está a executar, esperar ou ser bloqueada. Analisa status, wait type, blocking session, CPU, reads, elapsed time e query text. Evita interpretar um número isolado sem contexto.

4. Compreende waits

Wait statistics ajudam a classificar onde as sessões passam tempo. Não dão automaticamente a causa raiz, mas apontam para categorias como locks, I/O, CPU scheduling, memory grants ou parallelism. Relaciona sempre os waits com o workload e período que estás a investigar.

5. Verifica blocking antes de fazer tuning

Uma query rápida pode parecer lenta porque está à espera de outra transação. Identifica o head blocker, duração da transação, recurso bloqueado e se o comportamento é normal. Matar a sessão sem compreender a transação pode criar outro incidente. Para uma explicação específica, consulte bloqueios e deadlocks no SQL Server.

6. Usa Query Store para histórico

DMVs mostram o presente. Query Store ajuda a perceber o passado: que query regrediu, se apareceu um plano novo, como os runtimes mudaram e se os waits se alteraram. Isso é muito útil quando o incidente já terminou.

7. Lê execution plans com contexto

Planos podem mostrar scans, seeks, joins, sorts, lookups, spills, warnings e diferenças entre linhas estimadas e reais. Mas o plano precisa ser ligado a evidência de runtime. O operador com maior custo estimado não é automaticamente a causa real. Explore planos de execução no SQL Server para aprofundar este ponto.

8. Verifica CPU, memória e I/O

Se existe pressão real de recursos, os sinais devem confirmar. CPU elevada pode vir de poucas queries caras. Memory grants podem criar waits. Latência de storage pode tornar queries razoáveis muito lentas. WRITELOG pode apontar pressão no transaction log.

9. Procura regressões de plano e parameter sensitivity

Uma query antes rápida pode ficar lenta com um plano diferente ou quando o plano em cache funciona mal para outro parâmetro. Query Store, planos, estimativas e histórico ajudam a confirmar esse cenário.

10. Verifica tempdb e transaction log

Contenção em tempdb, crescimento inesperado ou gargalos no log podem afetar muitos workloads. Analisa uso e growth antes de alterar ficheiros apenas porque uma recomendação genérica diz para o fazer. Compare este ponto com os modelos de recuperação do SQL Server.

11. Muda uma coisa e mede novamente

Quando a evidência suporta uma hipótese, faz a menor alteração capaz de a testar. Pode ser índice, estatística, reescrita da query, configuração ou mudança na aplicação. Mede antes e depois.

Ordem prática de triage

1. Confirma o sintoma e período.
2. Procura mudanças conhecidas.
3. Analisa requests, sessões e blocking.
4. Revê waits relevantes.
5. Usa Query Store ou monitorização histórica.
6. Inspeciona planos das queries afetadas.
7. Verifica CPU, memória, storage e transaction log.
8. Cria uma hipótese.
9. Aplica uma mudança controlada.
10. Mede e documenta o resultado.

O que evitar

• Reiniciar SQL Server apenas porque está lento.
• Limpar todo o plan cache como primeira ação.
• Criar todos os índices sugeridos automaticamente.
• Alterar várias configurações ao mesmo tempo.
• Assumir que CPU alta significa imediatamente falta de CPU.
• Matar blockers sem compreender a transação.
• Fazer tuning numa query sem provar que ela causa o problema visível.

Performance tuning é investigação

O melhor trabalho de performance muitas vezes é menos dramático do que parece. É medição, comparação e mudança controlada. O objetivo não é minimizar todas as métricas; é fazer o workload cumprir os requisitos sem criar risco desnecessário. O artigo complementar sobre o trabalho de um DBA de SQL Server desenvolve este tema.

Formação relacionada

SQL Server Performance Tuning & Troubleshooting trabalha este método através de waits, DMVs, execution plans, Query Store, índices, estatísticas e incident labs.

Ver o curso de Performance Tuning

Precisa de ajuda para escolher o curso certo?

Se não tiver a certeza por onde começar, contacte a Goalbi Academy e diga-nos qual é o seu nível atual e o que pretende aprender.

Contactar a Goalbi Academy

Referências

Troubleshoot Slow-Running Queries in SQL Server - SQL Server

Monitor Performance by Using the Query Store - SQL Server

Display and save Execution Plans - SQL Server

Understand and Resolve SQL Server Blocking Problems - SQL Server