Você abre o chamado às 8h da manhã: "o sistema está lento". A aplicação trava, os usuários reclamam, o gestor cobra. Mas "lento" pode ter dezenas de causas diferentes — e aplicar a solução errada pode piorar tudo.
Depois de 25 anos administrando bancos Oracle em ambientes de missão crítica, posso afirmar: o diagnóstico correto resolve 80% do problema. O erro mais comum que vejo em empresas é atacar os sintomas (reiniciar o banco, matar sessões, aumentar memória às cegas) em vez de investigar a causa raiz.
Neste guia, vou te mostrar o processo exato que uso para diagnosticar lentidão em Oracle Database — do primeiro sinal de alerta até a identificação precisa do gargalo.
1. Antes de tudo: pergunte as coisas certas
Antes de abrir qualquer ferramenta, faça estas perguntas:
- Quando começou? A lentidão foi gradual ou súbita? Se foi de repente, provavelmente houve uma mudança: deploy, coleta de estatísticas, alteração de parâmetro, crescimento de dados.
- É generalizada ou específica? Todo mundo está lento, ou só quem usa determinada funcionalidade? Isso determina se o problema é de infraestrutura (I/O, CPU, memória) ou de uma query/módulo específico.
- Houve alguma mudança recente? Patch, upgrade, migração, novo módulo, alteração de índice, coleta de estatísticas. Mudanças são a causa mais comum de regressão de performance.
Essas respostas já reduzem drasticamente o escopo da investigação.
2. Gere o AWR Report — sua radiografia do banco
O AWR (Automatic Workload Repository) é a ferramenta mais importante para diagnóstico de performance Oracle. Ele captura snapshots periódicos do estado do banco e permite gerar relatórios comparativos.
Selecione o período que cobre a janela de lentidão. O relatório HTML gerado é extenso, mas você precisa focar em apenas 4 seções:
2.1. DB Time vs Elapsed Time
Se o DB Time é muito maior que o tempo real (elapsed), significa que múltiplas sessões estão consumindo o banco simultaneamente. Um DB Time de 120 minutos em 30 minutos de elapsed indica, em média, 4 sessões ativas o tempo todo.
2.2. Top 5 Timed Events (Wait Events)
Esta é a seção mais reveladora. Os wait events dizem exatamente onde o banco está gastando tempo:
- db file sequential read — Leitura de disco single-block (index scan). Se domina o AWR, indica I/O lento ou falta de cache (buffer cache pequeno).
- db file scattered read — Full table scans. Queries lendo tabelas inteiras por falta de índice adequado.
- log file sync — Commits lentos. Problema no storage dos redo logs ou commits excessivos.
- enq: TX - row lock contention — Sessões esperando lock em linhas. Problema de concorrência na aplicação.
- latch: shared pool — Contenção de shared pool. Hard parsing excessivo (falta de bind variables).
2.3. Top SQL by Elapsed Time
Mostra as queries que mais consumiram tempo. Normalmente, 3-5 queries são responsáveis por 80% do DB Time. Anote os SQL_ID das top consumers — vamos precisar deles.
2.4. Instance Efficiency Percentages
Olhe o Buffer Hit Ratio. Se estiver abaixo de 95%, o buffer cache pode estar subdimensionado. Mas cuidado: hit ratio alto não garante performance boa — pode significar apenas que as queries estão relendo os mesmos dados ineficientemente.
3. Mergulhe no ASH para análise em tempo real
O ASH (Active Session History) complementa o AWR com granularidade de segundo. Enquanto o AWR mostra o resumo do período, o ASH mostra o que estava acontecendo em cada instante.
ROUND(COUNT(*)*100/SUM(COUNT(*)) OVER(), 1) AS pct
FROM v$active_session_history
WHERE sample_time > SYSDATE - 2/24
GROUP BY event
ORDER BY samples DESC
FETCH FIRST 10 ROWS ONLY;
Para investigar um SQL_ID específico que apareceu no Top SQL do AWR:
COUNT(*) AS samples
FROM v$active_session_history
WHERE sql_id = '<seu_sql_id>'
AND sample_time > SYSDATE - 1/24
GROUP BY sql_id, event, blocking_session
ORDER BY samples DESC;
4. Investigue as sessões ativas
Se o problema está acontecendo agora, olhe diretamente quem está consumindo o banco:
s.event, s.wait_class, s.seconds_in_wait,
s.sql_id, s.blocking_session
FROM v$session s
WHERE s.status = 'ACTIVE'
AND s.type = 'USER'
ORDER BY s.seconds_in_wait DESC;
Preste atenção em:
- blocking_session — Se não for NULL, essa sessão está bloqueada por outra. Siga a cadeia até encontrar o bloqueador raiz.
- seconds_in_wait — Sessões esperando há muito tempo são suspeitas.
- event — O que cada sessão está esperando confirma ou descarta as hipóteses do AWR.
5. Os 5 vilões mais comuns (e o que fazer com cada um)
Vilão 1: Query mal otimizada
Responsável por 60%+ dos casos de lentidão que atendo. Uma única query com full table scan em uma tabela de milhões de linhas pode derrubar o banco inteiro. Solução: análise do execution plan, criação de índices adequados, reescrita de SQL. Em casos urgentes, SQL Plan Baselines ou SQL Profiles podem forçar um plano melhor sem alterar código.
Vilão 2: Lock contention
Múltiplas sessões tentando modificar as mesmas linhas simultaneamente. Comum em batch jobs que rodam no mesmo horário ou em designs de tabela que concentram updates em poucas linhas (sequências, contadores). Solução: identificar o bloqueador raiz, revisar a lógica de concorrência da aplicação.
Vilão 3: I/O saturado
O storage não consegue atender a demanda de leitura/escrita. Comum em ambientes com storage compartilhado ou discos subdimensionados. Solução: análise de IOPS e latência no SO, otimização de queries para reduzir I/O desnecessário, configuração de ASM e storage adequados.
Vilão 4: Memória insuficiente
Buffer cache pequeno demais causa excesso de physical reads. Shared pool subdimensionado causa hard parsing. PGA insuficiente força sort-to-disk. Solução: análise dos advisory reports do AWR (Buffer Pool Advisory, PGA Target Advisory) e ajuste de parâmetros SGA/PGA.
Vilão 5: Estatísticas desatualizadas
O otimizador Oracle depende de estatísticas para escolher o melhor execution plan. Estatísticas desatualizadas (ou recém-coletadas com configuração errada) levam a planos subótimos. Solução: verificar quando as estatísticas foram coletadas pela última vez, validar se o método de coleta é adequado, considerar o uso de SQL Plan Baselines para estabilidade.
6. Checklist rápido de diagnóstico
Use este checklist como roteiro quando receber o chamado de "banco lento":
- Confirmar se é realmente o banco (e não rede, aplicação ou storage)
- Gerar AWR Report do período de lentidão
- Analisar Top 5 Wait Events
- Identificar Top SQL consumers
- Verificar sessões bloqueadas (v$session + blocking_session)
- Checar uso de CPU/memória/disco no SO
- Verificar espaço em tablespaces (especialmente TEMP e UNDO)
- Consultar alert.log para erros recentes
- Verificar se houve coleta de estatísticas recente
- Documentar achados e plano de ação antes de agir
7. Quando escalar para suporte especializado
Se após seguir este roteiro você identificou o problema mas a correção exige mudanças em parâmetros de produção, reescrita de queries complexas, ou reestruturação de índices — considere trazer alguém com experiência. Uma alteração mal calculada em produção pode transformar "lento" em "fora do ar".
Na Fábrica de Dados, nosso processo de tuning começa exatamente onde este artigo termina: com o diagnóstico feito, montamos o plano de otimização, executamos de forma controlada e validamos com métricas antes/depois. Se a situação é emergencial — banco travado, aplicação parada, operação impactada — nosso S.O.S. DBA atende 24/7 com resposta imediata.
Seu banco Oracle está lento agora?
Solicite um diagnóstico de performance e descubra exatamente onde estão os gargalos — com plano de ação priorizado.