Não tem que pedir desculpas de nada, a idéia em um forum é o debate e ninguem é dono da verdade. É assim que aprendemos mais a cada nova discussão.
Ele sõ usou na segunda query, porque é mais barato. Ele sabe que através do índice, ele encontrará poucos registros em relação a tabela toda. No exemplo a proporção do índice era de 25% da tabela, portanto um fts é mais barato. hehehe, permita-me discordar. Se eu tenho uma tabela de 100 milhões eu vou considerar o particionamento, daí sim FPS (Full Partition Scan) de 1 milhão de registros. Então, mas quando voce chega no leaf block 1, temos não só um rowid, temos vários. Em uma leitura de 25% do cotingente da tabela, quantas vezes acha que vai ler esse mesmo bloco? Tem um monte de explicação disso na asktom. uma delas é http://asktom.oracle.com/pls/ask/f? p=4950:8:::::F4950_P8_DISPLAYID:4433887271030 Acho que voce muda de idéia com a versão 10gr2. Ela está ótima (quanto a configuração default). Mas em minha opinião é o voce disse, precisa entender o que acontece com o CBO para poder usar corretamente. O novo livro do Jonathan Lewis *dizem* está espetacular, não tem o que ele não explique. --- Em oracle_br@yahoogrupos.com.br, falmeida <[EMAIL PROTECTED]> escreveu > Olá Márcio, > > Antes de mais nada, peço desculpas por te torrar a paciência. > > Realmente me referia ao artigo de ontem - Histograma. E faço alguns > comensários, a seguir. > > Acho isto no Oracle muito "doido". Eu fiquei desconfiado que quando > você executasse já utilizando o histograma os selects: > SQL> select * from t where x_hist = 2; > ou > SQL> select * from t where x_hist = 5; > utilizariam o índice. Só usou na segunda query. . > > Depois, com a criação do bitmap index o resultado foi FTS nas duas daí > quando você força o índice, o custo da que ele fez full e menor da que > ele usou índice. > > Acho isto incongruente, pois imagine se você tivesse não 10 times, mas > sim 100 times, e em cada um tivesse 1.000.000 e em um deles apenas 5 > torcedores. Ora, se eu estivesse acessando um dos times que tem > 1.000.000 de torcedores, mesmo com o custo de ir no indice e depois na > tabela seria melhor do que percorrer os praticamente 100.000.000 > registros da tabela. Se colocassemos um indice do tipo arvore > balanceada sobre o campo em questão, ele deveria encontrar rapidamente > pelo ponteiro vertical onde iniciava o primeiro bloco onde a chave > procurada se encontrava e a partir daí percorreria todos os blocos a > direita desta árvore até não mais encontrar registros para chave > procurada. Para cada registro encontrado nesta pesquisa, ele deveria > acessar via rowid a linha na tabela. Vale lembrar que quando > computamos a estatistica conseguimos ver a profundidade da árvore do > índice. > Em um DISCO IDE com tempo de acesso médio de 8ms, e uma árvore > gigantesca com profundidade de 6 (eu particularmente eu nunca vi > nenhum índice com esta profundidade) observaremos que ele iria > encontrar o primeiro elemento e 7*8 = 56ms (7 por que temos que > acessar um bloco raiz). A partir daí é só percorrer blocos a direita. > Isto é extremamente rápido. Depois para cada registro encontrado ir no > bloco apontado pelo rowid. Lembro também que num bloco de índice cabem > inúmeras entradas (ponteiros) e que num bloco de dados vários > registros. Concluindo, poderiamos aqui fazer uma estimativa de quantas > entradas caberiam nos blocos de índices e depois quantas linhas > caberiam em um bloco de dados, mas acho que o plano de execução é > muito ruim nestes casos. Não consigo entender o que o programador da > Oracle estava pensando quando decidiu fazer o banco trabalhar desta > forma. Critico sim, pois trabalhei a vida toda com um SO/Linguagem > chamado MUMPS (hoje tem seu sucessor Caché - que é um banco da geração > pós-relacional) que era super eficiente em termos de busca em árvore. > Hoje concluo que a opção choose como padrão a pior escolha, pois o > critério que o Oracle escolhe, na minha opinião, é muito > "preconceituoso", duvidoso e não intuitivo. Hoje, eu deixo o banco em > RULE e analiso o tempo de resposta, e não um suposto custo que eu não > compreendo a lógica de sua apuração. > > Cabe um esclarecimento aqui. Minhas palavras não são para agredir, > ofender, nem denegrir, ninguém, nem ao produto com o qual venho > trabalhando e é o meu "ganha pão". Só queria .... entender..... :-p > > Cordialmente e abraços a todos por me aturar e chegar até aqui, > > Fabão. > > Em 24/11/05, Marcio Portes<[EMAIL PROTECTED]> escreveu: > > Fabão, acredito que voce esteja falando sobre o artigo de ontem > > (Histograma - introdução). > > > > 1) A query que tem um monte de registro vai por FTS. Achei que tinha > > ficado claro quando executei a primeira query com x_hist = 5 (sem > > histogramas corretos) que fez full table scan. Mesmo assim aqui > > está o resultado do autotrace traceonly. > > > > SQL> select * from t where x_hist = 2; > > > > > > 1835197 rows selected. > > > > > > Execution Plan > > ---------------------------------------------------------- > > 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2986 Card=1834400 > > Bytes=45860000) > > 1 0 TABLE ACCESS (FULL) OF 'T' (Cost=2986 Card=1834400 > > Bytes=45860000) > > > > > > > > > > Statistics > > ---------------------------------------------------------- > > 0 recursive calls > > 0 db block gets > > 49556 consistent gets > > 31045 physical reads > > 360 redo size > > 54405784 bytes sent via SQL*Net to client > > 202512 bytes received via SQL*Net from client > > 18353 SQL*Net roundtrips to/from client > > 0 sorts (memory) > > 0 sorts (disk) > > 1835197 rows processed > > > > SQL> select * from t where x_hist = 5; > > > > 10 rows selected. > > > > > > Execution Plan > > ---------------------------------------------------------- > > 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1 Bytes=25) > > 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=4 Card=1 > > Bytes=25) > > 2 1 INDEX (RANGE SCAN) OF 'T_IDX' (NON-UNIQUE) (Cost=3 > > Card=1) > > > > > > > > > > Statistics > > ---------------------------------------------------------- > > 0 recursive calls > > 0 db block gets > > 6 consistent gets > > 0 physical reads > > 0 redo size > > 920 bytes sent via SQL*Net to client > > 651 bytes received via SQL*Net from client > > 2 SQL*Net roundtrips to/from client > > 0 sorts (memory) > > 0 sorts (disk) > > 10 rows processed > > > > > > > > 2) Baixa seletividade não é o único argumento para criação de bitmap > > index. Já imaginou se mesmo com baixa seletividade, o sistema > > sofre intensa manutenção? Pra onde vai sua performance? Mas sim, > > seria uma alternativa (desde que bem avaliada em seus efeitos > > colaterais). no artigo de hoje eu ressalto isso: > > > > Pedaço do artigo em > > <http://mportes.blogspot.com/2005/11/histograma-definio-size.html> > > E agora, quando usar histogramas? > > Sempre que NÃO exista uniformidade na distribuição de valores > > sobre o grupo. Voltando ao exemplo dos torcedores, se em nosso > > conjunto não tivéssemos os torcedores do VOCEM, não seria > > interessante usar histogramas, porque não ganharíamos nada, > > haveria necessidade de estudar melhor os dados e talvez usar > > bitmap, cluster, etc. Tudo depende, mas se há distruibuição > > ^^^^^^ ^^^^^^^ ^^^ > > uniforme no grupo ou constante variação de valores distintos, a > > coluna não é candidata ao histograma. Outra ocasião onde > > deveríamos evitar o histograma é quando a coluna é comparada com > > bind variable. De novo o exemplo, se o campo torce_para for > > comparado com bind variable, ele não é candidado a histogramas. O > > otimizador precisa conhecer o valor literal da comparação para > > percorrer os buckets(endpoint_number, endpoint_value). > > > > 3) Só lembrando que o propósito do artigo foi dar uma introdução de > > histograma, onde um colega da lista perguntou qual a vantagem de > > usá-lo. O artigo foi elaborado para demonstrar a aplicabilidade do > > histograma. > > Mas, vamos a criação do índice e teste. > > > > SQL> create bitmap index t_bm on t ( x_hist ) parallel nologging; > > > > Index created. > > > > SQL> exec dbms_stats.gather_index_stats( user, 'T_BM' ) > > > > PL/SQL procedure successfully completed. > > > > SQL> set autotrace traceonly > > SQL> select * from t where x_hist = 2; > > > > 1835197 rows selected. > > > > > > Execution Plan > > ---------------------------------------------------------- > > 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2986 Card=1834400 > > Bytes=45860000) > > 1 0 TABLE ACCESS (FULL) OF 'T' (Cost=2986 Card=1834400 > > Bytes=45860000) > > > > > > > > > > Statistics > > ---------------------------------------------------------- > > 0 recursive calls > > 0 db block gets > > 49551 consistent gets > > 30842 physical reads > > 0 redo size > > 54405784 bytes sent via SQL*Net to client > > 202512 bytes received via SQL*Net from client > > 18353 SQL*Net roundtrips to/from client > > 0 sorts (memory) > > 0 sorts (disk) > > 1835197 rows processed > > > > Deixando o otimizador trabalhar com as estatísticas coletadas ele > > achou melhor fazer FTS. > > Mas vamos forçar o índice. > > > > SQL> select /*+ index(t, t_bm) */ * from t where x_hist = 2; > > > > 1835197 rows selected. > > > > > > Execution Plan > > ---------------------------------------------------------- > > 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=15420 Card=1834400 > > Bytes=45860000) > > 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=15420 > > Card=1834400 Bytes=45860000) > > 2 1 BITMAP CONVERSION (TO ROWIDS) > > 3 2 BITMAP INDEX (SINGLE VALUE) OF 'T_BM' > > > > > > > > > > Statistics > > ---------------------------------------------------------- > > 0 recursive calls > > 0 db block gets > > 49475 consistent gets > > 29340 physical reads > > 72 redo size > > 54405784 bytes sent via SQL*Net to client > > 202512 bytes received via SQL*Net from client > > 18353 SQL*Net roundtrips to/from client > > 0 sorts (memory) > > 0 sorts (disk) > > 1835197 rows processed > > > > Praticamente o mesmo esforço, embora o custo tenha sido maior do > > índice em relação ao FTS - (Cost=15420) contra (Cost=2986) na mesma > > cardinalidade 1834400. Acho que seria necessário um tkprof aqui para > > análise mais a fundo, mas como o propósito não era investigar bitmap > > index, vou deixar o script que eu usei para fazer o teste e voce pode > > realizá-lo e postar aqui mais tarde. > > > > drop table t; > > > > create table t nologging as > > select object_id, object_name, mod(rownum, 4) x_hist > > from all_objects > > / > > insert /*+ append */ into t > > select * from t; > > commit; > > insert /*+ append */ into t > > select * from t; > > commit; > > insert /*+ append */ into t > > select * from t; > > commit; > > insert /*+ append */ into t > > select * from t; > > commit; > > insert /*+ append */ into t > > select * from t; > > commit; > > > > update t set x_hist = 5 where rownum <= 10; > > > > select x_hist, count(*) > > from t > > group by rollup(x_hist) > > / > > > > create index t_idx on t (x_hist) parallel 8 nologging; > > > > begin > > dbms_stats.gather_table_stats( > > user, > > 'T', > > estimate_percent => 10, > > method_opt => 'for columns x_hist size 10', > > cascade => true, > > degree => 8 ); > > end; > > / > > > > --- Em oracle_br@yahoogrupos.com.br, falmeida <[EMAIL PROTECTED]> escreveu > > > Ola Marcio, > > > > > > Também gostei muito, mas tenho as seguintes perguntas, a saber: > > > > > > 1) Você após ter aplicado o 2 metodo de coleta de estatísticas você > > só > > > rodou a query abaixo: > > > > > > select * from t 2 where x_hist = 5 > > > > > > Não seria legal também demonstrar como ficaria com a query que tem > > um > > > monte de registros? > > > > > > select * from t 2 where x_hist = 4 > > > > > > 2) Não seria melhor criar um bitmap index, dado que você tem baixa > > > seletividade nesta coluna? > > > > > > 3) Já que você tem estes dados na tabela t poderia criar um indice > > > bitmap e mostrar o resultado aqui? > > > > > > Desde já agradeço, > > > > > > Fabão. > > > > > > > > > Em 24/11/05, Rosiano Vieira de Sales<[EMAIL PROTECTED]> escreveu: > > > > Marcio... dei uma lida no seu blog a respeito e gostei muito da > > nota que vc publicou ....contudo fiquei com uma dúvida ....qual o > > critério para definir o size do historgrama ??? .... se tiver algo a > > respeito envie para o grupo .. vai ser de muito proveito ..... > > > > > > > > abç. > > > > > > > > Rosiano > > > > > > > > -----Mensagem original----- > > > > De: oracle_br@yahoogrupos.com.br em nome de Marcio Portes > > > > Enviada: qua 23/11/2005 15:06 > > > > Para: oracle_br@yahoogrupos.com.br > > > > Cc: > > > > Assunto: [oracle_br] Re: Histogramas.???? > > > > > > > > > > > > > > > > Welvis, tomei a liberdade de escrever uma pequena > > introdução para sua > > > > dúvida no meu blog. > > > > Se interessar: > > > > http://mportes.blogspot.com/2005/11/histograma- > > introduo.html > > > > > > > > abraços, > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, Welvis Douglas Silva > > Moreto > > > > <[EMAIL PROTECTED]> escreveu > > > > > Quando devo estar utilizando Histogramas.... quais > > > > > beneficios terei utilizando o. > > > > > > > > > > > > > > > att, > > > > > > > > > > Welvis Douglas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________________ > > > > > Yahoo! Acesso Grátis: Internet rápida e grátis. > > > > > Instale o discador agora! > > > > > http://br.acesso.yahoo.com/ > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- ---- > > --------------------------------------------------------------- > > > > Atenção! As mensagens deste grupo são de acesso > > público e de inteira responsabilidade de seus remetentes. > > > > Acesse: http://www.mail- > > archive.com/oracle_br@yahoogrupos.com.br/ > > > > ------------------------------------------------------- ---- > > --------------------------------------------------------------- > > _____________________________________________________________________ > > > > Area de download do grupo - > > http://www.4shared.com/dir/101727/a4dcc423 > > > > Links do Yahoo! Grupos > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > -------------------------------------------------------------- ---- > > -------------------------------------------------------- > > > > Atenção! As mensagens deste grupo são de acesso público e de > > inteira responsabilidade de seus remetentes. > > > > Acesse: http://www.mail- archive.com/oracle_br@yahoogrupos.com.br/ > > > > -------------------------------------------------------------- ---- > > -------------------------------------------------------- > > _____________________________________________________________________ > > > > Area de download do grupo - > > http://www.4shared.com/dir/101727/a4dcc423 > > > > Links do Yahoo! Grupos > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Fábio Martinho de Almeida > > > Niterói-RJ-Brasil > > > > > > Visite o fotolog: http://fotolog.net/canon_a300 > > > > > > > > > > ------------------------------------------------------------------ -------------------------------------------------------- > > Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. > > Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ > > ------------------------------------------------------------------ -------------------------------------------------------- _____________________________________________________________________ > > Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423 > > Links do Yahoo! Grupos > > > > > > > > > > > > > > > > > > > -- > Fábio Martinho de Almeida > Niterói-RJ-Brasil > > Visite o fotolog: http://fotolog.net/canon_a300 -------------------------------------------------------------------------------------------------------------------------- Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ --------------------------------------------------------------------------------------------------------------------------_____________________________________________________________________ Area de download do grupo - http://www.4shared.com/dir/101727/a4dcc423 Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
