[oracle_br] Re: Diferença de planos ou estatisticas
Agradeçendo a ajuda dos colegas, e respondendo ao chiappa.. eu estou
usando os parametros _COMPLEX_VIEW_MERGING, e UNNEST_SUBQUERY como
default do banco, vou alterá-los e testar novamente..
Muito obrigado pelas dicas
Cristiano
--- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu
> Vários : erros de invalid number ou invalid date, erros ORA-nn
> diversos em montagem de hash tables, funções de strings (como SUBSTR,
> INSTR, etc) dando resultados errados Eu larguei mão TOTAL desse
> cara, em sistemas que não fazem BIND eu brigo até que seja feito
> isso, ou onde isso é fisicamente impossível ao menos tento esvaziar o
> cache de SQLs de tanto em tanto, esse parametrozinho é mesmo
> quebrado, IMHO. Se vc pesquisar no metalink, vc va achar PELO MENOS
> uma boa dezena de bugzinhos do tipo desse cara, e a maioria só foi
> corrigido no 10g (alguns só no 10gr2!!), pra quem não tá em 10g nem
> pensar em tentar usar isso...
>
> O pior dele, porém, ** não é ** os bugs, mas os efeitos colaterias :
> pra início de conversa, o trabalho de ficar pesquisando e trocando
> coisas num texto consome uma CPU que não é desprezível .Outra é o
> fato de como ele trabalha, o objetivo dele na vida é substituir TODOS
> OS LITERAIS com binds : assim (por exemplo), se vc tinha uma cláusula
> tipo :
>
> SUBSTR(campo, 1, 5)
>
> a ferramenta-cliente SABE que esse cara vai retornar 5 caracteres,
> normalmente sabe formatar a saída de acordo, com o raio desse
> parâmetro isso vira :
>
> SUBSTR(campo, :SYS_gahagag, :SYS_hsgsgs)
>
> ==> sabe-se lá qual o tamanho dessa saída
>
> Também tive interferência nos meus testes com índices de função, pois
> o SQL era tipo ... WHERE campo = funcçao('paramstring), e o raio
> desse treco trocava isso pra WHERE campo = função(:SYS_fdfda), e
> obviamente o índice não era nisso.
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "Augusto Cesar Rodovalho Costa"
> <[EMAIL PROTECTED]> escreveu
> > Só uma dúvida, quais são os bugs que encontraram ou problemas que
> tiveram
> > com esse parâmetro?
> > Atenciosamente.
> >
> > - Original Message -
> > From: "Renan da Silveira Medeiros" <[EMAIL PROTECTED]>
> > To:
> > Sent: Friday, September 30, 2005 8:44 AM
> > Subject: Re: [oracle_br] Re: Diferença de planos ou estatisticas
> >
> >
> > Aproveitando o assunto do Chiappa sobre CURSOR_SHARING, afirmo o
> seguinte :
> > NÃO USE. Outro dia num cliente implantei a utilização do mesmo, e
> uma semana
> > depois começou a dar alguns erros numa determinada aplicação.
> Resumo da
> > ópera, continua com os mesmo bug´s da versão 8i.
> >
> > Renan Medeiros
> > .
> > Unimix Tecnologia Ltda
> > 0 xx 61 8145 7869
> > 0 xx 61 3201
> >
> > - Original Message -
> > From: jlchiappa
> > To: oracle_br@yahoogrupos.com.br
> > Sent: Thursday, September 29, 2005 10:18 PM
> > Subject: [oracle_br] Re: Diferença de planos ou estatisticas
> >
> >
> > Seguinte : quanto às bind variables, isso depende da versão : na
> 9i em
> > diante o banco consegue antes de executar o bind dar uma "sapeada"
> > rápida nos histogramas (pesquise em http://asktom.oracle.com por
> BIND
> > VARIABLES PEEKING que vc acha alguns casos-exemplo) . Já na
> versão 8i
> > e anteriores isso não existia, então sim, na 8i basicamente era OU
> > histograma OU bind variable, vc não podia ter os dois.
> > Quanto ao CURSOR_SHARING, já que ele efetivamente altera o SQL a
> ser
> > enviado pro banco, substituindo o que está fixo por BIND
> VARIABLES, **
> > creio ** que vale o mesmo : na 9i em diante faz peeking, na 8i
> não usa
> > histogramas. Nunca usei esse cara (ele era muito bugado e muito
> > imprevisível pro meu gosto), mas acho que é isso.
> >
> > []s
> >
> > Chiappa
> > --- Em oracle_br@yahoogrupos.com.br, Roberto Cavalcanti
> > <[EMAIL PROTECTED]> escreveu
> > > Aproveitando o assunto, a utilização de histogramas
> > > funcionam quando se utiliza "bind variable" ou
> > > cursor_sharing = SIMILAR ?
> > >
> > > Sds
> > >
> > > Roberto
> > > --- jlchiappa <[EMAIL PROTECTED]> escreveu:
> > >
> > > > Com certeza, usar GATHER_SCHEMA_STATS é, na maior
> > > > parte das vezes,
> > > > uma BOBEIRA, pois vc está coletando da MESMA maneira
> > > > as difere
[oracle_br] Re: Diferença de planos ou estatisticas
Vários : erros de invalid number ou invalid date, erros ORA-nn
diversos em montagem de hash tables, funções de strings (como SUBSTR,
INSTR, etc) dando resultados errados Eu larguei mão TOTAL desse
cara, em sistemas que não fazem BIND eu brigo até que seja feito
isso, ou onde isso é fisicamente impossível ao menos tento esvaziar o
cache de SQLs de tanto em tanto, esse parametrozinho é mesmo
quebrado, IMHO. Se vc pesquisar no metalink, vc va achar PELO MENOS
uma boa dezena de bugzinhos do tipo desse cara, e a maioria só foi
corrigido no 10g (alguns só no 10gr2!!), pra quem não tá em 10g nem
pensar em tentar usar isso...
O pior dele, porém, ** não é ** os bugs, mas os efeitos colaterias :
pra início de conversa, o trabalho de ficar pesquisando e trocando
coisas num texto consome uma CPU que não é desprezível .Outra é o
fato de como ele trabalha, o objetivo dele na vida é substituir TODOS
OS LITERAIS com binds : assim (por exemplo), se vc tinha uma cláusula
tipo :
SUBSTR(campo, 1, 5)
a ferramenta-cliente SABE que esse cara vai retornar 5 caracteres,
normalmente sabe formatar a saída de acordo, com o raio desse
parâmetro isso vira :
SUBSTR(campo, :SYS_gahagag, :SYS_hsgsgs)
==> sabe-se lá qual o tamanho dessa saída
Também tive interferência nos meus testes com índices de função, pois
o SQL era tipo ... WHERE campo = funcçao('paramstring), e o raio
desse treco trocava isso pra WHERE campo = função(:SYS_fdfda), e
obviamente o índice não era nisso.
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "Augusto Cesar Rodovalho Costa"
<[EMAIL PROTECTED]> escreveu
> Só uma dúvida, quais são os bugs que encontraram ou problemas que
tiveram
> com esse parâmetro?
> Atenciosamente.
>
> - Original Message -
> From: "Renan da Silveira Medeiros" <[EMAIL PROTECTED]>
> To:
> Sent: Friday, September 30, 2005 8:44 AM
> Subject: Re: [oracle_br] Re: Diferença de planos ou estatisticas
>
>
> Aproveitando o assunto do Chiappa sobre CURSOR_SHARING, afirmo o
seguinte :
> NÃO USE. Outro dia num cliente implantei a utilização do mesmo, e
uma semana
> depois começou a dar alguns erros numa determinada aplicação.
Resumo da
> ópera, continua com os mesmo bug´s da versão 8i.
>
> Renan Medeiros
> .
> Unimix Tecnologia Ltda
> 0 xx 61 8145 7869
> 0 xx 61 3201
>
> - Original Message -
> From: jlchiappa
> To: oracle_br@yahoogrupos.com.br
> Sent: Thursday, September 29, 2005 10:18 PM
> Subject: [oracle_br] Re: Diferença de planos ou estatisticas
>
>
> Seguinte : quanto às bind variables, isso depende da versão : na
9i em
> diante o banco consegue antes de executar o bind dar uma "sapeada"
> rápida nos histogramas (pesquise em http://asktom.oracle.com por
BIND
> VARIABLES PEEKING que vc acha alguns casos-exemplo) . Já na
versão 8i
> e anteriores isso não existia, então sim, na 8i basicamente era OU
> histograma OU bind variable, vc não podia ter os dois.
> Quanto ao CURSOR_SHARING, já que ele efetivamente altera o SQL a
ser
> enviado pro banco, substituindo o que está fixo por BIND
VARIABLES, **
> creio ** que vale o mesmo : na 9i em diante faz peeking, na 8i
não usa
> histogramas. Nunca usei esse cara (ele era muito bugado e muito
> imprevisível pro meu gosto), mas acho que é isso.
>
> []s
>
> Chiappa
> --- Em oracle_br@yahoogrupos.com.br, Roberto Cavalcanti
> <[EMAIL PROTECTED]> escreveu
> > Aproveitando o assunto, a utilização de histogramas
> > funcionam quando se utiliza "bind variable" ou
> > cursor_sharing = SIMILAR ?
> >
> > Sds
> >
> > Roberto
> > --- jlchiappa <[EMAIL PROTECTED]> escreveu:
> >
> > > Com certeza, usar GATHER_SCHEMA_STATS é, na maior
> > > parte das vezes,
> > > uma BOBEIRA, pois vc está coletando da MESMA maneira
> > > as diferentes
> > > tabelas que existem num schema, e na real certamente
> > > devem existir
> > > ALGUMAS tabelas que precisam de histograma, ALGUMAs
> > > que não, ALGUMAS
> > > que exigem COMPUTE, e GATHER_SCHEMA coleta tudo
> > > igual pra todas
> > > Em msgs recentes aqui mesmo isso já foi discutido,
> > > mas vale o
> > > lembrete. No caso em questão, porém, pelo q entendi
> > > vc antes coletava
> > > com ANALYZE aí passou pra DBMS_STAT, certo, então
> > > ALÉM de usar
> > > erradamente a GATHER_SCHEMA, ainda HÀ SIM diferenças
> > > entre os
> > > defaults do ANALYZE e da DBMS_STATS
> > > Afora isso : a primeira coisa que se pensa é, os
> > > parãmet
RES: [oracle_br] Re: Diferença de planos ou estatisticas
Verdade verdadeira, uma versão 9i pode se comportar diferente duma 8i mesmo com parâmetros e estats absolutamente iguais : no caso em questão, porém, ele antes usava ANALYZE, depois passou a GATHER_SCHEMA, e provavelmente usando os defaults, que comprovadamente SÂO SIM absolutamente diferentes, então no caso em questão se eu fosse apostar ainda apostaria é mesmo em diferenças de stat e configs, ou nos params que mudaram de default no 9i. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Bruno Leonardo Santos Nascimento" <[EMAIL PROTECTED]> escreveu > > Além da coleta de estatísticas, deve-se considerar a evolução do próprio otimizador, que pode fazer com que consultas idênticas em objetos idênticos e com estatísticas idênticas, mas em ambientes com versões diferentes, sejam atendidas por planos distintos. > > Att., > Bruno Leonardo > > -Mensagem original- > De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] > nome de jlchiappa > Enviada em: quinta-feira, 29 de setembro de 2005 11:33 > Para: oracle_br@yahoogrupos.com.br > Assunto: [oracle_br] Re: Diferença de planos ou estatisticas > > > Com certeza, usar GATHER_SCHEMA_STATS é, na maior parte das vezes, > uma BOBEIRA, pois vc está coletando da MESMA maneira as diferentes > tabelas que existem num schema, e na real certamente devem existir > ALGUMAS tabelas que precisam de histograma, ALGUMAs que não, ALGUMAS > que exigem COMPUTE, e GATHER_SCHEMA coleta tudo igual pra todas > Em msgs recentes aqui mesmo isso já foi discutido, mas vale o > lembrete. No caso em questão, porém, pelo q entendi vc antes coletava > com ANALYZE aí passou pra DBMS_STAT, certo, então ALÉM de usar > erradamente a GATHER_SCHEMA, ainda HÀ SIM diferenças entre os > defaults do ANALYZE e da DBMS_STATS > Afora isso : a primeira coisa que se pensa é, os parãmetros de CBO > (ie, optimizer_nnn), de I/O (como multiblock), de consumo de RAM (SGA > e PGA) estão bons no banco 9i ?? O 9i é mesmo maior, é comum ele > exigir um tanto a mais de RAM e de CPU. Outra coisa : alguns > parâmetros de queries complexas (como o _COMPLEX_VIEW_MERGING, o > UNNEST_SUBQUERY, etc) ** MUDARAM ** de default no 9i, vc checou > isso ?? > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, "cristiano_miolo" > <[EMAIL PROTECTED]> escreveu > > Bom Dia amigos, migrei um banco de 8i para o 9i, tenho notado que > > algumas consultas estão com planos diferentes do que executavam > > anteriormente, eu estou usando CBO e coletando estatisticas > diarimente > > através do dbms_stats.gather_schema_stats, a minha duvida seria se o > > modo que estou coletando estatísticas está diferente do analyze do > 8i? > > isto pode ser o agravante?? > > > > []'s > > > > Cristiano > > > > > ORACLE_BR APOIA 2ºENPO-BR _ > O 2º Encontro Nacional de Profissionais Oracle será realizado no dia 05/11/2005 no auditório da FIAP em São Paulo. Serão apresentadas Palestras e Cases dirigidos exclusivamente por profissionais especialistas e renomados no mercado. Confira a programação no site do evento! http://www.enpo-br.org/ > _ > > Links do Yahoo! Grupos ORACLE_BR APOIA 2ºENPO-BR _ O 2º Encontro Nacional de Profissionais Oracle será realizado no dia 05/11/2005 no auditório da FIAP em São Paulo. Serão apresentadas Palestras e Cases dirigidos exclusivamente por profissionais especialistas e renomados no mercado. Confira a programação no site do evento! http://www.enpo-br.org/ _ 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
[oracle_br] Re: Diferença de planos ou estatisticas
Seguinte : quanto às bind variables, isso depende da versão : na 9i em diante o banco consegue antes de executar o bind dar uma "sapeada" rápida nos histogramas (pesquise em http://asktom.oracle.com por BIND VARIABLES PEEKING que vc acha alguns casos-exemplo) . Já na versão 8i e anteriores isso não existia, então sim, na 8i basicamente era OU histograma OU bind variable, vc não podia ter os dois. Quanto ao CURSOR_SHARING, já que ele efetivamente altera o SQL a ser enviado pro banco, substituindo o que está fixo por BIND VARIABLES, ** creio ** que vale o mesmo : na 9i em diante faz peeking, na 8i não usa histogramas. Nunca usei esse cara (ele era muito bugado e muito imprevisível pro meu gosto), mas acho que é isso. []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Roberto Cavalcanti <[EMAIL PROTECTED]> escreveu > Aproveitando o assunto, a utilização de histogramas > funcionam quando se utiliza "bind variable" ou > cursor_sharing = SIMILAR ? > > Sds > > Roberto > --- jlchiappa <[EMAIL PROTECTED]> escreveu: > > > Com certeza, usar GATHER_SCHEMA_STATS é, na maior > > parte das vezes, > > uma BOBEIRA, pois vc está coletando da MESMA maneira > > as diferentes > > tabelas que existem num schema, e na real certamente > > devem existir > > ALGUMAS tabelas que precisam de histograma, ALGUMAs > > que não, ALGUMAS > > que exigem COMPUTE, e GATHER_SCHEMA coleta tudo > > igual pra todas > > Em msgs recentes aqui mesmo isso já foi discutido, > > mas vale o > > lembrete. No caso em questão, porém, pelo q entendi > > vc antes coletava > > com ANALYZE aí passou pra DBMS_STAT, certo, então > > ALÉM de usar > > erradamente a GATHER_SCHEMA, ainda HÀ SIM diferenças > > entre os > > defaults do ANALYZE e da DBMS_STATS > > Afora isso : a primeira coisa que se pensa é, os > > parãmetros de CBO > > (ie, optimizer_nnn), de I/O (como multiblock), de > > consumo de RAM (SGA > > e PGA) estão bons no banco 9i ?? O 9i é mesmo > > maior, é comum ele > > exigir um tanto a mais de RAM e de CPU. Outra coisa > > : alguns > > parâmetros de queries complexas (como o > > _COMPLEX_VIEW_MERGING, o > > UNNEST_SUBQUERY, etc) ** MUDARAM ** de default no > > 9i, vc checou > > isso ?? > > > > []s > > > > Chiappa > > > > --- Em oracle_br@yahoogrupos.com.br, > > "cristiano_miolo" > > <[EMAIL PROTECTED]> escreveu > > > Bom Dia amigos, migrei um banco de 8i para o 9i, > > tenho notado que > > > algumas consultas estão com planos diferentes do > > que executavam > > > anteriormente, eu estou usando CBO e coletando > > estatisticas > > diarimente > > > através do dbms_stats.gather_schema_stats, a minha > > duvida seria se o > > > modo que estou coletando estatísticas está > > diferente do analyze do > > 8i? > > > isto pode ser o agravante?? > > > > > > []'s > > > > > > Cristiano > > > > > > > > > > ORACLE_BR APOIA 2ºENPO-BR > > > _ > > O 2º Encontro Nacional de Profissionais Oracle será > > realizado no dia 05/11/2005 no auditório da FIAP em > > São Paulo. Serão apresentadas Palestras e Cases > > dirigidos exclusivamente por profissionais > > especialistas e renomados no mercado. Confira a > > programação no site do evento! > > http://www.enpo-br.org/ > > > _ > > > > Links do Yahoo! Grupos > > > > > > > > http://br.yahoo.com/info/utos.html > > > > > > > > > > > > > > > > > > > > ___ > Novo Yahoo! Messenger com voz: ligações, Yahoo! Avatars, novos emoticons e muito mais. Instale agora! > www.yahoo.com.br/messenger/ ORACLE_BR APOIA 2ºENPO-BR _ O 2º Encontro Nacional de Profissionais Oracle será realizado no dia 05/11/2005 no auditório da FIAP em São Paulo. Serão apresentadas Palestras e Cases dirigidos exclusivamente por profissionais especialistas e renomados no mercado. Confira a programação no site do evento! http://www.enpo-br.org/ _ 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
Re: [oracle_br] Re: Diferença de planos ou estatisticas
Aproveitando o assunto, a utilização de histogramas funcionam quando se utiliza "bind variable" ou cursor_sharing = SIMILAR ? Sds Roberto --- jlchiappa <[EMAIL PROTECTED]> escreveu: > Com certeza, usar GATHER_SCHEMA_STATS é, na maior > parte das vezes, > uma BOBEIRA, pois vc está coletando da MESMA maneira > as diferentes > tabelas que existem num schema, e na real certamente > devem existir > ALGUMAS tabelas que precisam de histograma, ALGUMAs > que não, ALGUMAS > que exigem COMPUTE, e GATHER_SCHEMA coleta tudo > igual pra todas > Em msgs recentes aqui mesmo isso já foi discutido, > mas vale o > lembrete. No caso em questão, porém, pelo q entendi > vc antes coletava > com ANALYZE aí passou pra DBMS_STAT, certo, então > ALÉM de usar > erradamente a GATHER_SCHEMA, ainda HÀ SIM diferenças > entre os > defaults do ANALYZE e da DBMS_STATS > Afora isso : a primeira coisa que se pensa é, os > parãmetros de CBO > (ie, optimizer_nnn), de I/O (como multiblock), de > consumo de RAM (SGA > e PGA) estão bons no banco 9i ?? O 9i é mesmo > maior, é comum ele > exigir um tanto a mais de RAM e de CPU. Outra coisa > : alguns > parâmetros de queries complexas (como o > _COMPLEX_VIEW_MERGING, o > UNNEST_SUBQUERY, etc) ** MUDARAM ** de default no > 9i, vc checou > isso ?? > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br, > "cristiano_miolo" > <[EMAIL PROTECTED]> escreveu > > Bom Dia amigos, migrei um banco de 8i para o 9i, > tenho notado que > > algumas consultas estão com planos diferentes do > que executavam > > anteriormente, eu estou usando CBO e coletando > estatisticas > diarimente > > através do dbms_stats.gather_schema_stats, a minha > duvida seria se o > > modo que estou coletando estatísticas está > diferente do analyze do > 8i? > > isto pode ser o agravante?? > > > > []'s > > > > Cristiano > > > > > ORACLE_BR APOIA 2ºENPO-BR > _ > O 2º Encontro Nacional de Profissionais Oracle será > realizado no dia 05/11/2005 no auditório da FIAP em > São Paulo. Serão apresentadas Palestras e Cases > dirigidos exclusivamente por profissionais > especialistas e renomados no mercado. Confira a > programação no site do evento! > http://www.enpo-br.org/ > _ > > Links do Yahoo! Grupos > > > > http://br.yahoo.com/info/utos.html > > > > > ___ Novo Yahoo! Messenger com voz: ligações, Yahoo! Avatars, novos emoticons e muito mais. Instale agora! www.yahoo.com.br/messenger/ ORACLE_BR APOIA 2ºENPO-BR _ O 2º Encontro Nacional de Profissionais Oracle será realizado no dia 05/11/2005 no auditório da FIAP em São Paulo. Serão apresentadas Palestras e Cases dirigidos exclusivamente por profissionais especialistas e renomados no mercado. Confira a programação no site do evento! http://www.enpo-br.org/ _ 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
[oracle_br] Re: Diferença de planos ou estatisticas
Com certeza, usar GATHER_SCHEMA_STATS é, na maior parte das vezes, uma BOBEIRA, pois vc está coletando da MESMA maneira as diferentes tabelas que existem num schema, e na real certamente devem existir ALGUMAS tabelas que precisam de histograma, ALGUMAs que não, ALGUMAS que exigem COMPUTE, e GATHER_SCHEMA coleta tudo igual pra todas Em msgs recentes aqui mesmo isso já foi discutido, mas vale o lembrete. No caso em questão, porém, pelo q entendi vc antes coletava com ANALYZE aí passou pra DBMS_STAT, certo, então ALÉM de usar erradamente a GATHER_SCHEMA, ainda HÀ SIM diferenças entre os defaults do ANALYZE e da DBMS_STATS Afora isso : a primeira coisa que se pensa é, os parãmetros de CBO (ie, optimizer_nnn), de I/O (como multiblock), de consumo de RAM (SGA e PGA) estão bons no banco 9i ?? O 9i é mesmo maior, é comum ele exigir um tanto a mais de RAM e de CPU. Outra coisa : alguns parâmetros de queries complexas (como o _COMPLEX_VIEW_MERGING, o UNNEST_SUBQUERY, etc) ** MUDARAM ** de default no 9i, vc checou isso ?? []s Chiappa --- Em oracle_br@yahoogrupos.com.br, "cristiano_miolo" <[EMAIL PROTECTED]> escreveu > Bom Dia amigos, migrei um banco de 8i para o 9i, tenho notado que > algumas consultas estão com planos diferentes do que executavam > anteriormente, eu estou usando CBO e coletando estatisticas diarimente > através do dbms_stats.gather_schema_stats, a minha duvida seria se o > modo que estou coletando estatísticas está diferente do analyze do 8i? > isto pode ser o agravante?? > > []'s > > Cristiano ORACLE_BR APOIA 2ºENPO-BR _ O 2º Encontro Nacional de Profissionais Oracle será realizado no dia 05/11/2005 no auditório da FIAP em São Paulo. Serão apresentadas Palestras e Cases dirigidos exclusivamente por profissionais especialistas e renomados no mercado. Confira a programação no site do evento! http://www.enpo-br.org/ _ 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
