Documentação

Começar

• Visão geral do WaitScopeO que o WaitScope lê, o que o relatório entrega e o que ele não faz: o perfil do tempo de resposta a partir do trace Oracle 10046 e de deadlock.
• Primeira análise com o trace de exemploEnvie o trace sintético pela console, acompanhe o processamento e compare o tempo total, o perfil, o diagnóstico e o plano com o relatório de exemplo.

Gerar o trace

• Ligar o trace com o DBMS_MONITORLigue o trace 10046 com esperas e sem binds por sessão, por client_id ou por serviço, módulo e ação, confira se ficou ligado e desligue no fim.
• Escolher o nível do evento 10046Os níveis do evento 10046, qual deles o WaitScope precisa, como ligar e desligar com ALTER SESSION e os parâmetros que evitam trace sem tempo ou cortado.
• Achar o arquivo de trace no servidorMarque o nome com tracefile_identifier, ache o caminho pelo V$DIAG_INFO ou pelo V$PROCESS e copie o .trc da pasta de trace do ADR para enviar.
• Enviar o trace de um deadlock (ORA-00060)Ache pelo alert log o trace que o Oracle grava sozinho no ORA-00060, envie o arquivo e veja no relatório o grafo de espera, as sessões e o comando.
• O que um trace 10046 contémOs dados que um trace 10046 leva, o que o WaitScope guarda no relatório e apaga depois da análise, e o que conferir no arquivo antes de enviar.

Enviar

• Enviar traces pelo navegadorEnvie traces pela página Análises da console: arquivos ou pasta, envio em pedaços com retomada, a pergunta sobre o processo e a fila de processamento.
• Enviar traces pelo app AndroidInstale o app pela página App Android da console, escolha arquivos ou pastas, receba traces de outros apps e envie em segundo plano, se quiser só no Wi-Fi.
• Enviar traces pela APIEnvie um trace pela API v1 com o token do app: entrar, abrir o envio, mandar os pedaços de até 8 MiB, concluir e acompanhar a análise até o relatório.
• Arquivos compactados e pastasFormatos aceitos no envio, pasta inteira, arquivos .trm, uma análise por arquivo de zip ou tar, compactado dentro de compactado e arquivo que não é trace.
• Analisar vários traces juntosJunte numa análise só os arquivos da mesma operação, como os da troca de tracefile_identifier, e leia no cartão da coleta os arquivos e as sessões.
• Limites e envio repetidoTamanho por envio, limite descompactado, análises na fila e guardadas, prazo do relatório e o que acontece quando o mesmo arquivo é enviado de novo.

Ler o relatório

• Resumo: tempo total, período e ambienteO tempo total, o período, as chamadas, esperas e comandos e o ambiente do trace no alto do relatório, e como baixar o relatório ou excluir a análise.
• Diagnóstico: os achados do relatórioOs achados apontam padrões que costumam explicar o perfil, em ordem de severidade, com a parte do tempo total e a página de cada código.
• Perfil do tempo de respostaA tabela que divide o tempo total em CPU por tipo de chamada, eventos de espera e tempo não contabilizado, e o cartão que explica cada linha.
• Classes de espera e SQL recursivoO perfil agrupado pela classe de espera do Oracle e o tempo do SQL recursivo, que um comando dispara em funções, triggers e no dicionário.
• Comandos por componente e por classePara cada componente do perfil e cada classe de espera, os comandos que mais gastaram tempo nele, pelo perfil exclusivo de cada comando.
• Comandos SQL por contribuiçãoA lista dos comandos do trace pela contribuição ao tempo total, com o tempo inclusivo, a profundidade, as execuções, as linhas e as leituras.
• Detalhe do comandoA página de um comando: o peso no tempo total, o texto com os objetos em destaque, o perfil exclusivo, as chamadas e o SQL recursivo filho.
• Plano de execução e operações em destaqueO plano das linhas STAT, com o tempo e as leituras próprios de cada operação, as operações em destaque e as linhas estimadas contra as reais.
• Tipos de chamadaAs chamadas PARSE, EXEC, FETCH e CLOSE da sessão somadas por tipo, com CPU, duração, leituras, linhas e misses, como no total do tkprof.
• Chamadas de nível 0 mais longasAs chamadas da aplicação que mais demoraram, com a CPU, o instante em que cada uma começou, a linha no trace e o comando de cada uma.
• Distribuição de latênciaA duração de cada evento de espera e de cada tipo de chamada em faixas de potência de 10, para separar muitas ocorrências rápidas de poucas lentas.
• Leituras: faixas de disco e SSD e releituraAs leituras de bloco em faixas pensadas para disco e para SSD, e quantas vezes a sessão leu de novo um bloco que já tinha lido no mesmo trace.
• Objetos com mais espera e página do objetoOs objetos que mais somaram espera no trace e a página de cada um na console, com consultas prontas para rodar no banco do trace.
• Textos compartilháveis: SQL sem bindOs comandos que só diferem nos literais, juntos numa forma com :s e :n no lugar dos valores, com as variantes, os PARSE e o tempo somados.
• Deadlocks: grafo, sessões e diagnósticoComo ler o deadlock gravado no trace: quem esperava por quem, as sessões, a linha disputada, o SQL, a pilha PL/SQL e o diagnóstico pelo lock.
• Erros ORA no traceOs códigos ORA- das linhas ERROR e PARSE ERROR do trace, o que cada um significa, onde apareceu e o link para a documentação da Oracle.
• Coleta: vários arquivos analisados juntosO cartão que descreve a coleta quando vários traces foram analisados juntos: os arquivos, os trechos de cada um e o tempo de cada sessão.

