Raul, Olhando o teu report AWR cheguei nas conclusões abaixo. Peço para os demais experientes olharem também e darem o parecer deles.
O teu problema neste caso é I/O como você mesmo já constatou. No top 5 timed Events o que predomina é: db file sequential read 42.6% User I/O CPU time 30.0% db file scattered read 24.7% User I/O Olhando mais abaixo no Time Model Statistics temos: Statistic Name Time (s) % of DB Time sql execute elapsed time 11,195.99 97.22 DB CPU 3,449.49 29.95 Ou seja, maior parte do tempo gasto é executando mesmo a SQL e não em algum outro wait ou lock. A grande parte dos waits é mesmo full table. Os dois agressores são c42g3k0s8qrzm e cv1ycrvhmdcq3 com alto número de gets. Sendo que o primeiro executou 1651x contra 10x do segundo. Ou seja, o primeiro tá muito pior. Instance Activity Stats: physical read bytes 81,329,389,568 22,579,755.63 3,029,817.44 physical read total IO requests 1,538,638 427.18 57.32 physical read total bytes 82,919,284,224 23,021,163.50 3,089,046.84 Outra coisa tb é o tamanho dos redos. Statistic Total per Hour log switches (derived) 21 20.99 20 switchs por hora é muita coisa. Se bem que não tem um wait expressivo sobre os redos. Considere analisar a quantidade de switchs em outros horários e se for o caso aumente o tamanho dos grupos. Os caminhos dos datafiles parace ser o mesmo tando para dados, indíces. Qual a configuração de discos deste caminho? Qual o filesystem que vc está usando? Já considerou usar o ASM? Faça um teste. Teu buffer cache parece estar legal. PGA tb está legal. Segmentos problemáticos (Logical reads): Owner Tablespace Name Object Name Subobject Name Obj. Type Logical Reads %Total PRODUCAO UNICOO_DADOS TEMP_IMPCTB_LANCTO TABLE 78,874,496 35.45 PRODUCAO UNICOO_DADOS AUTORIZACAO TABLE 57,074,112 25.65 Physical Reads PRODUCAO UNICOO_DADOS AUTORIZACAO TABLE 9,182,316 92.49 Já rodou o segment advisor em cima destes objetos? As estatísticas dos segmentos acima e seus dependentes estão em dia, ou melhor.. de acordo com o especificado pelo fabricante do software em questão? Já rodou o SQL ACCESS ADVISOR em cima destes snapshots? O ACCESS ADVISOR pode ter dar alguma boa recomendação sobre criação de indexes. O teu grande desafio é reduzir a quantidade de leituras em discos. O ideal seria melhorar a query. Oferecer melhores caminhos de acesso (indexes e materialized views) também é uma opção. Teu banco é enterprise? Se não tiver jeito e a tabela for grande mesmo pode pensar em partir para o Partition, que é licensiado a parte. 2011/6/10 raulcsneto <raulcsn...@yahoo.com> > > > Marcio > > Eu compactei o segmento no final de semana passado, mas não adiantou muita > coisa, a tabela é grande mesmo. > > --- Em oracle_br@yahoogrupos.com.br, MARCIO CASTRO <marciomouracastro@...> > escreveu > > > > > Raul: > > > > Se nao tiver como mexer em nada, talvez voce possa tentar uma compactacao > > > nesta tabela. Quando os dados forem lidos para a memoria, irao > compactados > > tambem. > > > > > > Atenciosamente, > > > > > > Márcio de Figueiredo Moura e Castro > > > > > > Oracle 10g DBA OCA > > Oracle PL/SQL Developer OCA > > > > > > > > > > ________________________________ > > De: raulcsneto <raulcsneto@...> > > > Para: oracle_br@yahoogrupos.com.br > > Enviadas: Sexta-feira, 10 de Junho de 2011 11:38:18 > > Assunto: [oracle_br] Re: Problemas com System I/O (Estou Desesperado) > > > > > > Bom dia, > > > > Fiz a alteração da memória, até reduziu o tanho do meu swap, mas não > resolveu. > > > > finalmente consegui fazer o AWR de um periodo critico, segue o link > > http://www.megaupload.com/?d=DYRNKXTH > > > > > > Ja rodei todos os advisors de segmentos e de SQL possiveis, e não obtive > > resultado positivo, investigando, descobri uma bendita de uma query que > faz um > > full table scan em uma tabela de 16gb, acho que ela está causando grande > parte > > da minha dor de cabeça mas como o sistema é de terceiros, não tenho como > mexer > > na instrução, vocês conhecem algo que eu possa fazer para otimizar isso? > > > > Obrigado > > > > --- Em oracle_br@yahoogrupos.com.br, Hevandro Veiga <hevandro83@> > escreveu > > > > > > Então Raul, > > > > > > Rode a query, ela vai te retornar uma contagem agrupado por hash plan. > > > Pega aqueles que tiverem maior contagem. Ex.: 10, 15, 20 é pouco mas > 500, > > > 600, 2000 é para se preocupar. Claro que depende de cada ambiente. > > > > > > Pega os hash plans com as maiores contagens e executa a query abaixo > para > > > descobrir qual SQL está gerando parse excessivo, claro que isso serve > mais > > > se vc tiver como alterar as querys ou pedir alguém p fazer. > > > > > > Então recapitulando: > > > > > > Rode a query: > > > > > > SELECT PLAN_HASH_VALUE,COUNT(*) > > > FROM V$SQL > > > WHERE PARSING_SCHEMA_NAME NOT IN > > > ('SYS','DBSNMP','SYSMAN') > > > GROUP BY PLAN_HASH_VALUE ORDER BY 2; > > > > > > Pega os hash plans com as maiores contagens: > > > > > > SQL> SELECT SQL_TEXT,EXECUTIONS > > > FROM V$SQLAREA > > > WHERE PLAN_HASH_VALUE = &hash_value; > > > > > > Faça uma análise para ver se é falta de variável bind. Se for, manda p/ > > > desenvolvedor ou fornecedor se for o caso. > > > Outra alternativa mais mais radical é setar o parâmetro > > > CURSOR_SHARING=FORCE. Mas NÃO FAÇA EM PRODUÇÃO, TESTE em outro ambiente > para > > > medir o ganho, ou prejuízo. > > > > > > Meu único receio é você diminuir a memória e piorar ainda mais os > parses (se > > > é que é este o seu problema), aí a coisa pode ficar feia na shared > pool. > > > Portanto, faça com cautela. > > > > > > > > > 2011/6/8 raulcsneto <raulcsneto@> > > > > > > > > > > > > > > > Hevandro, estarei diminunido a memoria hoje a noite, conforme os > colegas > > > > orientaram, espero ter boa noticias amanha, o query que voce me > mandou > > > > retornou umas 1000 linhas, em mais da metade delas o count estava > maior que > > > > 1, que medida devo tomar?? quato ao AWR, desculpe-me, achei que fosse > a > > > > mesma coisa que o ADDM, vou rodar o AWR e envio, muito obrigado pelas > dicas > > > > e pela ajuda!!! > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, Hevandro Veiga <hevandro83@> > > > > escreveu > > > > > > > > > > > > > > Raul, > > > > > > > > > > O e-mail anterior saiu cortado. Deu tilt aqui. > > > > > > > > > > FINDING 1: 73% impact (1355 seconds) > > > > > ------------------------------------ > > > > > SQL statements consuming significant database time were found. > > > > > > > > > > Problemas com SQLs, já rodou o SQL tuning advisor em cima dessas > queries > > > > ou > > > > > o SQL Access Advisor no workload? > > > > > > > > > > FINDING 2: 50% impact (934 seconds) > > > > > ----------------------------------- > > > > > The SGA was inadequately sized, causing additional I/O or hard > parses. > > > > > > > > > > RECOMMENDATION 1: DB Configuration, 47% benefit (881 seconds) > > > > > ACTION: Increase the size of the SGA by setting the parameter > > > > > "sga_target" to 27648 M. > > > > > > > > > > O Oracle tá te pedindo para aumentar a memória da SGA. Concordo com > os > > > > > demais colegas com relação ao SWAP, você deveria reduzir e não > aumentar > > > > como > > > > > o Oracle tá pedindo. No entanto existe um problema aqui. O > optimizer > > > > parece > > > > > não conseguir compartilhar os cursores, pode ser falta de variáveis > bind, > > > > > excesso de ddl... > > > > > > > > > > A query abaixo te dá um contagem de querys com o mesmo hash. Querys > com o > > > > > mesmo hash plan tem grandes chances de serem similares, e podem ser > > > > > comparilhadas. > > > > > > > > > > SELECT PLAN_HASH_VALUE,COUNT(*) > > > > > FROM V$SQL > > > > > WHERE PARSING_SCHEMA_NAME NOT IN > > > > > ('SYS','DBSNMP','SYSMAN') > > > > > GROUP BY PLAN_HASH_VALUE ORDER BY 2; > > > > > > > > > > FINDING 3: 48% impact (896 seconds) > > > > > ----------------------------------- > > > > > Individual database segments responsible for significant user I/O > wait > > > > were > > > > > found. > > > > > > > > > > Você disse que já fez um reorg. > > > > > > > > > > > > > > > Pelo ADDM já é um bom começo. > > > > > Como eu havia te pedido antes, roda um report do AWR no período em > que > > > > você > > > > > sabe que teve o problema e envia em anexo. > > > > > Olhar o report do AWR pode indicar um caminho mais preciso a > seguir. > > > > > > > > > > Usa o $ORACLE_HOME/rdbms/admin/awrrpt.sql ou faz pelo enterprise > manager: > > > > > > > > > > > > > > > 2011/6/8 JLSilva <jljlsilva@> > > > > > > > > > > > > > > > > > > > > > > > > > > > raul, sim, pode editar os valores manualmente (aqueles > individuais). > > > > > > a lógica é a seguinte: quando vc configura valores individuais > para os > > > > > > parâmetros da sga e também configura um valor para o sga_target, > os > > > > valores > > > > > > individuais passam a ser considerados como valor mínimo para as > áreas > > > > > > individuais. > > > > > > ou seja, seguido minha sugestão, o cache de dados nunca será > menor do > > > > que > > > > > > 6gb. > > > > > > > > > > > > essas dicas eu coloquei considerando que os parâmetros de linux > já > > > > estejam > > > > > > configurados conforme as recomendações da Oracle, ou seja, os > > > > parâmetros > > > > > > como: > > > > > > /etc/sysctl.conf: > > > > > > fs.file-max = 6815744 > > > > > > fs.aio-max-nr = 1048576 > > > > > > kernel.shmmax = 8589934590 > > > > > > kernel.shmall = 8388608 > > > > > > kernel.shmmni = 4096 > > > > > > kernel.msgmni = 1024 > > > > > > kernel.msgmax = 65536 > > > > > > kernel.msgmnb = 65536 > > > > > > kernel.threads-max = 131072 > > > > > > kernel.sem = 250 32000 100 128 > > > > > > net.ipv4.ip_local_port_range = 9000 65500 > > > > > > net.core.rmem_default = 1048576 > > > > > > net.core.rmem_max = 16777216 > > > > > > net.core.wmem_default = 262144 > > > > > > net.core.wmem_max = 16777216 > > > > > > net.ipv4.tcp_rmem = 4096 87380 16777216 > > > > > > net.ipv4.tcp_wmem = 4096 65536 16777216 > > > > > > vm.swappiness = 10 > > > > > > vm.nr_hugepages = 7682 > > > > > > > > > > > > no caso do hugepages, o valor 7682 deverá suportar sua sga de > 12gb mais > > > > sua > > > > > > pga. > > > > > > > > > > > > /etc/pam.d/login > > > > > > session required pam_limits.so > > > > > > > > > > > > /etc/security/limits.conf > > > > > > oracle soft nproc 2047 > > > > > > oracle hard nproc 16384 > > > > > > oracle soft nofile 1024 > > > > > > oracle hard nofile 65536 > > > > > > > > > > > > > > > > > > On Jun 08, 2011, at 10:51 , raulcsneto wrote: > > > > > > > > > > > > > Bom dia JL, > > > > > > > Vou investigar a questão do SWAP, não havia pensado nisso. > Perdoe-me > > > > se > > > > > > eu estiver falando uma grande besteira, mas eu realmente tenho > pouca > > > > > > experiência, mas caso meu servidor esteja usando muito SWAP, isso > > > > poderia > > > > > > causar um problema de I/O no banco? Tendo em vista que o sistema > > > > operacional > > > > > > e o SWAP estão em um volume separado dos discos do banco, até a > > > > controladora > > > > > > é separada. Só mais uma dúvida, quanto a indicar valores > individuais, > > > > mesmo > > > > > > a Oracle recomendando a utilização do gerenciamento automático da > > > > memória, > > > > > > você considera viável editar os valores manualmente? > > > > > > > > > > > > > > > > > > > > > --- Em oracle_br@yahoogrupos.com.br, JLSilva <jljlsilva@> > escreveu > > > > > > >> > > > > > > >> raul, > > > > > > >> pelo que entendi, vc tem 20GB de memória física e está usando > 18GB > > > > para > > > > > > o Oracle. > > > > > > >> imagino que seu servidor deve estar usando bastante swap, e o > load > > > > > > average acaba subindo bastante. > > > > > > >> minha análise é bastante superficial, mas recomendo vc reduzir > a > > > > > > quantidade de memória alocada para o banco. > > > > > > >> se vc estiver usando "automatic memory management" > (sga_target), > > > > procure > > > > > > reduzir o valor desse parâmetro e indicar valores para os > parâmetros > > > > > > individuais. > > > > > > >> exemplo: > > > > > > >> sga_target=12GB > > > > > > >> db_cache_size=6GB > > > > > > >> shared_pool_size=4GB > > > > > > >> (folga=2GB para o AMM realocar conforme necessário, além das > outras > > > > > > áreas de memória menores, como shared_pool_reserved_size, > > > > stream_pool_size > > > > > > etc.). > > > > > > >> pga_aggregate_target=3GB (esta memória não é considerada no > > > > sga_target) > > > > > > >> > > > > > > >> faça os ajustes e nos avise do resultado, para sabermos se a > > > > sugestão > > > > > > foi boa. > > > > > > >> boa sorte. > > > > > > >> > > > > > > >> > > > > > > >> On Jun 08, 2011, at 9:06 , raulcsneto wrote: > > > > > > >> > > > > > > >>> Bom dia > > > > > > >>> > > > > > > >>> Tenho um banco de 230Gb rodando no 10G estou tendo muitos > problemas > > > > de > > > > > > System I/O, será que alguem poderia me ajudar a verificar a causa > deste > > > > > > problema, segue abaixo um resumo do meu cenário e das ações que > já > > > > tomei: > > > > > > >>> > > > > > > >>> O Oracle 10G roda em um servidor Redhat 5 com dois > processadores > > > > > > Quad-core Xeon 2.66Ghz, 20Gb de memória, dos quais 18Gb estão > alocadas > > > > para > > > > > > o oracle. > > > > > > >>> > > > > > > >>> Possuo um Disco Virtual com 8 discos SAS de 15.000Rpm e 143Gb > em > > > > RAID > > > > > > 10, totalizando 544Gb para Dados e Indices; > > > > > > >>> > > > > > > >>> Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb > em > > > > RAID > > > > > > 0, totalizando 272Gb para Redo; > > > > > > >>> > > > > > > >>> Possuo um Disco Virtual com 2 discos SAS de 15.000Rpm e 143Gb > em > > > > RAID > > > > > > 0, totalizando 272Gb para Archives; > > > > > > >>> > > > > > > >>> Estes tres volumes estão em uma controladora PERC6/E todos > > > > segmentados > > > > > > em Stripes de 512k; > > > > > > >>> > > > > > > >>> Possuo Tablespaces separadas para Dados e Indices criadas com > > > > alocação > > > > > > uniforme de 512k com datafiles de 2Gb; > > > > > > >>> > > > > > > >>> Recentemente movi todas as tabelas e indices para tablespaces > novas > > > > > > para eliminar a fragmentação; > > > > > > >>> > > > > > > >>> Caso alguem conheça algo que eu possa fazer para tentar > descobrir > > > > onde > > > > > > está o problema, seria de grande valor par mim, pois já esgotei > todas > > > > as > > > > > > minhas possibilidades, e a várias noites já não sei o que é > dormir > > > > direito. > > > > > > >>> > > > > > > >>> Seguem abaixo algumas querys que fiz, meus resultados estão > de > > > > acordo > > > > > > em todas elas: > > > > > > >>> > > > > > > >>> ÍNDICE DE ACERTOS NO CACHE > > > > > > >>> ========================== > > > > > > >>> (quanto mais BHR próximo a 1, melhor) > > > > > > >>> > > > > > > >>> column bhr format 9.99 > > > > > > >>> column mydate heading 'Ano Me Di Hora' > > > > > > >>> select to_char(end_interval_time,'yyyy-mm-dd HH24') mydate, > > > > > > >>> new.name "Buffer Pool", > > > > > > >>> (((new.consistent_gets-old.consistent_gets)+ > > > > > > >>> (new.db_block_gets-old.db_block_gets))- > > > > > > >>> (new.physical_reads-old.physical_reads)) / > > > > > > >>> ((new.consistent_gets-old.consistent_gets)+ > > > > > > >>> (new.db_block_gets-old.db_block_gets)) bhr > > > > > > >>> from > > > > > > >>> dba_hist_buffer_pool_stat old, > > > > > > >>> dba_hist_buffer_pool_stat new, > > > > > > >>> dba_hist_snapshot sn > > > > > > >>> where > > > > > > >>> (((new.consistent_gets-old.consistent_gets)+ > > > > > > >>> (new.db_block_gets-old.db_block_gets))- > > > > > > >>> (new.physical_reads-old.physical_reads)) / > > > > > > >>> ((new.consistent_gets-old.consistent_gets)+ > > > > > > >>> (new.db_block_gets-old.db_block_gets)) > 0 > > > > > > >>> and > > > > > > >>> new.name = old.name > > > > > > >>> and > > > > > > >>> new.snap_id = sn.snap_id > > > > > > >>> and > > > > > > >>> old.snap_id = sn.snap_id-1 > > > > > > >>> order by mydate; > > > > > > >>> > > > > > > >>> ÍNDICE DE ACERTOS DE CACHE PARA OBJETOS DO DICIONÁRIO DE > DADOS > > > > > > >>> > ============================================================== > > > > > > >>> (hit ratio deve estar próximo a 1 - apesar de ser inviável > para > > > > alguns > > > > > > objetos, como sequences) > > > > > > >>> > > > > > > >>> select > > > > > > >>> parameter "Parametro", > > > > > > >>> gets, > > > > > > >>> Getmisses , > > > > > > >>> getmisses/(gets+getmisses)*100 "Taxa de erro", > > > > > > >>> (1-(sum(getmisses)/ (sum(gets)+sum(getmisses))))*100 "Taxa de > > > > acerto" > > > > > > >>> from v$rowcache > > > > > > >>> where gets+getmisses <>0 > > > > > > >>> group by parameter, gets, getmisses ; > > > > > > >>> > > > > > > >>> ÍNDICE DE ACERTOS NO CACHE POR SESSÃO > > > > > > >>> ===================================== > > > > > > >>> (hit ratio deve estar próximo a 1 - apesar de 1 ser > improvável) > > > > > > >>> > > > > > > >>> select Username, > > > > > > >>> OSUSER, > > > > > > >>> Consistent_Gets, > > > > > > >>> Block_Gets, > > > > > > >>> Physical_Reads, > > > > > > >>> 100*( Consistent_Gets + Block_Gets - Physical_Reads)/ > > > > > > >>> ( Consistent_Gets + Block_Gets ) "Hit Ratio %" > > > > > > >>> from V$SESSION,V$SESS_IO > > > > > > >>> where V$SESSION.SID = V$SESS_IO.SID > > > > > > >>> and ( Consistent_Gets + Block_Gets )>0 > > > > > > >>> and username is not null > > > > > > >>> order by Username,"Hit Ratio %"; > > > > > > >>> > > > > > > >>> ÍNDICES DE CONTENÇÃO DE LATCH DE REDO > > > > > > >>> ===================================== > > > > > > >>> (quanto mais abaixo de 1 os ratios, melhor) > > > > > > >>> > > > > > > >>> SET feedback OFF > > > > > > >>> COLUMN name FORMAT a15 > > > > > > >>> COLUMN gets FORMAT 99999999 > > > > > > >>> COLUMN misses FORMAT 999999 > > > > > > >>> COLUMN immediate_gets FORMAT 99999999 HEADING 'IMM_GETS' > > > > > > >>> COLUMN immediate_misses FORMAT 99999999 HEADING 'IMM_MISSES' > > > > > > >>> PROMPT Examining Contention for Redo Log Buffer Latches... > > > > > > >>> PROMPT ---------------------------------------------------- > > > > > > >>> > > > > > > >>> SELECT name, gets, misses, immediate_gets, immediate_misses, > > > > > > >>> Decode(gets,0,0,misses/gets*100) ratio1, > > > > > > >>> Decode(immediate_gets+immediate_misses,0,0, > > > > > > >>> immediate_misses/(immediate_gets+immediate_misses)*100) > ratio2 > > > > > > >>> FROM v$latch WHERE name IN ('redo allocation', 'redo copy'); > > > > > > >>> > > > > > > >>> ORDENAÇÕES EM MEMÓRIA/DISCO > > > > > > >>> =========================== > > > > > > >>> (quanto mais memória e menos disco, melhor) > > > > > > >>> > > > > > > >>> SET HEADING OFF > > > > > > >>> SET FEEDBACK OFF > > > > > > >>> COLUMN name FORMAT a30 > > > > > > >>> COLUMN value FORMAT 99999990 > > > > > > >>> > > > > > > >>> SELECT name, value FROM v$sysstat > > > > > > >>> WHERE name IN ('sorts (memory)', 'sorts (disk)'); > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> ------------------------------------ > > > > > > >>> > > > > > > >>> ---------------------------------------------------------- > > > > > > >>>> Atenção! As mensagens do grupo ORACLE_BR são de acesso > público e > > > > de > > > > > > inteira responsabilidade de seus remetentes. > > > > > > >>> Acesse: > http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ > > > > > > >>> ---------------------------------------------------------- > > > > > > >>>> Apostilas » Dicas e Exemplos » Função » Mundo Oracle » > Package » > > > > > > Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU > PROPRIO > > > > ESPAÇO! > > > > > > VISITE: http://www.oraclebr.com.br/ > > > > > > >>> ---------------------------------------------------------- > Links do > > > > > > Yahoo! Grupos > > > > > > >>> > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------ > > > > > > > > > > > > > > ---------------------------------------------------------- > > > > > > >> Atenção! As mensagens do grupo ORACLE_BR são de acesso público > e de > > > > > > inteira responsabilidade de seus remetentes. > > > > > > > Acesse: > http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ > > > > > > > ---------------------------------------------------------- > > > > > > >> Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package > » > > > > > > Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU > PROPRIO > > > > ESPAÇO! > > > > > > VISITE: http://www.oraclebr.com.br/ > > > > > > > ---------------------------------------------------------- > Links do > > > > > > Yahoo! Grupos > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Hevandro Veiga > > > > > Oracle Certified Professional 11g > > > > > OCE RAC 10g > > > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Hevandro Veiga > > > Oracle Certified Professional 11g > > > OCE RAC 10g > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > -- Hevandro Veiga Oracle Certified Professional 11g OCE RAC 10g [As partes desta mensagem que não continham texto foram removidas] ------------------------------------ -------------------------------------------------------------------------------------------------------------------------- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -------------------------------------------------------------------------------------------------------------------------- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ ------------------------------------------------------------------------------------------------------------------------ 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: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
