Envie o trace Oracle. Veja para onde foi cada segundo.
O WaitScope lê traces Oracle do evento 10046 e monta o perfil do tempo de resposta da sessão: CPU, cada espera e cada comando SQL, somando exatamente o tempo total. Sem instalar nada no banco.
O trace é apagado assim que a análise termina. Fica só o relatório.
Trecho do trace (.trc)
FETCH #1:c=200,e=1600,p=1,cr=10,cu=0,mis=0,r=1,dep=0
WAIT #1: nam='db file sequential read' ela= 1000 file#=1 block#=100
WAIT #1: nam='SQL*Net message from client' ela= 5000 driver id=1
STAT #1 id=1 cnt=1 op='TABLE ACCESS BY INDEX ROWID T (cr=10 pr=1 time=1500 us)'
Perfil do tempo de resposta
| Componente | Participação | % do total |
|---|---|---|
| SQL*Net message from client | 71,3% | |
| db file sequential read | 18,5% | |
| tempo não contabilizado entre chamadas | 4,1% | |
| CPU: FETCH dbcalls | 2,8% | |
| outros 5 componentes | 3,3% | |
| Tempo total | 100,0% |
A sessão passou a maior parte do tempo esperando a aplicação Ajuste de SQL não reduz esse tempo: olhe a aplicação, a rede e a quantidade de idas e voltas.
Do trace ao perfil em três passos
Funciona com o trace que o próprio Oracle grava. Não há agente, conector nem acesso ao seu banco.
-
Ligue o trace na sessão lenta
Com o DBMS_MONITOR, com as esperas e sem os valores de bind. O ALTER SESSION com o evento 10046 também serve.
EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE( session_id => 123, serial_num => 4567, waits => TRUE, binds => FALSE); -- rode a operação lenta EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE( session_id => 123, serial_num => 4567); -
Envie o arquivo
Pelo navegador ou pelo app Android: o .trc, compactado em zip, gz, bz2 ou tar, ou a pasta inteira. Os arquivos de uma mesma operação podem virar uma análise só.
-
Leia o perfil
Quando a análise termina, o relatório abre com o tempo total, o perfil por componente e por classe de espera, os comandos SQL com plano e o diagnóstico.
Um relatório que fecha a conta do tempo
Cada linha do perfil é uma parte do tempo total, e a soma dá 100%. A partir dele, o relatório desce para os comandos, os planos e os objetos que pesaram.
Perfil do tempo de resposta
O tempo total dividido em CPU por tipo de chamada, cada evento de espera e o tempo não contabilizado, também agrupado por classe de espera do Oracle.
Comandos SQL e planos
Cada comando pela contribuição para o tempo total, com as chamadas, o plano das linhas STAT e as operações em que o otimizador errou a estimativa de linhas.
Diagnóstico
Padrões que costumam explicar o perfil: espera pela aplicação, leitura lenta, hard parse, laço linha a linha em PL/SQL, commit e bloqueio.
Objetos e PL/SQL
Os objetos com mais espera e consultas prontas para rodar no banco: colunas, índices, estatísticas e o código do PL/SQL.
Deadlocks (ORA-00060)
O grafo de espera, as sessões, o SQL e a pilha PL/SQL de quem recebeu o erro, com o diagnóstico pelo tipo de lock.
Vários traces da mesma operação
Quando a aplicação troca o tracefile_identifier, a operação se espalha por vários arquivos. O WaitScope junta os trechos na ordem do tempo.
O trace não fica no servidor
Trace de produção traz SQL e, às vezes, dado pessoal. O WaitScope guarda só o relatório, e os valores de bind usados nos filtros nem entram nele.
- Apagado depois da análise
- O arquivo enviado sai do servidor assim que a análise termina, pronta ou com erro. Fica só o relatório, pelo prazo de retenção.
- Servidor no Brasil
- A análise roda e o relatório fica guardado em servidor no Brasil.
- Só você vê as suas análises
- Cada conta enxerga apenas o que enviou. Nem o administrador da console vê o conteúdo.
- Literais escondidos
- Texto entre aspas e números com 6 dígitos ou mais saem como *** no SQL que você vê e baixa. Vem ligado e pode ser desligado na conta.
- Verificação em duas etapas
- Toda conta entra com senha e com o código do app autenticador.
- Nada no seu banco
- Sem agente, sem schema e sem conexão com o banco: o WaitScope só vê o arquivo que você escolhe enviar.
Perguntas frequentes
Quais traces o WaitScope lê?
Traces do evento 10046 com esperas (nível 8 ou 12) e traces de deadlock (ORA-00060). Traces antigos, com tempo em centissegundos, também entram. Outros arquivos do Oracle, como o trace 10053 e o alert log, são reconhecidos e recusados com a explicação de como gerar o 10046.
Qual a diferença para o TKPROF?
O TKPROF organiza o trace por comando. O WaitScope começa pelo tempo total da sessão e mostra quanto cada parte pesou, inclusive o tempo fora do banco, como a espera pela aplicação, e o tempo que o trace não explica. Os comandos e os planos vêm depois, na ordem de contribuição.
Trace grande funciona?
Sim. Cada envio vai até 4 GiB, e o arquivo pode ir compactado. A leitura é em fluxo: um trace de 119 MB, com 2,1 milhões de linhas, é lido em cerca de 4 segundos.
É uma ferramenta de monitoramento?
Não. O WaitScope analisa o trace de uma operação quando você precisa entender o tempo dela. Não fica conectado ao banco e não coleta nada continuamente.
Por quanto tempo o relatório fica disponível?
Pelo prazo de retenção, 7 dias no padrão. Dá para baixar o relatório em HTML ou JSON e excluir a análise antes do prazo.
Tem app?
Tem app Android. Ele envia traces grandes em pedaços, retoma o envio se a conexão cair e abre os relatórios. Relatórios e telas em português, inglês e espanhol.
Quanto custa?
Os planos ainda não foram publicados. Durante o acesso antecipado, escreva para contato@waitscope.com e combine o uso.
Analise o próximo trace no WaitScope
Peça acesso e envie o trace da operação lenta. O relatório sai assim que a análise termina.