Pular para o conteúdo
WaitScope Entrar Solicitar acesso (por e-mail) Menu

O que o WaitScope não faz

O que fica fora do alcance do WaitScope: conexão com o banco, monitoramento, os arquivos que ele recusa e o que um trace 10046 não consegue mostrar.

Vale para: Traces 10046 e de deadlock

O WaitScope lê o arquivo de trace que você envia e monta o relatório só com o que está nele. Esta página junta o que fica de fora: o que o serviço não faz, os arquivos que ele recusa e o que um trace não consegue mostrar.

O que o WaitScope não faz

  • Não se conecta ao banco. Não há agente, conector, usuário nem schema no seu ambiente. O WaitScope só vê os arquivos que você escolhe enviar.
  • Não monitora. Ele não fica ligado ao banco nem coleta nada de forma contínua: cada análise é o trace de uma operação que você decidiu rastrear. Para acompanhar o banco ao longo do dia, use uma ferramenta de monitoramento.
  • Não muda nada no banco. As consultas prontas da página de objeto e os blocos de estatística só rodam se você os copiar e executar no seu banco.
  • Não lê os valores de bind. O bloco BINDS do trace é ignorado, e o relatório não mostra com que valores o SQL rodou.
  • Não guarda o trace. O arquivo sai do servidor quando a análise termina. Não há download do trace nem reprocessamento: para analisar de novo, envie o arquivo outra vez. Os prazos estão em Retenção, exclusão e privacidade dos dados.
  • Não decide por você. O diagnóstico aponta padrões que costumam explicar o perfil. Como diz o próprio relatório, são pistas para a análise, não conclusões: as decisões sobre o SQL, o banco e a aplicação são suas.

O relatório só vê o que está no trace

O trace 10046 registra a sessão rastreada: as chamadas ao banco, as esperas e, quando o Oracle as grava, as linhas do plano. Tudo o que o relatório mostra sai daí.

  • O que outras sessões faziam no mesmo momento não aparece. Numa espera por bloqueio, o trace mostra quanto a sessão esperou, mas não quem segurava o recurso. A exceção é o deadlock: o bloco DEADLOCK DETECTED traz as sessões envolvidas.
  • O plano de execução vem das linhas STAT do próprio trace. Comando sem essas linhas fica sem plano: o WaitScope não consulta o banco para buscá-lo.
  • O tempo em que a sessão espera a aplicação aparece como a espera SQL*Net message from client, sem o detalhe do que a aplicação fazia nesse intervalo.

Arquivos recusados

O WaitScope analisa traces do evento 10046 e traces de deadlock (ORA-00060). Quando o arquivo não tem nenhuma linha do 10046 nem bloco de deadlock, a análise termina com a situação erro, e a mensagem diz que tipo de arquivo o WaitScope reconheceu.

Arquivos recusados e o começo da mensagem na console
ArquivoA mensagem começa com
Trace do otimizador (evento 10053)o arquivo é um trace do otimizador (evento 10053), que mostra como o plano foi escolhido
Trace de incidente (ORA-00600 ou ORA-07445)o arquivo é um trace de incidente (ORA-00600 ou ORA-07445), feito para o suporte da Oracle
Dump de estado do sistema ou de hanganalyzeo arquivo é um dump de estado do sistema ou de hanganalyze
Alert log da instância, em texto ou em XMLo arquivo é um alert log da instância
Outro trace do Oracle, sem as linhas do 10046o arquivo é um trace Oracle
Arquivo que não é trace do Oracleo arquivo não parece um trace Oracle (evento 10046)

Nos cinco primeiros casos, a mensagem continua assim: “sem as linhas do evento 10046 (PARSE, EXEC, FETCH, WAIT) que o perfil usa. Para analisar uma sessão, gere o trace com DBMS_MONITOR.SESSION_TRACE_ENABLE(waits => TRUE) ou, na própria sessão, ALTER SESSION SET EVENTS '10046 trace name context forever, level 8'”.

