Performance Oracle para devs: 5 erros fatais (e como corrgi-los)

Mas calma, não precisa entrar em desespero.

-- Parece inofensivo, mas pode ser um assassino silencioso
SELECT * FROM users WHERE UPPER(email) = 'DIEGO@ROCKETSEAT.TEAM';

Parece familiar? Então bora codar! 🚀

Erro #1 - O massacre das consultas SQL ineficientes

Como identificar (antes que seus usuários reclamem)?

1. EXPLAIN PLAN: essa é sua bola de cristal. O EXPLAIN PLAN mostra exatamente como o Oracle pretende executar sua consulta. Ele revela se o banco vai usar um índice, se vai fazer um full table scan (ler a tabela inteira) e qual o custo estimado da operação.

2. SQL Developer: use o atalho para visualizar o plano de execução diretamente na sua IDE.

3. Sinais de alerta: consultas que demoram mais de 5 segundos em um ambiente OLTP (transacional), picos inexplicáveis de CPU no servidor do banco e, claro, usuários irritados.

A anatomia de uma consulta assassina

-- ANTES: consulta que mata performance
SELECT * FROM products WHERE UPPER(name) LIKE '%SMARTPHONE%';

• SELECT *: você raramente precisa de todas as colunas. Trafegar dados desnecessários sobrecarrega a rede e a memória.

• UPPER(name): aplicar uma função na coluna da cláusula WHERE geralmente impede o Oracle de usar um índice naquela coluna.

• LIKE '%...': o curinga no início da busca força o Oracle a varrer a tabela inteira, pois ele não sabe por onde começar a procurar.

-- DEPOIS: otimizada e feliz
SELECT id, name, price FROM products
WHERE name LIKE 'smartphone%' AND status = 'active';

Soluções que realmente funcionam

• Reescreva suas consultas: Foque em simplicidade. Evite subqueries complexas quando um JOIN resolve.

• Use o EXPLAIN PLAN religiosamente: analise o "custo" (cost) da consulta. Se o custo for alto, investigue as operações que aparecem em vermelho ou que indicam full table scan.

• Crie índices estratégicos: falaremos mais sobre isso no erro #3, mas índices são vitais para evitar a leitura completa das tabelas.

Dica pro: se você encontrar consultas SQL lentas recorrentes, use o SQL Tuning Advisor (disponível em algumas versões do Oracle) para receber recomendações automáticas de otimização.

Erro #2 - configuração de memória que faz Oracle chorar

O resultado? Caos e lentidão.

Os sinais de que sua memória está pedindo socorro

• ORA-04031: "out of memory in shared pool". Significa que a SGA (a cozinha) está lotada ou fragmentada. O Oracle não consegue encontrar espaço contínuo para armazenar novas informações, como planos de execução de SQL.

• ORA-04030: "out of process memory". Significa que a PGA (a estação do garçom) esgotou. Isso geralmente acontece durante operações pesadas de ordenação ou hash joins.

-- Verificar memória livre na SGA
SELECT * FROM v$sgastat WHERE name LIKE '%free memory%';

-- Verificar alocação total de PGA
SELECT * FROM v$pgastat WHERE name = 'total PGA allocated';

Configuração que realmente funciona

-- Configuração para projeto médio (exemplo prático)
ALTER SYSTEM SET SGA_TARGET=4G SCOPE=SPFILE;
ALTER SYSTEM SET PGA_AGGREGATE_TARGET=1G SCOPE=SPFILE;

• SGA_TARGET: o alvo para a memória compartilhada.

• PGA_AGGREGATE_TARGET: o alvo para a memória agregada dos processos.

• SCOPE=SPFILE: significa que a mudança será salva no arquivo de parâmetros do servidor e só terá efeito após a reinicialização da instância.

Erro #3 - A tragédia dos índices mal planejados

Esse é o paradoxo dos índices de performance no Oracle.

Quando menos é mais (e quando mais é demais)

• Poucos índices: Forçam o Oracle a realizar full table scans para encontrar os dados, o que é lento em tabelas grandes.

• Muitos índices: Cada vez que você insere, atualiza ou deleta um registro, o Oracle precisa atualizar todos os índices associados àquela tabela. Isso gera overhead de manutenção e consome espaço em disco.

O segredo está no equilíbrio e na estratégia.

Criando índices inteligentes

1. Chaves primárias e estrangeiras: quase sempre devem ser indexadas (o Oracle faz isso automaticamente para chaves primárias).

2. Cláusulas WHERE: colunas frequentemente usadas para filtrar dados (como email, status, created_at) são ótimas candidatas.

3. Cláusulas JOIN: as colunas que conectam tabelas são cruciais para joins rápidos.

4. Cláusulas ORDER BY: se você frequentemente ordena por uma coluna específica, indexá-la pode evitar operações de ordenação custosas na memória.

-- Índice estratégico para login rápido
CREATE INDEX idx_user_email ON users(email);

-- Índice composto para relatórios de pedidos por usuário e data
CREATE INDEX idx_order_user_date ON orders(user_id, created_at);

O poder dos índices compostos

Dica Pro: a ordem das colunas no índice composto importa! Coloque a coluna com maior seletividade (a que filtra mais registros) primeiro.

Erro #4 - Connection pool que mais atrapalha que ajuda!

Por que sua aplicação trava nos horários de pico

Configuração correta de connection pool

// Configuração otimizada para aplicação web Node.js
const oracledb = require('oracledb');

async function startApp() {
  try {
    await oracledb.createPool({
      user: 'rocketseat_user',
      password: 'senha_segura_do_diego',
      connectionString: 'localhost/xepdb1',
      // Configurações chave para performance:
      poolMin: 20,         // Manter conexões prontas
      poolMax: 25,         // Evitar crescimento explosivo
      poolIncrement: 1     // Crescer lentamente se necessário
    });

    // Iniciar servidor HTTP...
  } catch (err) {
    console.error('Falha ao iniciar connection pool', err);
  }
}

Erro #5 - Parsing que devora CPU

É exatamente isso que acontece quando o Oracle faz hard parsing excessivo.

O vampiro invisível da performance

1. Parse: Oracle verifica a sintaxe, as permissões e decide o melhor plano de execução.

2. Execute: Oracle executa o plano.

3. Fetch: Oracle retorna os dados para a aplicação.

Bind variables: sua arma secreta

-- PROBLEMA: parsing desnecessário
SELECT * FROM users WHERE id = 12345;
SELECT * FROM users WHERE id = 12346;
SELECT * FROM users WHERE id = 12347;

-- SOLUÇÃO: bind variables
SELECT * FROM users WHERE id = :user_id;

Próximos passos na sua evolução

• Você aprendeu a diagnosticar consultas assassinas com EXPLAIN PLAN.

• Você entendeu como configurar a memória (SGA/PGA) sem medo.

• Você dominou a arte de criar índices estratégicos.

• Você viu como configurar um connection pool otimizado em Node.js.

• E descobriu o poder das bind variables para combater o parsing excessivo.