← Administração Oracle: recuperação, desempenho e produção
15 / 15 · 70 MIN

Planos executados e evidência de desempenho

Distingue planos estimados de execução observada e interpreta contadores sem perder o contexto do cursor.

Identificar exatamente o que foi executado

Um incidente APS inclui dois anexos: um EXPLAIN PLAN recolhido pelo programador e um tempo elevado observado na aplicação. O primeiro descreve um plano estimado no contexto em que foi produzido; não prova o caminho nem as linhas processadas pela execução lenta. Procura o SQL_ID, child_number, PDB, valores relevantes e intervalo da execução afetada. No laboratório, cada consulta tem um comentário identificador e é procurada pelo texto exato e pelo esquema. A recolha confirma um único child executado antes de chamar DISPLAY_CURSOR. Essa disciplina evita mostrar acidentalmente o plano da própria consulta de diagnóstico. Em produção, a retenção do cursor e os privilégios disponíveis podem limitar o que consegues recuperar.

Recolher contadores com um âmbito explícito

A indicação ALLSTATS LAST pede estatísticas da última execução, mas não cria retrospectivamente contadores que não foram recolhidos. O laboratório executa as consultas com gather_plan_statistics, consome completamente a linha agregada e apresenta o cursor identificado. Os utilizadores sintéticos recebem SELECT nas quatro views fixas necessárias ao diagnóstico; não recebem SYSDBA. O EXPLAIN PLAN separado apresenta Rows estimadas sem A-Rows. Se uma aplicação só consumir parte dos resultados, ou se outra execução substituir a observação relevante, tens de qualificar a evidência. Não preenches valores em falta a partir das estimativas. Regista como a instrumentação foi ativada e avalia o seu custo antes de ampliar a recolha a um serviço real.

Ler a operação, os starts e a janela

Na consulta rara, o acesso à tabela produz 100 linhas num único start. Depois de repetir exatamente o mesmo SQL, a view mostra duas execuções, dois starts acumulados e 200 linhas acumuladas; os campos da última execução continuam a mostrar um start e 100 linhas. Comparar 200 acumuladas com a estimativa de uma execução criaria uma conclusão falsa. Em operações reiniciadas, relaciona A-Rows com Starts antes de avaliar E-Rows; uma média por start pode ajudar, mas também esconder diferenças entre iterações. Não somes indiscriminadamente tempos ou buffers de todas as linhas do plano como se fossem custos independentes. Mantém a árvore e a semântica de cada contador no registo de diagnóstico.

Relacionar predicados e caminhos de acesso

O plano inclui a operação e o predicado que restringe ou filtra as linhas. No exemplo raro com histograma, o índice localiza STATE=REVIEW e a tabela fornece AMOUNT para calcular a soma. O índice existente só contém STATE; observar acesso por ROWID não demonstra falha de utilização do índice. Na consulta frequente, a leitura completa produz 9 900 linhas e o resultado mantém-se correto. Analisa seletividade, projeção e trabalho observado antes de propor um índice adicional ou um hint. Para um índice composto, a ordem das colunas e os predicados disponíveis importam; existem caminhos como skip scan, pelo que regras absolutas sem contexto podem induzir decisões erradas. Este laboratório não executa todos esses caminhos.

Entregar um diagnóstico que suporte uma decisão

Prepara um resumo para APS e desenvolvimento: impacto funcional, cursor identificado, diferença observada, hipótese, alteração limitada e critérios de reversão ou aceitação. Cost é uma estimativa interna do otimizador; não corresponde a milissegundos nem permite comparar diretamente consultas arbitrárias como uma tabela de SLA. As duas execuções do laboratório passaram 36 verificações cada, sem carga concorrente, AWR ou SQL Tuning Advisor. Os logs demonstram a sequência descrita, não capacidade de produção. Para uma release, acrescenta carga representativa, parâmetros reais autorizados, resultados reconciliados e métricas de serviço. Guarda a diferença entre documentação, observação e hipótese. O diagnóstico termina quando existe evidência suficiente para a decisão acordada, não quando o plano parece visualmente mais simples.

-- Execute and fully fetch the target query with statistics collection enabled.
SELECT /*+ gather_plan_statistics */ SUM(amount) FROM payments WHERE state='REVIEW';
-- Obtain the intended SQL_ID and child_number before displaying its evidence.
SELECT plan_table_output FROM TABLE(
 DBMS_XPLAN.DISPLAY_CURSOR('<captured_sql_id>',0,'ALLSTATS LAST +PREDICATE'));
-- Replace both cursor identifiers with the captured values, not another session's defaults.
NA PRÁTICA

Depois de duas execuções: OUTPUT_ROWS=200 e STARTS=2; LAST_OUTPUT_ROWS=100 e LAST_STARTS=1.

Armadilhas comuns

EXPLAIN como execução real; ALLSTATS como recolha retroativa; comparar acumulados com uma execução; Cost como tempo do SLA.

Tópicos relacionados: Estatísticas do otimizador · Diagnóstico de desempenho · Aceitação operacional de alterações

Leva esta ideia contigo

Identifica o cursor, recolhe os contadores adequados e liga cada conclusão ao âmbito que a evidência realmente cobre.

Criar conta

Referência: DBMS_XPLAN · 1Z0-183 public objectives inspected 2026-09-30; revision date not published

Oracle® é uma marca registada da Oracle e/ou das suas afiliadas. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por Oracle. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.