30 Dúvidas Reais sobre SQL e Oracle Database (com respostas práticas para DBAs e programadores)
Dúvidas SQL Oracle – A rotina de banco de dados raramente envolve apenas escrever SQL. Ela envolve performance, concorrência, crescimento, backup, arquitetura e comportamento da aplicação.
Abaixo estão 30 dúvidas reais do dia a dia, com explicações diretas e aplicáveis.
PERFORMANCE E SQL
1. Como melhorar a performance de consultas SQL?
Selecione apenas colunas necessárias, revise joins, crie índices coerentes com filtros, atualize estatísticas e valide o plano real executado.
2. Por que minha query ignora o índice?
Pode ser baixa seletividade, função na coluna indexada, estatísticas ruins ou custo estimado menor para full scan.
3. SELECT * realmente prejudica?
Sim. Aumenta leitura de dados, tráfego de rede, uso de memória e pode impedir uso eficiente de índices.
4. Índice demais pode piorar o sistema?
Pode. Cada índice impacta INSERT/UPDATE/DELETE, consome espaço e aumenta custo de manutenção.
5. Como descobrir quais SQL são mais pesados?
Consulte views de performance (ex.: v$sql) e ordene por tempo total ou médio de execução.
PLANOS E ESTATÍSTICAS
6. Estatísticas desatualizadas impactam tanto assim?
Sim. O otimizador depende delas para estimar cardinalidade e escolher o plano correto.
7. Estatísticas automáticas são suficientes?
Nem sempre. Grandes cargas, tabelas críticas ou mudanças bruscas exigem coleta manual.
8. Como ver o plano realmente executado?
Use DBMS_XPLAN.DISPLAY_CURSOR com ALLSTATS LAST para comparar estimado vs real.
9. Plano mudou sozinho — por quê?
Mudança de estatística, volume de dados, bind peeking, atualização de versão ou parâmetros.
10. Histogramas são sempre necessários?
Só quando há distribuição desigual de valores; caso contrário, podem até prejudicar.
BLOQUEIOS E CONCORRÊNCIA
11. Como identificar sessões bloqueadas?
Consulte v$session verificando blocking_session ou analise locks via v$lock.
12. Posso matar sessão bloqueadora?
Sim, mas confirme se não é processo crítico e se não está prestes a finalizar.
13. O que causa bloqueios frequentes?
Transações longas, falta de índice em FK, commits tardios e atualizações em massa.
14. Deadlock é culpa do banco?
Normalmente não. É problema lógico na ordem de acesso a registros pela aplicação.
15. Falta de commit pode travar o sistema?
Sim. Mantém locks ativos e aumenta undo, podendo afetar muitas sessões.
APLICAÇÃO E DESENVOLVIMENTO
16. Por que ficou lento só em produção?
Diferença de volume, plano diferente, estatísticas distintas, hardware ou concorrência.
17. ORM pode gerar SQL ruim?
Frequentemente. Joins excessivos, consultas repetidas e ausência de paginação são comuns.
18. UNION ou UNION ALL?
UNION remove duplicados (mais lento). UNION ALL apenas concatena (mais rápido).
19. EXISTS ou IN: qual usar?
EXISTS costuma performar melhor com subqueries grandes; IN funciona bem para listas pequenas.
20. Muitas consultas pequenas são problema?
Sim. Podem gerar overhead de parsing, rede e CPU maior que uma consulta otimizada.
RECURSOS E INFRAESTRUTURA
21. Como saber se o gargalo é CPU ou I/O?
Analise eventos de espera, uso de CPU, leituras físicas e tempo de resposta do storage.
22. Buffer cache pequeno deixa o banco lento?
Pode aumentar leitura física e tempo de resposta.
23. Storage lento impacta mesmo com SQL bom?
Totalmente. I/O é frequentemente o maior gargalo em bancos grandes.
24. Redo log pequeno é problema?
Sim. Pode causar trocas frequentes e waits adicionais.
25. Tablespace cheio pode parar o sistema?
Sim. Impede gravações e gera erros para a aplicação.
BACKUP E RECUPERAÇÃO
26. Backup garante recuperação?
Só se o restore for testado regularmente.
27. Backup incremental é melhor que full?
O ideal é combinar: full periódico + incremental frequente.
28. Quanto tempo leva para restaurar o banco?
Depende do tamanho, hardware e estratégia. Esse tempo precisa ser conhecido (RTO).
CRESCIMENTO E ARQUITETURA
29. Quando devo particionar tabelas?
Quando são muito grandes, possuem histórico temporal e consultas filtram por período.
30. Preciso mesmo de monitoramento contínuo?
Sim. Sem monitoramento, problemas só aparecem após impacto no usuário. Com observabilidade, é possível prever saturação, detectar SQL degradando e agir antes do incidente.
Veja também:
30 Dicas Essenciais para SQL e Banco de Dados Oracle que Todo Profissional Deve Conhecer
