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
BINDSdo 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 DETECTEDtraz as sessões envolvidas. - O plano de execução vem das linhas
STATdo 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.
| Arquivo | A 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 hanganalyze | o arquivo é um dump de estado do sistema ou de hanganalyze |
| Alert log da instância, em texto ou em XML | o arquivo é um alert log da instância |
| Outro trace do Oracle, sem as linhas do 10046 | o arquivo é um trace Oracle |
| Arquivo que não é trace do Oracle | o 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 linhasSTATnão chegaram a ser gravadas fica sem plano. - Operação em vários arquivos. A aplicação que troca o
tracefile_identifierreparte 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
- Níveis do evento 10046: qual nível grava as esperas que o perfil precisa.
- Linhas do trace 10046 que o WaitScope lê: os campos de cada linha e onde eles aparecem no relatório.
- Retenção, exclusão e privacidade dos dados: o que fica guardado e por quanto tempo.
- Método para achar a causa raiz: como ler o perfil, do maior componente para o menor.