O perfil divide o tempo total da sessão em componentes: a CPU de cada tipo de chamada, cada evento de espera e o tempo que o trace não explica. É a seção que diz onde o tempo foi, e é pelo maior componente que a análise começa.
O que a seção mostra
A seção Perfil do tempo de resposta (no índice, Perfil) tem uma linha por componente, da maior duração para a menor, e uma linha Total igual ao Tempo total do Resumo. A soma das linhas é exatamente o tempo total, sem arredondamento: as porcentagens fecham 100%.
| Componente | O que mede |
|---|---|
CPU: FETCH dbcalls e os outros tipos de chamada | A CPU (c=) das chamadas daquele tipo, sem a CPU das chamadas recursivas que elas dispararam, que fica no tipo de chamada delas. |
| Cada evento de espera | A soma do ela= das linhas WAIT do evento, como db file sequential read ou SQL*Net message from client. |
tempo não contabilizado dentro das chamadas | A parte da duração das chamadas (e=) que não é CPU, nem espera registrada dentro delas, nem chamada recursiva. |
tempo não contabilizado entre chamadas | O tempo total menos as chamadas de nível 0 e as esperas entre elas: intervalos em que o trace não registrou nada. |
Ao lado do nome vem o tipo: a classe de espera do Oracle para os eventos (Idle, User I/O, Network e outras), cpu ou não contabilizado. O mesmo perfil agrupado por classe fica logo abaixo (classes de espera e SQL recursivo).
Como ler
| Coluna | O que diz |
|---|---|
| Componente | O nome do componente. Clique nele para abrir o cartão (o cartão de cada linha). |
| Duração (s) | O tempo do componente, em segundos, com seis casas. |
| % do total | A parte do tempo total, com a barra ao lado. |
| Ocorrências | Nas esperas, quantas linhas WAIT do evento. Na CPU e no tempo não contabilizado dentro das chamadas, quantas chamadas. Em branco no tempo entre chamadas. |
| Média (s) | A duração dividida pelas ocorrências. |
| Mín (s) e Máx (s) | A ocorrência mais curta e a mais longa. Em branco no tempo não contabilizado. |
O tempo não contabilizado dentro das chamadas pode sair negativo: a medida de CPU é menos fina que a de tempo, e em chamadas curtas a CPU anotada pode passar da duração. Não indica problema no banco (CPU acima do tempo decorrido).
No relatório de exemplo, SQL*Net message from client soma 0,005000 s numa única espera, 71,3% do total de 0,007010 s. A segunda linha, db file sequential read, tem 2 leituras com média de 0,000650 s.
O cartão de cada linha
Clique no nome de um componente para abrir o cartão dele. O cartão traz o nome em linguagem simples (db file sequential read é Leitura de um bloco), o nome original, o que o componente mede e três partes:
- Normal quando
- O comportamento esperado, com números de referência quando existem. Para
db file sequential read: média de 0,1 a 1 ms em SSD ou flash e de 5 a 10 ms em disco. - Preocupa quando
- O padrão que indica problema e a causa mais comum dele.
- Onde olhar
- O que conferir e em que parte do relatório, com link para a seção ou para a linha exata: a linha do componente no perfil, a tabela dele em Latência, o grupo dele em Comandos por componente, os Objetos. Itens que terminam em no banco ou fora do relatório são conferências que o trace não traz, como
v$session.blocking_session.
A console tem cartão próprio para mais de 50 eventos de espera, para a CPU de cada tipo de chamada e para os dois tempos não contabilizados. Evento fora do catálogo abre o cartão da classe dele; os eventos gc do RAC têm um cartão comum. Quando o lugar indicado não existe no relatório, o cartão aponta para a seção inteira ou mostra o lugar sem link.
Quando preocupa
- Um componente sozinho soma a maior parte do tempo total: é por ele que a análise começa (componente dominante, CPU dominante).
SQL*Net message from clientestá entre as primeiras linhas: o banco esperou a aplicação, e ajuste de SQL não reduz esse tempo (sessão esperando a aplicação).- O tempo não contabilizado dentro das chamadas pesa no total: fila de CPU, paginação ou código sem instrumentação (dentro das chamadas). Negativo, é efeito da medida de CPU.
- O tempo não contabilizado entre chamadas pesa no total: o trace tem lacunas (lacunas entre chamadas).
- Um evento de espera pesa e a Média (s) está acima do que o cartão chama de normal: o recurso está lento. Com média normal e muitas ocorrências, o problema é o volume, e a causa costuma estar no plano.
Para onde ir depois
- Perfil do relatório de exemplo, e a linha de db file sequential read: clique no nome do evento para abrir o cartão.
- Comandos por componente, para ver quais comandos gastaram o tempo do maior componente.
- Distribuição de latência, para separar muitas ocorrências rápidas de poucas lentas.
- O método, para a ordem da análise.