Um analista de infraestrutura é responsável por gerenciar um banco de dados Oracle que armazena informações críticas de processos judiciais. Para garantir o desempenho ideal e a alta disponibilidade, o DBA (Database Administrator) deve realizar o monitoramento e a otimização proativa do ambiente. Recentemente, o analista notou um aumento na latência de consultas e na carga do sistema.
Considerando as ferramentas e as práticas de administração de SGBD Oracle, a abordagem mais adequada e tecnicamente correta para investigar a causa da degradação de desempenho e otimizar o banco de dados é:
AUtilizar as visões dinâmicas de desempenho (V$ views) para coletar estatísticas do sistema em tempo real, como V$SESSION_WAIT e V$SQLAREA, analisar os planos de execução de consultas com o EXPLAIN PLAN ou o AUTOTRACE, e verificar a ocorrência de bloqueios em sessões com o DBA_LOCKS.
BFocar a análise nas tabelas e no espaço em disco livre (tablespaces), pois a degradação de desempenho é causada, na maioria dos casos, pela falta de espaço. A otimização seria feita simplesmente adicionando mais arquivos de dados (datafiles) para garantir que não ocorram erros de out of space.
CConsultar o Oracle Enterprise Manager (OEM) para uma visão genérica do ambiente, identificar o SQL mais lento com base em elapsed time e, em seguida, forçar o otimizador a usar um índice específico, sem necessidade de avaliar a distribuição dos dados ou a validade do plano de execução.
DDesabilitar as estatísticas do otimizador de consultas, pois elas consomem recursos do sistema, e confiar na indexação manual de todas as colunas de todas as tabelas para garantir um acesso mais rápido e eficiente aos dados.
EReiniciar o banco de dados para liberar a memória e resolver a degradação de desempenho, o que é a maneira mais simples e rápida de restaurar a performance do sistema. As ferramentas de monitoramento seriam usadas apenas após a reinicialização para identificar se a performance foi restaurada.
Revelar gabarito e comentário▾
GabaritoA — Utilizar as visões dinâmicas de desempenho (V$ views) para coletar estatísticas do sistema em tempo real, como V$SESSION_WAIT e V$SQLAREA, analisar os planos de execução de consultas com o EXPLAIN PLAN ou o AUTOTRACE, e verificar a ocorrência de bloqueios em sessões com o DBA_LOCKS.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Diagnóstico de desempenho no Oracle: V$ views, planos de execução e bloqueios
Gabarito: letra A. A abordagem tecnicamente correta para investigar degradação de desempenho no Oracle combina a coleta de estatísticas em tempo real por meio das visões dinâmicas de desempenho (V$ views), a análise dos planos de execução das consultas (EXPLAIN PLAN / AUTOTRACE) e a verificação de bloqueios entre sessões (DBA_LOCKS) — um fluxo completo de diagnóstico que parte da observação do sistema e chega à causa raiz do problema.
A degradação de desempenho em um banco de dados Oracle raramente tem uma causa única e óbvia. Pode ser resultado de consultas SQL mal escritas, planos de execução ineficientes, contenção de recursos (como locks e latches), configuração inadequada de memória, problemas de I/O ou até mesmo estatísticas de otimizador desatualizadas. Por isso, a abordagem profissional segue um método: observar → analisar → agir. Primeiro, coletam-se dados objetivos do sistema (quem está esperando por quê, quais SQLs consomem mais recursos); depois, examina-se o plano de execução das consultas suspeitas para entender como o otimizador decidiu acessar os dados; por fim, verifica-se se há bloqueios ou contenção entre sessões que estejam travando a operação.
As V$ views (visões dinâmicas de desempenho) são a fonte primária de diagnóstico em tempo real. A V$SESSION_WAIT mostra os eventos de espera de cada sessão — se uma sessão está esperando por I/O de disco, por um lock, por CPU, etc. A V$SQLAREA agrega estatísticas por SQL executado, permitindo identificar as consultas mais custosas (maior elapsed time, maior número de execuções, maior leitura de blocos). Já o EXPLAIN PLAN e o AUTOTRACE são ferramentas de análise de plano de execução: mostram como o otimizador pretende executar (ou executou) uma consulta — se usa full table scan, se usa índice, a ordem das operações, o custo estimado. E o DBA_LOCKS (ou as visões de bloqueio como V$LOCK e DBA_BLOCKERS) revela sessões que estão segurando locks e impedindo outras de progredir.
O otimizador baseado em custo (CBO) é o coração da execução de SQL no Oracle. Ele decide o caminho de acesso aos dados com base nas estatísticas coletadas sobre as tabelas e índices (número de linhas, distribuição de valores, densidade, etc.). Se essas estatísticas estiverem desatualizadas ou ausentes, o otimizador pode escolher um plano ruim — por exemplo, um full table scan quando um índice seria muito mais eficiente. Por isso, desabilitar as estatísticas (como propõe a alternativa D) é um erro grave: é justamente o contrário do que se deve fazer. A manutenção proativa das estatísticas (com o pacote DBMS_STATS) é parte fundamental da otimização.
A alternativa A é a única que segue o fluxo completo e correto de diagnóstico: coletar dados (V$ views) → analisar o plano (EXPLAIN PLAN/AUTOTRACE) → verificar contenção (DBA_LOCKS). As demais alternativas propõem soluções simplistas, baseadas em suposições infundadas ou em práticas que prejudicam o banco em vez de ajudá-lo. A banca explora exatamente a tentação de resolver o problema com uma "solução mágica" (reiniciar, adicionar disco, forçar índice) em vez de investigar a causa raiz com as ferramentas adequadas.
Guarde o fluxo de diagnóstico profissional: observar o sistema (V$ views) → analisar o SQL (plano de execução) → verificar contenção (locks) → agir com base em evidências. É esse critério que separa a alternativa correta das demais.
1Observar (V$ views)
2Analisar (EXPLAIN PLAN/AUTOTRACE)
3Verificar contenção (DBA_LOCKS)
4Agir com base em evidências
LEVEL · soulevel.com.br
Alternativa A — ✅ Correta ⟵ GABARITO
Esta é a abordagem completa e tecnicamente correta. Ela combina três frentes essenciais do diagnóstico de desempenho no Oracle:
V$ views para estatísticas em tempo real: V$SESSION_WAIT revela os eventos de espera das sessões (o que está travando cada sessão — I/O, lock, CPU), e V$SQLAREA identifica os SQLs mais custosos (maior tempo de execução, maior consumo de recursos).
Análise do plano de execução: EXPLAIN PLAN mostra o plano que o otimizador pretende usar; AUTOTRACE executa a consulta e mostra o plano real com estatísticas de execução. Isso permite identificar full table scans desnecessários, uso incorreto de índices, etc.
Verificação de bloqueios: DBA_LOCKS (e visões relacionadas como V$LOCK) mostra sessões que estão segurando locks e impedindo outras de progredir — uma causa comum de lentidão que não aparece na análise de SQL isolada.
É exatamente o fluxo que um DBA profissional segue: observar → analisar → agir, sempre com base em evidências coletadas do próprio sistema.
Alternativa B — ❌ Incorreta
A alternativa parte de uma premissa falsa: que a degradação de desempenho é causada, na maioria dos casos, por falta de espaço em disco. Isso não é verdade. A falta de espaço pode causar erros de out of space, mas raramente é a causa primária de lentidão em consultas. A lentidão geralmente vem de planos de execução ruins, contenção de recursos, estatísticas desatualizadas ou problemas de I/O — não de tablespaces cheios. Além disso, simplesmente adicionar datafiles trata o sintoma (falta de espaço) sem investigar a causa raiz da degradação. A alternativa ignora completamente as ferramentas de diagnóstico (V$ views, planos de execução, locks) que são essenciais para entender o que está realmente acontecendo.
Alternativa C — ❌ Incorreta
A alternativa contém dois erros graves. Primeiro, sugere "forçar o otimizador a usar um índice específico" sem avaliar a distribuição dos dados ou a validade do plano de execução. Forçar um índice (com hints como /*+ INDEX */) é uma prática de último recurso, que deve ser usada apenas após análise cuidadosa — e nunca sem entender por que o otimizador escolheu outro caminho. Se a distribuição dos dados não favorece o índice (por exemplo, se a coluna tem muitos valores repetidos), forçá-lo pode piorar o desempenho. Segundo, a alternativa subestima a necessidade de análise: identificar o SQL mais lento é apenas o primeiro passo; é preciso entender o plano de execução e as estatísticas para saber por que ele está lento. O Oracle Enterprise Manager (OEM) é uma ferramenta válida de monitoramento, mas a alternativa o usa de forma superficial e com uma ação precipitada (forçar índice) que não é tecnicamente correta.
Alternativa D — ❌ Incorreta
Esta alternativa propõe exatamente o oposto do que a prática recomenda. Desabilitar as estatísticas do otimizador é um erro grave: o otimizador baseado em custo (CBO) depende das estatísticas para escolher o melhor plano de execução. Sem estatísticas, o otimizador trabalha "às cegas" e tende a escolher planos ruins (como full table scans em tabelas grandes). Além disso, a alternativa sugere "indexação manual de todas as colunas de todas as tabelas" — um absurdo técnico. Índices consomem espaço, aumentam o custo de INSERT/UPDATE/DELETE e nem sempre são usados pelo otimizador. A indexação deve ser seletiva, baseada nas consultas reais e na distribuição dos dados — não uma regra genérica de "indexar tudo".
Alternativa E — ❌ Incorreta
Reiniciar o banco de dados é uma medida drástica que deve ser usada apenas em último caso (por exemplo, após uma falha ou para aplicar mudanças de parâmetros). Não é uma solução para degradação de desempenho: reiniciar limpa a memória (SGA/PGA), mas não corrige a causa raiz — o SQL ineficiente, o lock problemático ou a estatística desatualizada continuarão lá após o restart. Além disso, reiniciar um banco de dados crítico (como o de processos judiciais do enunciado) causa indisponibilidade, o que é inaceitável em um ambiente de alta disponibilidade. A alternativa inverte a ordem correta: primeiro se investiga com as ferramentas de monitoramento, e só então se decide se uma ação drástica (como restart) é necessária — e mesmo assim, raramente é a solução para lentidão.
NÃO CAIA NESSA!
A banca explora a tentação de resolver o problema com "soluções mágicas" — reiniciar o banco (E), adicionar disco (B), forçar índice (C) ou desabilitar estatísticas (D). Todas parecem "ações concretas" que um DBA poderia tomar, mas nenhuma investiga a causa raiz com as ferramentas adequadas. A pegadinha está em confundir "agir" com "diagnosticar": o profissional correto primeiro observa (V$ views), analisa (plano de execução) e verifica contenção (locks) — só então age com base em evidências. Na prova, desconfie de alternativas que propõem uma ação imediata sem passar pelo diagnóstico.
PEGA ESSA DICA!
Para questões de desempenho no Oracle, memorize o fluxo de diagnóstico: V$ views (observar) → EXPLAIN PLAN/AUTOTRACE (analisar) → DBA_LOCKS (verificar contenção). Essa tríade é a resposta clássica para "como investigar degradação de desempenho". E lembre-se: estatísticas do otimizador são sempre necessárias — nunca desabilite. Índices são seletivos, nunca "indexar tudo". Reiniciar é último recurso, nunca primeira ação.