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