A recusa só acontece quando falta o 10046. Um trace 10046 que também traz, por exemplo, um trecho de ORA-00600 é analisado normalmente. O WaitScope lê o trace que o Oracle grava (.trc), não relatórios feitos a partir dele: a saída do TKPROF e os relatórios do AWR também são recusados.

Os arquivos .trm, que o Oracle grava ao lado do .trc, não são trace: a console e o app os deixam fora do envio. Numa coleta, o arquivo que não é trace fica de fora com o aviso “arquivo não parece um trace Oracle e ficou de fora da coleta”; se nenhum for trace, a análise termina com “nenhum arquivo da coleta parece um trace Oracle”.

O arquivo recusado também sai do servidor. Para tentar de novo, gere o trace com as esperas e envie outra vez: veja Ligar o trace com o DBMS_MONITOR.

Limites do que o trace mostra

Trace sem esperas

Nos níveis 1 e 4 do evento 10046, ou com waits => FALSE no DBMS_MONITOR, o Oracle não grava as linhas WAIT. O relatório sai, mas o perfil fica só com CPU e tempo não contabilizado: a leitura de disco dentro das chamadas vira tempo não contabilizado dentro das chamadas, e a espera pela aplicação vira tempo não contabilizado entre chamadas. No Resumo, Esperas igual a 0 mostra esse caso.

Nesse caso, os achados sobre tempo não contabilizado não querem dizer fila de CPU nem lacuna no trace: falta a informação. Gere o trace de novo com as esperas, no nível 8 ou 12 (níveis do evento 10046).

Trace cortado

  • Ligado depois do início da operação. O cursor aberto antes do trace não tem a linha PARSING IN CURSOR, e o detalhe do comando mostra “Texto não disponível: o cursor foi aberto antes do início do trace.” A chamada recursiva cuja chamada de nível 0 começou antes do trace gera o aviso “N chamadas recursivas sem chamada de nível 0 correspondente (trace iniciado ou cortado no meio de uma chamada)”.
  • Desligado antes do fim. O que a sessão fez depois da última linha não entra no tempo total. O mesmo vale para o arquivo que parou no limite de tamanho do trace (parâmetro MAX_DUMP_FILE_SIZE). O comando cujas linhas STAT não chegaram a ser gravadas fica sem plano.
  • Operação em vários arquivos. A aplicação que troca o tracefile_identifier reparte a sessão em vários traces. Analisado sozinho, cada arquivo perde os cursores abertos nos outros: envie todos juntos, como uma coleta (analisar vários traces juntos). O arquivo que faltar aparece como tempo não contabilizado entre chamadas.

Tempo não contabilizado

O perfil sempre soma o tempo total. O que o trace não explica por CPU nem por espera entra em duas linhas: o tempo não contabilizado dentro das chamadas, a parte da duração de cada chamada que não é CPU nem espera registrada, e o tempo não contabilizado entre chamadas, o intervalo entre uma chamada de nível 0 e a próxima sem espera registrada.

O WaitScope mede quanto é, mas o trace não diz o que foi. As causas comuns estão em tempo não contabilizado dentro das chamadas e tempo não contabilizado entre chamadas. O valor negativo dentro das chamadas vem da granularidade da medida de CPU (CPU acima do decorrido).

Avisos no topo do relatório

Quando a leitura encontra algo fora do comum, o relatório mostra avisos em destaque antes do resumo. Os mais comuns:

  • “N esperas sem tim (trace antigo): a separação entre esperas dentro e fora das chamadas usa o nome do evento”.
  • “N linhas longas demais foram cortadas”.
  • Os limites da análise, que só um trace muito grande ou com muitos comandos distintos atinge. O aviso diz qual limite foi atingido e o que ficou somado num grupo ou fora do detalhe. Com os comandos, as contagens estimadas aparecem como cerca de N: veja trace com muitos comandos.

O texto muito longo de um comando aparece cortado, com a nota “Texto cortado: o trace declara N caracteres.”

Para onde ir depois

Atualizado em 29/10/2026. Relatar erro nesta página