Achar a causa raiz

• O método do perfil do tempo de respostaComo achar a causa raiz de uma lentidão: escolher a operação, medir o tempo de resposta com o trace, atacar o maior componente e medir de novo.
• Sessão esperando a aplicaçãoO achado TEMPO_NA_APLICACAO aparece quando a espera SQL*Net message from client ocupa boa parte do tempo total: o tempo está fora do banco.
• Um componente domina o tempo de respostaO achado COMPONENTE_DOMINANTE aparece quando um só componente do perfil concentra a maior parte do tempo total. Veja por onde seguir em cada caso.
• CPU domina o tempo de respostaO achado CPU_DOMINANTE aparece quando a CPU das chamadas concentra a maior parte do tempo total. Em geral, vem de leitura lógica em excesso ou de parse.
• Tempo não contabilizado dentro das chamadasO achado NAO_CONTABILIZADO_DENTRO aparece quando muito tempo fica nas chamadas sem CPU nem espera: trace sem esperas, fila de CPU ou swap.
• Lacunas de tempo entre chamadasO achado NAO_CONTABILIZADO_ENTRE aparece quando muito tempo cai entre chamadas sem espera registrada. Quase sempre, a falha está na medida.
• CPU medida acima do tempo decorridoO achado CPU_ACIMA_DO_DECORRIDO aparece quando o tempo não contabilizado dentro das chamadas fica negativo. É efeito da medida de CPU, não do banco.
• Leitura de bloco único lentaO achado LEITURA_LENTA aparece quando a leitura de um bloco único demora em média mais do que o armazenamento deveria. Veja se são todas as leituras ou poucas.
• Muitas leituras de bloco únicoO achado MUITAS_LEITURAS aparece quando as leituras de bloco único ocupam boa parte do tempo total. Antes de acelerar o disco, veja se o plano lê blocos demais.
• Muitos hard parsesO achado HARD_PARSE aparece quando boa parte dos PARSE da sessão é hard parse, ou quando o PARSE de SQL com literais pesa no tempo. A causa mais comum é SQL sem bind variables.
• Um PARSE a cada execuçãoO achado PARSE_POR_EXECUCAO aparece quando um comando muito executado faz um PARSE a cada execução. Manter o cursor aberto evita o PARSE repetido.
• SQL com literais em vez de bind variablesO achado LITERAIS_SEM_BIND aponta o mesmo SQL repetido com valores diferentes no texto, em muitas variantes cujo PARSE pesa na sessão. A correção é usar bind variables.
• Muitos FETCH com poucas linhasO achado FETCH_PEQUENO aparece quando a aplicação faz muitos FETCH com poucas linhas cada, em média. Um fetch size maior corta idas e voltas.
• Processamento linha a linha em PL/SQLO achado LINHA_A_LINHA aponta SQL recursivo executado ou lido muitas vezes, uma linha por vez: o laço em PL/SQL que pede processamento em conjunto.
• Espera por bloqueio de outra sessãoO achado BLOQUEIO aparece quando a classe Application pesa no tempo total: como achar a sessão que segura o lock e corrigir a causa.
• Disputa por estruturas internas do bancoO achado CONCORRENCIA aparece quando latches, mutexes e buffer busy pesam no tempo total: como ligar cada evento à causa e corrigir.
• Muito tempo esperando a gravação do redo no commitO achado COMMIT aparece quando o log file sync pesa no tempo total: como separar commits demais de redo lento e o que fazer em cada caso.
• Espera ligada à configuração do bancoO achado CONFIGURACAO aparece quando troca de redo log, buffer, ITL ou sequence pesam no tempo total: o evento diz o limite a ajustar.
• Troca de blocos entre instâncias do RACO achado CLUSTER aparece quando os eventos gc pesam bastante no tempo total: instâncias do RAC disputando os mesmos blocos, e como reduzir as trocas.
• Sessão contida pelo Resource ManagerO achado RESOURCE_MANAGER aparece quando as esperas resmgr pesam no tempo total: como achar o plano, o grupo e a janela que seguraram a sessão.
• Operação do plano que concentra o trabalhoO achado PLANO_PONTO_QUENTE aponta a operação que concentra o tempo ou as leituras do plano de um comando pesado, com a pista do que corrigir.
• Estimativa de linhas errada no planoO achado ESTIMATIVA_ERRADA mostra a operação em que o otimizador errou as linhas por 10 vezes ou mais, e como corrigir estatísticas e bind peeking.
• Chamadas de nível 0 lentasO achado CHAMADAS_LENTAS conta as chamadas da aplicação que levaram 0,1 s ou mais e leva à lista das mais longas, de onde se chega ao comando.
• Erros Oracle no traceO achado ERROS_ORACLE conta os erros ORA- gravados no trace, menos o ORA-01403: como ver onde cada código apareceu e o que corrigir.
• ORA-01403 (fim de dados) no traceO achado FIM_DE_DADOS aparece quando o único erro do trace é o ORA-01403, fim normal de leitura. Veja os casos em que ele merece atenção.
• Rollbacks no traceO achado ROLLBACK conta as transações que terminaram em rollback: como saber, pelo próprio trace, se houve trabalho desfeito ou só rotina do pool.
• Deadlock entre sessões (ORA-00060)O achado DEADLOCK classifica cada ORA-00060 pelo tipo de lock do grafo (TX, TM ou UL) e aponta a causa provável e a correção de cada tipo.
• Trace sem intervalo de tempoO achado TRACE_VAZIO aparece quando o arquivo tem linhas do 10046, mas nenhuma chamada ou espera com tim: não há tempo de resposta a analisar.

