O que um trace 10046 contém

O trace 10046 é um arquivo de texto e traz mais do que tempos: o texto de cada comando SQL com os valores escritos nele, nomes do servidor e da aplicação, caminhos e, se você ligar, os valores de bind. Esta página lista o que vai no arquivo, o que o WaitScope guarda, o que ele apaga e o que conferir antes de enviar.

O que o trace traz

O trace de deadlock traz ainda, de cada sessão envolvida, o usuário do banco, a máquina, o programa, o módulo, a ação, o SQL e a linha esperada, com o rowid, além de um dump do estado do processo. O relatório mostra o que lê dessas partes na seção Deadlocks.

O que o WaitScope guarda

• O resultado da análise: tempos, contagens, o texto de cada comando como está no trace (no comando que soma variantes, o texto com :s e :n e os literais das variantes que mais gastaram), os nomes do cabeçalho, os nomes dos objetos e as partes do deadlock que o relatório mostra.
• O nome do arquivo enviado: ele vira o nome da análise no Histórico e o título do relatório, inclusive no HTML baixado.
• O tamanho e o número de linhas do arquivo.

O resultado fica pelo prazo de retenção, e só a sua conta vê as suas análises: nenhum outro usuário, nem o administrador da console (retenção e privacidade). Os valores de bind não entram no resultado.

O que é apagado

• O trace sai do servidor assim que a análise termina, pronta ou com erro. Não há download do trace nem reprocessamento: para analisar de novo, envie o arquivo outra vez.
• O envio pela metade é apagado quando você cancela, depois de 24 horas sem pedaço novo ou quando termina a sessão que fez o envio, no navegador ou no app.
• A análise é apagada quando vence o prazo de retenção, ou antes, quando você exclui.

O que conferir antes de enviar

1. Gere sem binds. Use o nível 8 do 10046 ou binds => false no DBMS_MONITOR. Se o arquivo já tem blocos BINDS, o WaitScope não os usa, mas eles viajam no arquivo até a análise terminar e o trace ser apagado.
2. Renomeie o arquivo. O nome vira o título do relatório e aparece no Histórico e no aviso do app. Tire dele nomes de cliente, de sistema ou de pessoa: zz-lote-noturno.trc serve.
3. Confira a máscara de literais. Ela vem ligada e fica em Minha conta, no quadro Privacidade dos relatórios; o seu nome no alto da console abre a página.
4. Lembre do cabeçalho. O nome do servidor, a instância, o serviço, o módulo, a ação, o client_id e o caminho do arquivo aparecem no relatório como estão: a máscara vale só para o texto do SQL.

Máscara de literais

A máscara troca por *** o texto entre aspas e todo número usado como valor no SQL, também no GROUP BY, onde o número é um valor e não a posição de uma coluna. Só o número de posição do ORDER BY, como em order by 2, fica como está. Vale para tudo o que você vê: a página, o HTML e o JSON baixados, a API e o app. A análise gravada fica com o texto original, e desmarcar as opções mostra o SQL como veio no trace.

No comando que soma variantes, o texto já aparece com :s e :n no lugar dos literais. A máscara esconde os literais da tabela Variantes que mais gastaram e também o SQL ID de cada variante, que levaria de volta ao texto com os valores.

As dicas /*+ */, os nomes entre aspas duplas e os binds, como :1, ficam como estão. Dentro de um comentário, o texto entre aspas e os números também viram ***. Os detalhes estão em literais escondidos.

Para onde ir depois

• Para gerar o trace sem binds: ligar o trace com o DBMS_MONITOR ou níveis do 10046.
• Para o prazo e o isolamento entre contas: retenção e privacidade.
• Para enviar: enviar pelo navegador.