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 <*> 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