Estudos de caso

• Caso 1: tempo entre chamadas e SQL linha a linhaLeitura guiada do relatório de um trace 10046 real: 73,6% do tempo entre chamadas, dois SELECT com literais executados 89.112 vezes e o trace cortado no meio da rotina.
• Caso 2: sessão dominada por espera de I/OLeitura guiada do relatório de um trace 10046 real: 51,4% do tempo em User I/O, uma consulta com 72% do tempo e sem plano no recorte, e um DELETE de quase 3 milhões de linhas.

Limites e privacidade

• O que o WaitScope não fazO 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.
• Retenção, exclusão e privacidade dos dadosQuanto tempo o relatório fica guardado, quando o trace é apagado, como excluir e baixar, quem vê as suas análises e como pedir ajuda sem mandar o trace.
• Literais escondidos no SQLComo a máscara troca por *** o texto entre aspas e os números do SQL que você vê e baixa, o que ela não esconde e como ligar ou desligar cada opção.

Referência

• GlossárioOs termos do relatório e do trace 10046 em ordem alfabética, do tempo de resposta e do componente ao hard parse, às leituras cr e cu e ao sql_id.
• Linhas do trace 10046 que o WaitScope lêCada linha do trace 10046 que o WaitScope lê, com os campos que ele usa, os que ele ignora, a unidade de tempo e onde tudo aparece no relatório.
• Referência da API v1Resumo da API v1 que o app Android usa: endereço, token, idioma, códigos de erro, rotas de sessão, conta, análises, relatório e envio, e os limites.
• Novidades da console e do appO que mudou em cada versão da console e do app Android do WaitScope, da mais nova para a mais antiga, do HTML baixado que abre aos poucos da console 1.7.0 ao aceite dos termos da 1.5.0.