Olá Marcio, Farei o seguinte, na minha máquina do trabalho tenho um 9i só para recuperar backup de clientes. Passarei ela para RULE e farei uns testes. Quando encontrar algo estranho reportarei a vocês.
Ou seja, darei uma chance pro CBO. hehehe! Abraços, Fabão. P.S. Num falei que sou o vovô do grupo !!! Mas até hoje gosto e tenho T pelo que faço. E o faço com o maior carinho e dedicação. Sou um cara comprometido com qualidade e continuo empolgadão hoje e sempre! Em 25/11/05, Marcio Portes<[EMAIL PROTECTED]> escreveu: > Acho que dá pra escovar uns bits por ai e te convencer de usar CBO. > Faz o seguinte, na próxima oportunidade que voce tiver que voce > colocou /*+ rulle */ ganhou do cbo manda pra lista. Tem muito cara > bom por aqui e tenho certeza que alguem surge com a resolução ou > mesmo uma explicação. > > Sobre a idade :) > É que eu comecei cedo também, 1989 com COBOL para Xenix. Então a > gente conhece IDENTIFICATION DIVISION, ENVIRONMENT DIVISION, WORKING- > STORAGE SECTION 77 ... e por ai vai ;) > > > > --- Em oracle_br@yahoogrupos.com.br, falmeida <[EMAIL PROTECTED]> escreveu > > Olá Marcio, > > > > Eu ainda não fui no site para ler mas vou ler sim. Acho que com mais > > um ano frequentando os comentário de vocês acabarei entendendo como > o > > CBO "pensa". Na época que eu trabalhava direto com o SQLServer > achava > > que o plano gerado era mais natural > > > > Vejo que vocês utilizam sempre o banco em CHOOSE, eu utilizando em > > RULE estou na contramão? Tenho minhas dúvidas, pois analisando > > diversas queries, vendo o que elas faziam e adequando índices, > rodando > > estatístiscas (não da forma que vocês fazem, eu simplesmente entrava > > no DBA Studio e mandava fazer um ANALISE nos SCHEMAS - tinha um job > > para isto (nossos bancos são pequenos e posso me dar o luxo de fazer > > isto à noite). Muitas das vezes eu tinha que colocar o hint para > usar > > RULE nas queries para melhorá-las, e olha que melhorava um absurdo! > > Muitas das vezes percebia que o banco gerava planos completamente > > diferentes, daí ter mudado para RULE. > > > > Para terminar... este coment é OFF... Pô cara, acabei de fazer 48 > > anos, pelo seu blog você é bem mais novo! Tô nesta práia desde os 16 > > anos quando entrando no 1° ano do segundo grau me apaixonei por um > tal > > de COMPUTADOR que me obedeceu só que não o vía nunca (IBM 360 - > > COBOL). Aquelas coisas de: fluxograma, folha de codificação, > perfurar > > cartão, ler listagem, encontrar erros, etc. Caraca que cheiro de > > naftalina!!! > > > > Abraços, > > > > Fabão. > > > > Em 25/11/05, Marcio Portes<[EMAIL PROTECTED]> escreveu: > > > --- 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > 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
