--- Em oracle_br@yahoogrupos.com.br, falmeida <[EMAIL PROTECTED]> escreveu > Olá Marcio, > > Entendi em parte. Imaginei que estava usando 10% por isto, mas fiquei > preocupado se iria prejudicar a análise. Legal! > > É claro que em determinados exemplos o melhor é o particionamento, mas > o que eu estou discutindo é que no exemplo que eu dei, eu teria > 1.000.000 de torcedores divididos por 100 times, da seguinte forma. O > time 50 teria 10 torcedores e os demais com o restante dividido > aproximadamente em partes iguais. Quando você pesquisa uma dada chave > em uma árvore esta pesquisa é extremamente eficiente. Como os dados > estão ordenados nela, quando você chega ao bloco folha onde aparece o > primeiro registro com a chave procurada, basta você ler > sequencialmente a direita os blocos.
Olha até onde eu sei a busca não é assim não. Ela é randômica. >Estou falando em árvore > balanceada, não em árvore binária onde temos que ficar subindo e > descendo. Logo, imagine que teríamos que varrer estes blocos folhas de > índice a direita e para cada entrada fazer um acesso via rowid nos > blocos de dados. Estamos falando em eliminar 90% da tabela e não 25%. Ok, o otimizador trabalha mediante esforço. Se o custo para trazer 10% de registros pelo índice é maior que fts, ele vai por fts. Se estiver errado é porque algo nas estatísticas está errado. Por isso a necessidade de entender bem o que conta no momento da elaboração do custo. Não sei se teve oportunidade de ler o link na asktom, lá inclusive ele faz os cálculos da leitura randômica contra a sequencial massiva. Tem alguns parâmetros que ajudam ao CBO tomar decisão de ir por índice. Por exemplo: optimizer_index_caching, optimizer_index_cost_adj e db_file_multiblock_read_count para começar. > E mais, a partir do momento que o bloco é lido a próxima leitura > provavelmente será feita no buffer e não em disco (claro que isto > dependerá dos parâmetros). Mesmo assim, sou do tempo que a gente media > as coisas. Não falo em termos de olhar o resultado da query em termos > de custo ou outros resultados, pois estes número são dados através de > um modelo matemático, mas falo em criar os dados e medir com o velho e > bom relógio. hhehe - acho que temos a mesma idade ;) > Sem é claro deixar com que a aplicação fique exibindo no > vídeo, pois isto acaba também interferindo no tempo de resposta. Vou > além, se os dados estiverem ordenados nos blocos de dados, ai a coisa > ficaria mais ainda ao meu favor, pois na maioria das vezes, produzimos > relatórios onde lemos uma parte dos dados em sequencia. Relação de > funcionários. Telefones e suas respectivas chamadas etc. Concordo! A sequencia dos dados no storage é fator significativo na tomada de decisão do otimizador e essa informação está disponível na *_indexes: clustering_factor. Quanto mais próximo do número de blocos - blocks (mais ordenado) Quanto mais próximo do número de linhas - num_rows (mais desordenado) Abraços, > > Fico por aqui, > > Abraços, > > Fabão > > Em 25/11/05, Marcio Portes<[EMAIL PROTECTED]> escreveu: > > > > 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 > > > > > > > > > > > > > > > > > > > -- > 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
