Irei ver a questão dos parametros OPT o que posso melhorar, já os custos iguais
também e outras coisas mais.
----- Original Message -----
From: jlchiappa
To: oracle_br@yahoogrupos.com.br
Sent: Tuesday, August 18, 2009 6:34 PM
Subject: [oracle_br] Re: Problema Tuning
** Releia ** a resposta, eu disse (entre outras coisas ) :
- PODE SER que o fato dos params optimizer estarem iguais esteja INCORRETO,
um ajuste seja necessário em PROD porque o hardware é diferente, a concorrência
é diferente, o que for
- *** NÂO *** é só "fazer o analyze com 100%", é COLETAR HISTOGRAMAS se há
distribuição irregular de valores
- e as outras coisas TODAS que eu disse como CPU Costing, situação física
diferente, cluster factor.... Isso TUDO tem que ser analisado para vc descobrir
o que está acontecendo, OK ?
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "Willian Fernando Frasson"
<wfras...@...> escreveu
>
> Então Chiappa, o plano de execução está diferente na tabela está fazendo
Full (conforme plano de execução) no Desenv que está ok.
>
> Com relação aos parametros opt*** estão iguais em ambos bancos, ja tentei
tambem fazer um analyze com 100% usando gather_stats das tabelas envolvidas.
>
> ----- Original Message -----
> From: jlchiappa
> To: oracle_br@yahoogrupos.com.br
> Sent: Tuesday, August 18, 2009 1:01 PM
> Subject: [oracle_br] Re: Problema Tuning
>
>
> Vamos por partes aí : PRIMEIRO de tudo, o acesso via índice ao final das
contas É mais rápido do que o full table scan ou não ???? Se for, pelo que vc
diz parece ser muito mais questão de utilização do CBO do que tuning da query
em si, provavelmente vc deve estar caindo num dos casos ** clássicos ** aonde o
CBO pode montar um plano não-ótimo :
>
> a) não basta só ter estatísticas, as estatísticas ** TEM ** que ser de boa
qualidade, com COMPUTE sempre aonde que der, e (IMPORTANTE!!) com Histogramas
em colunas aonde a distribuição de dados seja irregular
>
> b) constraints (de PK, FK, UK) devem estar presentes aonde necessário, elas
não servem apenas para Integridade, mas dão dicas importantes pro CBO
>
> c) configuração do CBO, em especial os parâmetros OPTIMIZER_nnn (como o
optimizer_index_cost_adj, aonde vc influencia o custo do acesso via índice), o
db_file_multiblock_read_count, as áreas de hash e sort, paralelismo.... Muitas
vezes os valores default desses params até atendem, mas em outras para ajustar
ao seu hardware e condições de uso pode ser necessários ajustes neles... O
ponto de "estarem iguais em prod e em dev" me parece levar à copnclusão de que
estão ** ERRADOS **, pois PROD e DEV são ambientes COMPLETAMENTE diferentes
imagino (em número de usuários simultâneos, capacidade de I/O e CPU,
concorrência, RAM disponível, etc), deixar os settings iguais nem sempre é o
melhor , ajustar em PROD para corresponder à realidade de PROD pode ser
recomendável
>
> d) se for banco 10g ou superior, coletar estatísticas de SISTEMA (CPU
costing) via dbms_stats.gather_system_stats , num período ** REPRESENTATIVO **
da sua utilização
>
> e) questões físicas dos índices/tabelas, como cluster factor, extents
anormalmente grandes ou pequenos, linhas migradas/chaining
>
> quando se fala em volumes maiores (não que 2, 3 milhões sejam , longe disso
num hardware de Produção) mas enfim a) é um caso típico por causa dos
histogramas, mas cheque TODAs as possibilidades... Um trace 10053 pode ser
útil, também.... Boas refs pra esse trabalho são :
http://www.centrexcc.com/A%20Look%20under%20the%20Hood%20of%20CBO%20-%20the%2010053%20Event.pdf
, http://www.adp-gmbh.ch/ora/tuning/cbo/logical_physical_io.html ,
http://www.centrexcc.com/Fallacies%20of%20the%20Cost%20Based%20Optimizer.pdf ,
http://www.centrexcc.com/Tuning%20by%20Cardinality%20Feedback.pdf ,
http://www.dbazine.com/oracle/or-articles/hotka2 ,
http://www.dbasupport.com/forums/archive/index.php/t-38893.html ,
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3126073805757
,
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:6601251003901
e
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:67994814192949#1085556500346495558
.
>
> Sucesso,
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "Willian Fernando Frasson" <wfrasson@>
escreveu
> >
> > Pessoal boa tarde,
> >
> > Vamos ver se alguém já teve o problema semelhante:
> >
> > Imaginem uma query com 4/5 tabelas envolvidas no voluma de 2, 3 milhoes
de registros, onde o PLANO DE EXECUCAO mostra um FULL SCAN em todos, bom até ai
tudo bem.
> >
> > A mesma query no desenvolvimento com o mesmo volume de dados faz uso de
índice e não o full scan.
> >
> > Estatisticas da base de desenvolvimento desatualizadas, Estatisticas da
produção (tabelas e indices das tabelas envolvidas atualizadas)
> >
> > Pior de tudo (Retiro o stats dos indices da produção (faz o plano de
execução correto usando os indices)
> >
> > Obs.: Todos parametros opt_* estão iguais na Producao e no Desenv.
> >
> > Utilização de RULE na produção (faz o plan correto tambem)
> >
> > Hits de buffer cache (58% na producao)
> >
> > Hits de buffer cache (95% no desenv)
> >
> > Alguem teria ideia de mais alguma coisa que poderia ser...?
> >
> >
> > Abcs.
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>
>
>
>
>
> ----------------------------------------------------------
>
>
>
> O Banco de Dados de Vírus interno expirou.
> Verificado por AVG - http://www.avgbrasil.com.br
> Versão: 8.0.233 / Banco de dados de vírus: 270.10.16/1926 - Data de
Lançamento: 30/1/2009 17:31
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
------------------------------------------------------------------------------
O Banco de Dados de Vírus interno expirou.
Verificado por AVG - http://www.avgbrasil.com.br
Versão: 8.0.233 / Banco de dados de vírus: 270.10.16/1926 - Data de
Lançamento: 30/1/2009 17:31
[As partes desta mensagem que não continham texto foram removidas]
