Willian As diferenças de velocidade são muito grandes? (com índices e sem índices nos 2 ambientes)
[ ] André 2009/8/18 Willian Fernando Frasson <wfras...@yahoo.com.br> > > > 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 <oracle_br%40yahoogrupos.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:6601251003901e > http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:67994814192949#1085556500346495558. > > Sucesso, > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br <oracle_br%40yahoogrupos.com.br>, > "Willian Fernando Frasson" <wfras...@...> 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] > > > [As partes desta mensagem que não continham texto foram removidas]
