[oracle_br] Re: Trace 'acelerando' a consulta

[jlchia...@yahoo.com.br [oracle_br]]

Opa, então : não há bizarrice *** NENHUMA *** no cenário que vc descreve se a 
minha análise estiver correta :  vc deve estar caindo no que 
http://www.oracle.com/technetwork/issue-archive/2008/08-jan/o18asktom-090158.html
 descreve bem, e em diversos livros de tuning isso é coberto... 
 A questão é que quando vc ativa o trace vc está criando um ** NOVO ** 
environment (tipo como se vc estivesse alterando com ALTER SESSIONs os settings 
da sessão), então vc acaba fazendo um novo HARD PARSE, completo com 
re-avaliação de BINDINGs e refeitura do Plano de Execução.... 
 Tipicamente vc encontra diferença de performance nesse cenário quando o BIND 
PEEKING está Ativo, vc tem distribuição de valores Altamente irregular (ie, 
para diferentes valores no filtro a Cardinalidade e/ou a Seletividade é 
vastamente diferente) e por azar na execução anterior o valor fornecido no 
BINDING (e que foi usado para o peeking) é um dos irregulares.... Isso é bem 
mais provável de acontecer no 9i ou no 10g (no 11g o mecanismo de BIND PEEKING 
foi bem alterado) ...
  E como vc corrige isso, se for confirmado esse diagnóstico ?  Basicamente vc 
OU desativa o BIND PEEKING , OU coleta HISTOGRAMAS com SIZE maior , OU evita 
alterações de plano de acordo com o valor (via recursos de Plan Stability, tais 
como HINTs , OULINES, SQL Profiles, etc) , OU "força" um HARD PARSE para esse 
SQL, alterando a aplicação de modo que a cada execução algum detalhinho do SQL 
(o texto, talvez, nalgum ponto não-essencial, ou o environment) seja alterado...
   []s
    Chiappa