O WaitScope lê o trace que o próprio Oracle grava de uma sessão e mostra para onde foi o tempo dela: quanto foi CPU, quanto foi cada espera e quanto pesou cada comando SQL. Você gera o trace no banco, envia o arquivo pela console ou pelo app, e o relatório sai quando a análise termina.
O que o WaitScope lê
- Trace do evento 10046 com esperas, no nível 8 ou 12, ou ligado pelo
DBMS_MONITORcomwaits => TRUE(ligar o trace com o DBMS_MONITOR, níveis do 10046). - Trace de deadlock, que o Oracle grava sozinho quando uma sessão recebe o ORA-00060, avulso ou dentro de um trace 10046 (trace de deadlock).
- Traces de versões antigas do Oracle, com o tempo em centissegundos. O WaitScope reconhece a unidade sozinho, e o relatório mostra qual foi usada em Unidade de tempo.
O arquivo pode ir avulso, compactado em gz, bz2, zip ou tar, ou numa pasta inteira (compactados e pastas). Os arquivos de uma mesma operação podem virar uma análise só (analisar juntos).
O que o relatório entrega
- Perfil do tempo de resposta. O tempo total da sessão dividido em CPU por tipo de chamada, cada evento de espera e o tempo que o trace não explica. A soma das linhas dá exatamente o tempo total (perfil).
- Classes de espera. Os mesmos componentes agrupados pela classe de espera do Oracle, como User I/O e Commit (classes de espera).
- Comandos SQL. Cada comando pela contribuição para o tempo total, com as chamadas e o perfil do próprio comando. Os comandos que só diferem nos literais aparecem somados numa linha, marcada com o número de variantes, e o detalhe do comando mostra as variantes que mais gastaram (comandos SQL).
- Planos. O plano das linhas STAT, com o tempo e as leituras de cada operação e as estimativas de linhas que erraram por 10 vezes ou mais (plano de execução).
- Diagnóstico. Padrões que costumam explicar o perfil, em ordem de severidade: espera pela aplicação, leitura lenta, hard parse, SQL com literais em vez de bind, laço linha a linha em PL/SQL, commit, bloqueio e outros (Diagnóstico).
- Objetos. As tabelas e os índices com mais espera, com consultas prontas para você rodar no seu banco (objetos).
- Deadlocks. O grafo de espera, as sessões envolvidas, o comando e a pilha PL/SQL da sessão que recebeu o ORA-00060 (Deadlocks).
O relatório traz ainda a distribuição de latência, as leituras de disco, as chamadas mais longas, os erros ORA e os textos de SQL que só diferem nos literais. O relatório de exemplo mostra tudo isso a partir de um trace sintético. O perfil segue o método descrito por Cary Millsap e Jeff Holt (o método).
O que o WaitScope não faz
- Não instala nada no banco. Não há agente, schema nem conexão: o WaitScope só vê o arquivo que você envia.
- Não é monitoramento. Ele analisa o trace de uma operação quando você precisa entender o tempo dela, e não coleta nada continuamente.
- Não lê outros arquivos do Oracle. Trace do otimizador (10053), trace de incidente, dump de estado e alert log são reconhecidos e recusados, com a explicação de como gerar o 10046.
- Não mostra valores de bind. As linhas de bind do trace são ignoradas.
O trace enviado é apagado assim que a análise termina, pronta ou com erro, e fica só o relatório, pelo prazo de retenção (retenção e privacidade). Na configuração padrão da conta, o SQL que você vê traz *** no lugar do texto entre aspas e dos números usados como valor (literais escondidos). A lista completa está em o que o WaitScope não faz.
Por onde seguir
- Para ver o caminho inteiro com um trace pronto: primeira análise com o trace de exemplo.
- Para gerar o trace da sua operação: ligar o trace com o DBMS_MONITOR e achar o arquivo no servidor.
- Para enviar: pelo navegador, pelo app Android ou pela API.
- Para ler o relatório: comece pelo Resumo e pelo perfil.
A console fica em app.waitscope.com. No acesso antecipado, o acesso é pedido por e-mail para contato@waitscope.com.