Colega, sendo quase brutalmente honesto, seguinte : TODO conselho que vc ver na estilo de :
- ordenar as tabelas no FROM - não usar ORDER BY se vc já tem GROUP BY na query - não usar views, simplesmente (sem especificar nada mais) - qquer full-table-scan que vc vir num Plano necessariamente é mau/ruim, nenhuma Análise cabe mais - tenha um único extent , ou na pior das hipóteses poucas dezenas de extents por segmento - troque o IN por EXISTS nas subqueries, sem pensar em nada - cache-hit / hit-ratio menor que X necessariamente indica problemas e uns outros, são muito Claramente falando, MITOS, FOLCLORE - qquer fonte que te afirmar o contrário vc Imediatamente coloca sob suspeita.... A questão é que, ANTIGAMENTE, muitos desses itens eram válidos, mas os tempos mudam, a tecnologia progride, o que era totalmente verdadeiro antigamente passa a ser FALSO, cfrme vc comprovou : a própria Oracle é em parte culpada pela demora que ela leva pra Atualizar o material didático / referências oficiais dela... Quanto ao "instrutor Oracle", não é pelo fato dele trabalhar na Oracle que isso dá qquer peso adicional pra ele - ao contrário, ele papaguear mitos do tipo, sem a menor comprovação, só demonstra a má qualidade técnica dele : e sim, o que tem pelaí de intrutor abaixo da crítica, até mesmo dentro da Oracle, que só repete o que tá no material didático (que nem sempre tá o mais atual/adequado em relação à tecnologia) não é fácil... http://asktom.oracle.com, http://www.quest.com/whitepapers/MythsandFolkloreAboutOrPerfTun.pdf , www.oaktable.net/category/tags/rac-performance-myths , http://www.oaktable.net/category/tags/rac-performance-myths , http://www.asktheoracle.net/plsql-myths.html , http://www.oracle.com/technetwork/database/features/plsql/plsql-performance-debunking-the-myt-131388.pdf , http://resources.orapub.com/product_p/myths.htm e http://thinkoracle.blogspot.com/2005/05/optimizing-oracle-performance-millsap.html são alguns exemplos de referências confiáveis (ie, Autores conhecidos na comunidade, que DEMONSTRAM o que afirmam) sobre isso... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Milton Bastos Henriquis Junior <milton.bastos@...> escreveu > > Bom dia amigos! > > Gostaria de tirar uma dúvida, e entender o porquê da minha experiência não > ter o resultado esperado. > > Eu estava estudando o básico de Tuning de SQL através deste livro: > http://www.americanas.com.br/produto/6834512/livros/informatica/sistemasoperacionais/livro-oracle-database-11g-sql > > Pois bem... no capítulo âAjuste de SQLâ eu me deparei com o seguinte > texto: > > âVocê deve escolher a ordem de junção em sua consulta de modo a juntar > menos linhas nas tabelas posteriormente. Por exemplo, digamos que você > estivesse juntando três tabelas relacionadas, chamada tab1, tab2 e tab3. > Suponha que tab1 contenha 1.000 linhas; tab2, 100 linhas; e tab3, 10 linhas. > Você deve juntar primeiro tab1 com tab2, seguido de tab2 e tab3.â > > Bom, eu já tinha noção disso há muito tempo atrás (pois um instrutor de > Oracle já havia falado isso), porém eu nunca tinha testado para ver essa > diferença na prática. > Ontem eu resolvi fazer uma simulação, e criei as seguintes tabelas: > > Moto: 7 linhas > Pessoa: 205.000 linhas > Cidade: 1.300.000 linhas > Estado: 27 linhas > > Obviamente eu populei a tabela CIDADE com muitos dados repetidos, pois não > existem tantas cidades assim no Brasil, exatamente com a intenção de ter uma > tabela âgrandeâ suficiente para meu teste. > As tabelas acimas estão ordenadas conforme o relacionamento: a moto pertence > a uma pessoa, que mora em uma cidade, que fica em um estado. > > Executei as duas querys abaixo, que diferem apenas na ordem dos joins: > > SELECT /*+ MONITOR*/ m.moto_nome, p.nome, c.cidade, e.estado > FROM moto m, pessoa p, cidade c, estado e > WHERE p.cidade = c.id > AND m.dono = p.pessoa_id > AND c.estado = e.est_id; > > SELECT /*+ MONITOR*/ m.moto_nome, p.nome, c.cidade, e.estado > FROM moto m, pessoa p, cidade c, estado e > WHERE m.dono = p.pessoa_id > AND p.cidade = c.id > AND c.estado = e.est_id; > > E então executei o SELECT DBMS_SQLTUNE.report_sql_monitor para ver o plano de > execução das duas querys â" no qual eu esperava planos diferentes. > > Pois bem, tive o mesmo resultado: > SQL Plan Monitoring Details (Plan Hash Value=861704268) > > O mesmo Plan Hash para as duas querys. > > Fica minhas pergunta: afinal, faz ou não faz diferença alterar a ordem dos > JOINs dentro da cláusula WHERE? > O Oracle foi inteligente o suficiente para detectar que as duas querys > trariam o mesmo resultado, e por isso reutilizou o plano de execução anterior? > > -- > Milton Bastos > www.miltonbastos.com > > > This message has been scanned for malware by Websense. www.websense.com > > > [As partes desta mensagem que não continham texto foram removidas] >
