Quando a aplicação escreve os valores no texto do SQL em vez de usar bind variables, cada valor diferente vira um comando novo para o banco, com PARSE próprio e, em geral, hard parse próprio. Esta seção junta esses comandos pela forma do texto e mostra quanto eles custam somados.
O que a seção mostra
A seção Textos compartilháveis aparece quando o trace tem comandos que só diferem nos literais. O texto do alto resume: Comandos que só diferem em literais. Com bind variables, um único cursor serviria a todos e os PARSE com hard parse cairiam.
A forma é o texto do comando com cada literal trocado por um marcador: :s para texto entre aspas e :n para número. Ficam como estão os nomes entre aspas duplas e os binds, como :1 e :b1; números dentro de comentários e dicas também viram :n. Os comandos com a mesma forma são as variantes dela. Estes dois comandos:
select nome from exemplo where id = 101
select nome from exemplo where id = 102são duas variantes desta forma:
select nome from exemplo where id = :nA seção lista as formas com duas variantes ou mais que mais somaram tempo, da que mais somou para a que menos somou.
Como ler
| Coluna | O que diz |
|---|---|
| Textos | Quantas variantes a forma tem: quantos comandos diferentes o trace tem com essa forma. Quando a contagem é estimada, aparece como cerca de N (trace com muitos comandos). |
| PARSE | A soma das chamadas PARSE das variantes. |
| PARSE (s) | A duração somada desses PARSE. |
| Total (s) | A soma do tempo inclusivo das variantes: a duração de todas as chamadas delas. |
| SQL IDs | Alguns sql_id de variantes, para procurar no banco. Com a Privacidade dos relatórios ligada, a coluna mostra ocultos pela máscara. |
| Exemplo | O texto da forma, com :s e :n no lugar dos literais. Quando a forma está entre os comandos do relatório, o texto vem com o número dela, como #3, e leva ao detalhe, onde ficam as variantes que mais gastaram. Quando duas formas começam igual, cada uma mostra o começo, um … e o trecho em que difere das outras. |
As variantes nas listas de comandos
Nas listas do relatório, cada forma com duas variantes ou mais é uma linha só, com o selo N variantes antes do texto: em Comandos SQL, em Comandos por componente, no SQL recursivo de cada comando, nas Chamadas mais longas e na tabela Onde apareceu dos erros. O texto da linha é a forma, e a contribuição, as chamadas e o tempo são a soma das variantes: o perfil e o tempo total não mudam. A linha da forma não tem SQL ID, porque cada variante tem o seu. Quando a contagem de variantes é estimada, o selo diz cerca de N variantes. O PARSE ERROR, que não tem cursor, continua identificado pelo próprio texto.
No detalhe da forma, a tabela Variantes que mais gastaram mostra as variantes com mais tempo nas próprias chamadas, com o SQL ID, as chamadas, o tempo e os literais de cada uma (variantes que mais gastaram).
Com a Privacidade dos relatórios ligada em Minha conta, os literais das variantes saem com *** conforme as opções marcadas, e os SQL IDs das variantes não aparecem com qualquer uma delas, nem nesta seção nem no detalhe: o sql_id é calculado a partir do texto com os valores e permitiria descobrir o literal escondido (literais escondidos).
Quando preocupa
O Diagnóstico mostra o achado Comando #n: n variantes do mesmo SQL, só com literais diferentes (LITERAIS_SEM_BIND) para as formas com muitas variantes em que o PARSE pesa no tempo da sessão, com o link Ver comando #n. O texto do achado diz quantos PARSE as variantes fizeram, quantos deles foram hard parse, quanto tempo levaram e quanto as variantes somam com todas as chamadas e o SQL recursivo.
A severidade é baixa ou média: sobe quando o PARSE das variantes pesa mais na sessão. Uma forma pode aparecer nesta seção sem achado, por exemplo quando as variantes são poucas ou o PARSE delas quase não custa.
A correção é usar bind variables na aplicação. CURSOR_SHARING=FORCE no banco reduz os hard parses enquanto a aplicação não muda, mas é só paliativo (literais em vez de bind).
Outras seções dão o mesmo sinal: PARSE com Misses perto da Quantidade em Tipos de chamada (muitos hard parses) e, no perfil, a CPU do PARSE e as esperas de Concurrency na shared pool e na library cache, cujos cartões apontam para esta seção.
Para onde ir depois
O trace sintético do exemplo não tem comandos que só diferem nos literais, e o relatório de exemplo não tem esta seção. Os relatórios dos casos reais têm: veja a seção no caso 1 e no caso 2, e o achado de literais no Diagnóstico do caso 1.
- Literais em vez de bind, para a causa e a correção.
- Muitos hard parses, o efeito mais comum no tempo.
- Comandos SQL, onde a forma aparece como uma linha só.