Sim, o dynamic sampling faz isso mesmo, se não houver estatísticas ao invés de "chutar" - o que era feito antes - , com o dynamic ativo o banco faz uma coleta rápida e superficial, em tempo de execução, isso mesmo : Lógico, se vc tiver estatísticas decentes, direitas, já coletadas antes da Execução muito melhor, mas o quebra-galho do dynamic sampling às vezes pode ser útil, sim... E sim, a Causa para a independência da ordem de escrita nos JOINs é que no CBO (a otimização por Custo, o modo moderno e Suportado atualmente de otimizar SQLs) ele não dá mais bola pra ordem em que as tabelas são escritas, pra data de criação de índices, nem pra nada mais do tipo, só se baseia nas estatísticas, sejam estatísticas boas e bem coletadas, sejam estats superficiais via sampling... Quanto à fonte, não : esse Autor pra mim não é nada confiável Porque :
a) se vc analisar friamente o texto dele, ele quase NUNCA, nem sequer Uma vezinha só, te dá uma Evidência concreta do que está falando, um caso reproduzível via sqlplus, uma análise evidenciada por um trace+tkprof, nada - ao contrário , tudo é baseado na Opinião dele b) ele MUITO dificilmente questiona as fontes , principalmente Notas metalink , as apresenta como Verdade absoluta e inquestionável c) grande parte do conteúdo é copy/paste das fontes (principalmente notas, cfrme b) - trabalho próprio, pensamento Original é meio raro ali d) dificilmente vc o vê corrigindo uma informação, aceitando um refuse, um argumento técnico que vá ao contrário do que ele prega, muito menos correção de erros : somos todos humanos, falíveis, Autor que não publica correções de erros frequentes, que não mostra quando/onde/porque mudou de opinião (ou que não muda nunca) é imho Suspeito pra dizer o mínimo ==> Aliás, esses MESMOS critérios que eu usei pra julgar o trabalho do Autor citado vc deveria usar pra julgar QUALQUER fonte de informação técnica que te cair nas mãos ... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Milton Bastos Henriquis Junior <milton.bastos@...> escreveu > > Muito obrigado Chiappa! > > Acabei de encontrar este material a respeito: > http://www.dba-oracle.com/t_table_join_order.htm > e > http://www.dba-oracle.com/art_dbazine_oracle10g_dynamic_sampling_hint.htm > > Meu inglês está longe de ser uma maravilha, mas pelo que entendi em uma lida > rápida e superficial é que a partir da versão 9i existe o método âdynamic > samplingâ, o qual confesso que ainda não entendi o conceito e vou ler mais > a respeito. É para coletar estatísticas em tempo de execução? É isso mesmo? > E a partir do 10g, é default=enabled. > > Pelo que entendi também, ele usa essas estatísticas de cardinalidade para > estimar o melhor plano de execução â" independente da ordem em que coloco > minhas tabelas tanto no FROM quanto a ordenação dos JOINs. É isso mesmo ou > entendi errado? > > Esse autor é confiável? Ou esses dois artigos também se encaixam nos âmitos > e folcloresâ? > > -- > Milton Bastos > www.miltonbastos.com > > De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em > nome de José Laurindo > Enviada em: quinta-feira, 14 de julho de 2011 09:48 > Para: oracle_br@yahoogrupos.com.br > Assunto: [oracle_br] Re: Tuning "básico" de SQL > > > > 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<mailto:oracle_br%40yahoogrupos.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] > > > > > > Clique > aqui<https://www.mailcontrol.com/sr/oExbKYuaUgLTndxI!oX7Ui4!6LUEZOJcgE3eT1Ah+ECwYBx!FOn!FD60dYsLMkVkR+FxcQ!5rC5PcbrY0G8NdQ==> > para reportar este e-mail como SPAM. > > > [As partes desta mensagem que não continham texto foram removidas] >
