O plano de execução mostra por onde o comando passou para achar as linhas e quanto cada passo custou. O relatório separa o que é de cada operação e destaca as que concentram o trabalho.
O que a seção mostra
No detalhe do comando, cada plano gravado no trace vira um bloco Plano de execução seguido do hash do plano. O plano vem das linhas STAT do trace; sem elas, o bloco não aparece (o que o trace traz). Abaixo do título, Das linhas STAT do trace. ou, quando o mesmo plano foi gravado mais de uma vez, plano gravado N vezes, mostrando o último. Num comando com o selo N variantes, o plano soma as gravações das variantes e mostra as linhas da execução gravada mais demorada entre elas, e a nota diz plano gravado N vezes, mostrando o da gravação mais demorada.
Quando o plano tem mais de uma operação, o bloco Onde o plano gasta lista as operações em destaque, pelo valor próprio de cada operação, sem o das operações abaixo dela: as que concentram o tempo ou as leituras lógicas do plano, da mais pesada para a menos pesada.
Cada item traz o link Id N · operação, a parte do tempo e das leituras lógicas e, quando houver, uma explicação do que costuma estar por trás, como Visita a tabela linha a linha a partir do índice: índice pouco seletivo ou sem as colunas que o filtro usa.
O número de cada operação em destaque aparece também na linha dela no plano e no texto do comando, marcando o objeto que ela lê.
Como ler
O STAT traz o tempo e as leituras de cada operação somados aos das operações abaixo dela, que são as que alimentam a operação com linhas. O relatório mostra esses valores acumulados e também os próprios, que descontam as operações de baixo.
| Coluna | O que diz |
|---|---|
| Id | O id= da operação. É o alvo dos links Ver no plano do comando #n dos achados. |
| Operação | A operação e o objeto, recuados pela profundidade no plano. Clique nela para abrir o cartão (o cartão de cada operação). |
| Exec. | Quantas vezes a operação rodou (str=). Em branco quando o trace não traz esse campo. |
| Linhas | As linhas que a operação devolveu (cnt=), somadas em todas as vezes que ela rodou. |
| Linhas/exec | Linhas dividido por Exec.: o que cada execução devolveu. |
| Estimado | As linhas por execução que o otimizador estimou (card=). |
| Tempo próprio (s) e % tempo | O tempo da operação sem o das operações abaixo, e a parte dele na soma do tempo próprio de todas as operações. |
| LIO próprio e % LIO | As leituras lógicas da operação sem as das operações abaixo, e a parte delas no plano. |
| PR | Blocos lidos do disco (pr=), acumulados como o CR. |
| PW | Blocos gravados (pw=), em geral no TEMP, por ordenação ou hash join que não coube na memória. |
| Tempo (s) | O tempo acumulado (time=), com as operações abaixo. |
| CR | As leituras lógicas acumuladas (cr=), com as operações abaixo. |
| Custo | O custo do otimizador (cost=). |
| obj | O object_id do objeto da operação. Na console, leva à página do objeto; no HTML baixado, ao detalhe do objeto. |
O Oracle mede o tempo por operação por amostragem, então o tempo de uma operação pode não fechar com o das operações de baixo; as leituras lógicas são contadas sempre. Quando a amostra dá um tempo próprio negativo, o relatório mostra zero.
No relatório de exemplo, a operação 1, TABLE ACCESS BY INDEX ROWID T, tem CR 10 e a operação 2, INDEX UNIQUE SCAN T_PK, logo abaixo, tem CR 2. O LIO próprio da operação 1 é 8, ou 80,0% das leituras lógicas do plano, e o tempo próprio dela é 98,0% do tempo.
Linhas estimadas e reais
Linhas/exec e Estimado ficam em vermelho quando o otimizador errou a quantidade de linhas por 10 vezes ou mais, como diz a nota abaixo do plano; erro numa operação de poucas linhas não fica vermelho. Com o ponteiro sobre o número estimado, aparece o erro por extenso, como o otimizador estimou 1 linha por execução e vieram 5.000 (5.000 vezes mais). A comparação precisa do str= no trace.
Com a estimativa errada, o otimizador escolhe mal a ordem e o método de junção. O achado estimativa de linhas errada aponta, nos comandos que pesam no tempo total, a operação em que a estimativa errada começa, num ramo do plano que trabalha de verdade: o erro de baixo se propaga para cima.
O cartão de cada operação
Clique numa operação para abrir o cartão dela. A console tem cartão para mais de 50 operações, como TABLE ACCESS FULL, INDEX RANGE SCAN, NESTED LOOPS, HASH JOIN e SORT ORDER BY; a variante STORAGE do Exadata usa o cartão da operação comum. Operação fora do catálogo aparece sem botão. O cartão traz:
- Boa quando
- Quando a operação é a escolha certa.
- Ruim quando
- O padrão que a torna cara e a causa comum dele.
- No plano, olhe
- Que colunas conferir, como as linhas desta operação comparadas com as do index scan logo abaixo.
Quando preocupa
- Uma operação em destaque com LIO próprio alto e poucas linhas: lê blocos demais para o que devolve. Num acesso por índice, o índice é pouco seletivo ou não tem a coluna do filtro.
- Exec na casa dos milhares no lado interno de um
NESTED LOOPS: a operação roda uma vez por linha do lado externo, e o custo baixo de cada execução vira um custo alto no total. - PW acima de zero numa ordenação ou num hash join: a operação gravou no TEMP porque a memória da sessão não bastou.
- Números em vermelho: a estimativa errada costuma vir de estatísticas desatualizadas, colunas correlacionadas ou bind peeking.
TABLE ACCESS FULLnuma tabela grande para devolver poucas linhas: falta índice para o filtro, ou ele não é usado.
O achado operação que concentra o plano aponta a primeira operação em destaque dos comandos que mais pesam no tempo total, com o link Ver no plano do comando #n.
Para onde ir depois
- Operação 1 do plano do comando #1, no relatório de exemplo: clique em
TABLE ACCESS BY INDEX ROWID Tpara abrir o cartão. - Objetos, para consultar no banco a tabela ou o índice da operação.
- Detalhe do comando, para as chamadas e o SQL recursivo.