O Diagnóstico junta os padrões que o WaitScope reconhece no trace e que costumam explicar o perfil. Cada achado tem um código e uma página nesta documentação, com a causa, a resolução e como confirmar.
O que a seção mostra
A seção vem logo depois do Resumo e só aparece quando o trace tem pelo menos um achado. O texto do alto resume a regra: Padrões que costumam explicar o que o trace mostra, em ordem de severidade. São pistas para a análise, não conclusões.
Cada achado é um bloco com a severidade, o título, a parte do tempo total quando ela se aplica, um texto com os números do trace e a causa mais comum, e um link para o lugar do relatório que sustenta o achado.
Como ler
| Parte | O que diz |
|---|---|
| Severidade | alta, média, baixa ou informação. Os achados vêm nessa ordem e, dentro da mesma severidade, da maior parte do tempo total para a menor. O mesmo achado pode sair com severidades diferentes conforme o peso do que ele aponta: leitura lenta num evento que quase não pesa no tempo total, por exemplo, sai como baixa. |
| Título | O padrão, com o componente, o comando ou a contagem que o disparou, como Comando #1: a operação 1 do plano concentra 98,0% do tempo. |
| % do tempo total | O peso do que o achado aponta: o componente, a classe de espera, o tempo dos PARSE ou, nos achados de um comando, o tempo inclusivo do comando. Achados de contagem, como erros, rollbacks, chamadas lentas e deadlock, não têm porcentagem. |
| Texto | Os números do trace e o que costuma estar por trás deles. |
| Link | Leva à evidência: Ver no perfil, Ver perfil por classe, Ver distribuição de latência, Ver tipos de chamada, Ver textos compartilháveis, Ver chamadas mais longas, Ver erros, Ver resumo ou Ver deadlock. Nos achados de um comando, leva ao comando, com Ver comando #n, ou à operação do plano, com Ver no plano do comando #n. |
Os achados e a página de cada um
O código não aparece na tela: é o nome da regra, que a API devolve no campo code. No título, o que está em itálico muda conforme o trace.
| Código | Título no relatório | Página |
|---|---|---|
TEMPO_NA_APLICACAO | A sessão passou a maior parte do tempo esperando a aplicação | Sessão esperando a aplicação |
COMPONENTE_DOMINANTE | componente domina o tempo de resposta | Componente dominante |
CPU_DOMINANTE | CPU domina o tempo de resposta | CPU dominante |
NAO_CONTABILIZADO_DENTRO | Muito tempo dentro das chamadas sem CPU nem espera registrada | Tempo não contabilizado dentro das chamadas |
NAO_CONTABILIZADO_ENTRE | Lacunas de tempo entre chamadas | Lacunas entre chamadas |
CPU_ACIMA_DO_DECORRIDO | CPU medida acima do tempo decorrido | CPU acima do tempo decorrido |
LEITURA_LENTA | Leitura de bloco único lenta em evento, ou Leitura de bloco único acima do esperado em evento | Leitura lenta |
MUITAS_LEITURAS | Muitas leituras de bloco único (evento) | Muitas leituras |
HARD_PARSE | Muitos hard parses | Muitos hard parses |
PARSE_POR_EXECUCAO | Comando #n: um PARSE a cada execução (n PARSE, n EXEC) | Um PARSE a cada execução |
LITERAIS_SEM_BIND | Comando #n: n variantes do mesmo SQL, só com literais diferentes, ou, com a contagem estimada, Comando #n: cerca de n variantes do mesmo SQL, só com literais diferentes | Literais em vez de bind |
FETCH_PEQUENO | Muitos FETCH com poucas linhas | Muitos FETCH com poucas linhas |
LINHA_A_LINHA | Comando #n executado n vezes, ou Comando #n lido linha a linha: n FETCH | Linha a linha em PL/SQL |
BLOQUEIO | Espera por bloqueio de outra sessão | Bloqueio por outra sessão |
CONCORRENCIA | Disputa por estruturas internas do banco | Concorrência interna |
COMMIT | Muito tempo esperando a gravação do redo no commit | Espera no commit |
CONFIGURACAO | Espera ligada à configuração do banco | Configuração do banco |
CLUSTER | Troca de blocos entre instâncias do RAC | Troca de blocos no RAC |
RESOURCE_MANAGER | Sessão contida pelo Resource Manager | Resource Manager |
PLANO_PONTO_QUENTE | Comando #n: a operação id do plano concentra x% do tempo, ou x% das leituras lógicas | Operação que concentra o plano |
ESTIMATIVA_ERRADA | Comando #n: estimativa de linhas errada na operação id do plano | Estimativa de linhas errada |
CHAMADAS_LENTAS | n chamadas de nível 0 acima de 0,100 s | Chamadas lentas |
ERROS_ORACLE | n erros Oracle no trace | Erros Oracle |
FIM_DE_DADOS | n ORA-01403 (fim de dados) | Fim de dados (ORA-01403) |
ROLLBACK | n rollbacks | Rollback |
DEADLOCK | tipo do deadlock entre as sessões a e b, como Deadlock de linha (TX em modo X) entre as sessões 12 e 34 | Deadlock |
TRACE_VAZIO | Trace sem intervalo de tempo | Trace vazio |
Quando preocupa
- Comece pelos achados de severidade alta e pelos de maior parte do tempo total: nenhum ajuste economiza mais do que o tempo que o achado aponta.
- Antes de agir, abra o link do achado e confira o número no relatório. O achado é uma pista; o perfil e o comando é que confirmam.
- Achados de informação, como chamadas lentas e fim de dados, registram um fato que costuma ser normal. Leia, mas não comece por eles.
- Diagnóstico vazio não quer dizer trace sem problema: as regras cobrem padrões conhecidos. O perfil continua sendo a base da análise.
Para onde ir depois
- Diagnóstico do relatório de exemplo: dois achados de severidade média, a espera pela aplicação com 71,3% do tempo total e a operação 1 do plano do comando #1, com 24,6%.
- O método, para saber em que ordem atacar os achados.
- Perfil do tempo de resposta, onde a maior parte dos achados se confirma.