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" <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] >
