Um componente só com a maior parte do tempo é o caso mais simples do método: o ganho possível está quase todo ali. A causa depende de qual componente domina.
Sintomas
No Diagnóstico, aparece o achado componente domina o tempo de resposta (COMPONENTE_DOMINANTE), com o nome do componente no começo, por exemplo db file scattered read domina o tempo de resposta. O texto diz quanto do tempo total vem desse componente, em percentual e em segundos, e termina com Ver no perfil.
O achado aparece quando o primeiro componente do perfil concentra a maior parte do tempo total. A severidade é sempre média. Ele não aparece quando outro achado já trata do mesmo tempo:
SQL*Net message from clienttem o achado da sessão esperando a aplicação;- o tempo não contabilizado dentro das chamadas tem achado próprio;
- a CPU e as classes de espera com achado próprio (Application, Concurrency, Commit, Configuration, Cluster e Scheduler) aparecem com o achado da classe, como CPU dominante ou bloqueio.
Na prática, ele aparece para eventos das classes User I/O, Network, System I/O, Other e Administrative, para esperas Idle que não são SQL*Net message from client, para eventos não classificados e para o tempo não contabilizado entre chamadas.
Causa
Clique no nome do componente no perfil para abrir o cartão com o que ele mede, quando é normal e onde olhar. Os casos mais comuns:
| Componente | O que costuma ser | Por onde seguir |
|---|---|---|
db file sequential read, cell single block physical read | Leitura de um bloco por vez: acesso por índice que lê blocos demais, ou disco lento | Muitas leituras de bloco único e leitura lenta |
db file scattered read, direct path read, cell smart table scan | Leitura completa (full scan) de tabela ou índice grande para devolver poucas linhas | Operações FULL no plano de execução e operação que concentra o plano |
direct path read temp, direct path write temp | Ordenação ou hash join que não coube na memória da sessão (PGA) e foi para o TEMP | Coluna PW no plano de execução |
SQL*Net more data to client, SQL*Net message from dblink | Resposta grande para a aplicação, ou espera pelo banco remoto de um database link | Linhas por FETCH e o comando no banco remoto |
PL/SQL lock timer | Pausa pedida pelo código (DBMS_LOCK.SLEEP ou DBMS_SESSION.SLEEP) | O bloco PL/SQL que faz a pausa, em Comandos por componente |
PX Deq: Execute Reply | A sessão coordena uma consulta paralela e espera os processos de execução paralela | O trabalho está nos traces desses processos |
| tempo não contabilizado entre chamadas | Trace sem esperas, ligado e desligado no meio da operação, ou coleta incompleta | Lacunas de tempo entre chamadas |
Resolução
- Abra Ver no perfil e confira a linha do componente: Ocorrências, Média (s) e Máx (s) dizem se são muitas esperas curtas ou poucas longas.
- Ache o componente na tabela da causa. Se outro achado do Diagnóstico trata do mesmo componente, como leitura lenta ou muitas leituras, comece por ele.
- Em Principais comandos por componente, abra o grupo do componente e ache o comando que mais gastou nele.
- No detalhe do comando, confira o Perfil do comando e o plano: a operação em destaque costuma ser a que gera o componente.
- Se o componente é espera por um recurso (disco, rede, banco remoto), veja também Objetos com mais tempo de espera e a carga desse recurso no mesmo período, fora do relatório.
Como confirmar
Depois da mudança, gere um trace novo da mesma operação e compare: a Duração (s) do componente e o Tempo total devem cair juntos. O achado some quando nenhum componente concentra mais a maior parte do tempo total. Se o tempo total caiu pouco, o tempo foi para outro componente: ataque o novo maior.
No relatório
No relatório de exemplo, o maior componente é SQL*Net message from client, que tem achado próprio, e por isso este achado não aparece. O relatório do caso 1, de um trace real, tem este achado para o tempo não contabilizado entre chamadas (Diagnóstico do caso 1). Os links abaixo abrem as seções do exemplo:
- Diagnóstico: o achado e o link Ver no perfil.
- Perfil do tempo de resposta: o componente é a primeira linha, com o maior % do total.
- Por classe de espera: a classe do componente e os outros componentes dela, em Principais componentes.
- Principais comandos por componente e por classe: os comandos que gastaram o tempo do componente.
- Distribuição de latência: as faixas de duração das esperas de cada evento.
Leia também as páginas do perfil, das classes de espera e dos comandos por componente.