Blz ? Erick, eu não sei como estão hoje, mas um tempo atrás eu tinha visto uns produtos da Quest e achei fracos no quesito de Tuning : em especial, eles só faziam o EXPLAIN PLAN (que dá o Plano de Execução estimado, e Não o real) dos SQLs a analisar, não tinham muitas informações sobre Histogramas, Child Cursors e coisas do tipo, além de só coletarem/exibirem estatísticas muito gerais de performance do banco..... É algo a analisar/avaliar se esses progs vão ser úteis no caso em questão.....
Marcos, primeira coisa : teu ambiente DESENV contém o ** mesmo ** volume de dados que PROD, com o mesmo (ou similar) número de sessões concorrentes, com um hardware e um software o mais semelhantes possíveis em relação à PROD ??? Se não tem, não vejo NADA DE ESTRANHO em observar performance diferente em hardwares diferentes manipulando volumes de dados diferentes com diferente número de sessões no banco, não é ?? Faz sentido ? Eu acho que faz..... Segundo : essa coluna que vc adicionou, qual é o datatype dela, será que não é um datatype complexo/não-escalar como LOB ? Vcs tem CONSTRAINTS nela , em especial FK ? Tem TRIGGERS referenciando ela/usando-a ? Ela é usada nos SQLs da aplicação ? Se é usada sim, será que ela não é usada nos WHEREs - obviamente, se é citada/usada nos WHEREs e não houver estatísticas e histogramas apropriados o CBO pode montar um Plano de Execução impróprio, o que nos leva ao Terceiro ponto .... Terceiro : pra vc SABER o que está sendo diferente em dois databases que pro mesmo SQL apresentam performance largamente diferente, vc TEM que coletar 4 informações cruciais em ambos os bancos - SE vc não é o DBA e portanto não tem acesso à todas elas, Peça Suporte/ajuda pro seu DBA... São elas : a. os indicadores gerais de performance do banco coletados imediatamente antes e imediatamente depois da execução do SQL em questão (derivados principalmente da V$SYSSTAT) : a idéia é fazer uma coleta da V$SYSSTAT imediatamente antes (armazenando numa tabela ou algo assim), executar o SQL e imediatamente depois fazer nova coleta, armazenar E fazer a diferença entre os valores da segunda e da primeira coleta, o resultado é quanto foi 'gasto' .... b. os indicadores de performance/consumo de recursos da sessão (pode ser a V$SESSTAT, pode ser a MYSTATS) : http://betteratoracle.com/posts/12-runstats é um exemplo possível, eu costumo usar uma Variação desse script, que mostra só os indicadores que Foram alterados ou os cuja diferença foi maior que um dado valor c. os Planos de Execução REAIS : quando vc faz um EXPLAIN PLAN (o que como eu disse afaik é o que a maioria das tools faz por vc) vc obtém uma ESTIMATIVA do plano de execução do SQL... Para vc obter o plano que REALMENTE foi criado e usado, inclusive com Detalhes como qtdade de linhas estimadas e reais, tempo gasto, etc) vc pode usar a DBMS_XPLAN, desde que vc TENHA ativado a coleta extendida : https://blogs.oracle.com/optimizer/how-do-i-know-if-the-cardinality-estimates-in-a-plan-are-accurate dá um exemplo... d. os WAIT EVENTs todos que a execução do SQL sofreu : há diversas maneiras de se obter isso mas imho a mais simples é vc fazer um TRACE da sessão executando o SQL : http://psoug.org/reference/dbms_monitor.html, https://community.toadworld.com/platforms/oracle/b/weblog/archive/2014/06/22/tracing-code-with-dbms-monitor e http://programmersnotes.com/2013/12/how-to-enable-tracing-in-oracle-db-how-to-read-trace-files/ tem uns exemplos ===>>> Com essas 4 informações vc ** VAI ** descobrir o que está diferente : PODE ser que o plano tenha mudado em um dos databases, PODE ser que o plano não mudou mas o banco PROD está rodando o mesmo plano que DESENV mas com performance inferior (por causa de waits extras, digamos, ou I/O ineficiente, ou qtdade de blocos muito diferente de DESENV)..... Sem essas infos vc vai estar CHUTANDO, simples assim.... []s Chiappa
