Re: RES: [oracle_br] Export/Import

[nandoverona]

SO - Win2003
Versão - 10g
Fiz um exp com todos os valores padrões.




--- Em oracle_br@yahoogrupos.com.br, "Rafael Milanez" <[EMAIL PROTECTED]> 
escreveu
>
> Pra variar ,
> 
>  
> 
> Sistema Op
> 
>  
> 
> E versão do banco,
> 
>  
> 
> E como fez esse bkp ?
> 
>  
> 
> -Mensagem original-
> De: oracle_br@yahoogrupos.com.br 
[mailto:[EMAIL PROTECTED] Em nome de nandoverona
> Enviada em: sexta-feira, 1 de junho de 2007 17:16
> Para: oracle_br@yahoogrupos.com.br
> Assunto: [oracle_br] Export/Import
> 
>  
> 
> Pessoal,
> 
> Tô com uma dúvida.
> Eu tenho um banco de produção, tô fazendo o bkp todos os dia com 
export 
> (banco inteiro).
> 
> Agora eu quero testar um restor em outra máquina.
> Já instalei o Oracle nela com o mesmo nome da instância.
> 
> Em que estado tem que estar o BD?
> Quando eu dou o import ele cria todas as tablespaces???
> 
> Alguém utiliza essa estratégia de bkp?
> 
> Obrigado
> 
>  
> 
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

Re: RES: [oracle_br] Export/Import Lento

[jlchiappa]

Está ** totalmente ** sob seu controle, se vc for descuidado e rodar 
o imp 2 vezes sem constraint, sim, é claro que vai duplicar. Quanto à 
outra pergunta, migração entre sistemas operacionais até a versão 9i 
TEM QUE ser extraindo-se os dados  do bd origem e inserindo no bd 
destino, não há outra forma. Essa extração pode ser via exp/imp, pode 
ser gerando-se arquivo-texto com os dados na origem e depois load no 
bd destino, pode ser via db link se os 2 bancos estão ativos (ie, 
insert ou copy no sql*plus), pode ser via programa de terceiros 
(existem programa que extraem em .txt ou em formatos binários)... O 
ponto porém é que até a versão 9i o formato dos datafiles em sistemas 
operacionais diferentes é ** incompatível **, não dá pra vc pegar o 
datafile dum sistema operacional X e copiar pro Y.

[]s

 Chiappa
 
--- Em oracle_br@yahoogrupos.com.br, "Akira" <[EMAIL PROTECTED]> 
escreveu
> 
> Mas... tem perigo de duplicar registro ou não, se eu fizer o imp 
sem índices e constraints mais de 1 vez?
> E alguém conhece alguma outra forma de se fazer esse tipo de 
migração? Windows para Linux ou vice-versa, no 9i...
> 
> Obrigado pelas respostas.
> []'s
> Akira
> 
>   - Original Message - 
>   From: jlchiappa 
>   To: oracle_br@yahoogrupos.com.br 
>   Sent: Thursday, July 07, 2005 4:49 PM
>   Subject: Re: RES: [oracle_br] Export/Import Lento
> 
> 
>   Respostas abaixo :
> 
>   >> Eu até pensei em fazer algo assim... imp constraints=n 
indexes=n 
>   rows=y, depois
>   um imp rows=n, o que acha?
> 
>   A idéia do imp sem constraints e índices é trazer *** apenas *** 
os 
>   dados, e os índices e constraints vc obter um script com eles 
>   (provavelmente via indexfile no imp), alterar o script para as 
opções 
>   de nOLOGGING e NOVALIDATE, e aí criar VIA SCRIPT, *** fugindo 
***, do 
>   imp, criar índices e constraints via imp é leeento, é serial 
ainda 
>   que a máquina aceito parallel, é feito em modo LOGGING, é ruim.
> 
>   >> Mas a situação estava ruim... o export eu já tinha feito 
full=y 
>   apenas... e a
>   base do windows já tinha sido queimada. O export full simples ou 
** 
>   impróprio **
>   era a minha única ficha naquela hora. 
> 
>   Bem, ao menos vc ficou sabendo que exp & imp full ** não é ** a 
>   melhor maneira, ganhou experiência. 
> 
>   >> Eu fiquei na dúvida se poderia cancelar o
>   imp (ctrl+C) e fazer novamente sem os índices e constraints... 
fiquei 
>   com medo
>   de acabar de estragar tudo.
> 
>   O bd Oracle é um tantinho mais resistente que isso, "estragar", 
(ie, 
>   crashar, perder dados) acho que não tem a ver, o que poderia 
>   acontecer se vc interromper o imp é se vc interrompeu no meio de 
um 
>   criação de índice, a tabela ficou sem o índice, se o índice era 
usado 
>   numa constraint a constraint fica inválida, mas perda de dados 
não 
>   vejo como.
> 
>   >> é Já tinha se passado 4 horas nesse momento, e meu
>   tempo estava ficando curto. 
> 
>   Na verdade vc errou em :
> 
>   a) não fazer um teste antes
>   b) não pesuqisar as opções adequadas de performance
> 
>   aí com tempo curto não dava mesmo pra fazer direito, aí acaba 
>   demorando é mais ainda : o tempo que se gasta pesquisando e 
treinando 
>   antes de ir pra produção ** QUASE SEMPRE ** é investimento 
garantido, 
>   retorno sem dúvida.
> 
> 
> 
>   >> Ahhh, sobre fazer paralelo por schemas, eu pensei em dois 
>   problemas nisso... um
>   eram os usuários que eu teria que recriar, com senhas e tudo... 
outro 
>   eram as
>   fks referenciando schemas diferentes, acho que isso ia perder 
(claro, 
>   se eu
>   gerar o scripts de criação das constrains, isso não seria 
problema). 
>   Quanto aos
>   usuários, tem jeito de serem importados antes ou depois, com 
senha e 
>   tudo?
> 
>   Na verdade a idéia de ter vários imps por usuário (ou pro grupo 
de 
>   tableas, ou coisa do tipo) necessariamente IMPLICA que , não 
sendo 
>   exp full, vc VAI TER QUE criar as tablespaces, usuários, etc, no 
bd 
>   destino. È ridiculamente simples, porém, a partir do bd origem, 
vc 
>   montar um script pra isso e depois rodar o script no bd destino 
via 
>   sqlplus :
> 
>   [EMAIL PROTECTED]:SQL>l
> 1  select 'CREATE USER ' || username || ' identified by values'
> 2   || chr(39) || password || chr(39)
> 3   || ' default tablespace ' || default_tablespace
> 4   || ' temporary tablespace ' || temporary_tablespace
> 5*  || ';' from dba_users
>   [EMAIL PROTECTED]:SQL>/
> 
>   'CREATEUSER'||USERNAME||'IDENTIFIEDBYVALUES'||CHR(39)
||PASSWORD||CHR
>   (39)||'D

Re: RES: [oracle_br] Export/Import Lento

[Akira]

Mas... tem perigo de duplicar registro ou não, se eu fizer o imp sem índices e 
constraints mais de 1 vez?
E alguém conhece alguma outra forma de se fazer esse tipo de migração? Windows 
para Linux ou vice-versa, no 9i...

Obrigado pelas respostas.
[]'s
Akira

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Thursday, July 07, 2005 4:49 PM
  Subject: Re: RES: [oracle_br] Export/Import Lento


  Respostas abaixo :

  >> Eu até pensei em fazer algo assim... imp constraints=n indexes=n 
  rows=y, depois
  um imp rows=n, o que acha?

  A idéia do imp sem constraints e índices é trazer *** apenas *** os 
  dados, e os índices e constraints vc obter um script com eles 
  (provavelmente via indexfile no imp), alterar o script para as opções 
  de nOLOGGING e NOVALIDATE, e aí criar VIA SCRIPT, *** fugindo ***, do 
  imp, criar índices e constraints via imp é leeento, é serial ainda 
  que a máquina aceito parallel, é feito em modo LOGGING, é ruim.

  >> Mas a situação estava ruim... o export eu já tinha feito full=y 
  apenas... e a
  base do windows já tinha sido queimada. O export full simples ou ** 
  impróprio **
  era a minha única ficha naquela hora. 

  Bem, ao menos vc ficou sabendo que exp & imp full ** não é ** a 
  melhor maneira, ganhou experiência. 

  >> Eu fiquei na dúvida se poderia cancelar o
  imp (ctrl+C) e fazer novamente sem os índices e constraints... fiquei 
  com medo
  de acabar de estragar tudo.

  O bd Oracle é um tantinho mais resistente que isso, "estragar", (ie, 
  crashar, perder dados) acho que não tem a ver, o que poderia 
  acontecer se vc interromper o imp é se vc interrompeu no meio de um 
  criação de índice, a tabela ficou sem o índice, se o índice era usado 
  numa constraint a constraint fica inválida, mas perda de dados não 
  vejo como.

  >> é Já tinha se passado 4 horas nesse momento, e meu
  tempo estava ficando curto. 

  Na verdade vc errou em :

  a) não fazer um teste antes
  b) não pesuqisar as opções adequadas de performance

  aí com tempo curto não dava mesmo pra fazer direito, aí acaba 
  demorando é mais ainda : o tempo que se gasta pesquisando e treinando 
  antes de ir pra produção ** QUASE SEMPRE ** é investimento garantido, 
  retorno sem dúvida.



  >> Ahhh, sobre fazer paralelo por schemas, eu pensei em dois 
  problemas nisso... um
  eram os usuários que eu teria que recriar, com senhas e tudo... outro 
  eram as
  fks referenciando schemas diferentes, acho que isso ia perder (claro, 
  se eu
  gerar o scripts de criação das constrains, isso não seria problema). 
  Quanto aos
  usuários, tem jeito de serem importados antes ou depois, com senha e 
  tudo?

  Na verdade a idéia de ter vários imps por usuário (ou pro grupo de 
  tableas, ou coisa do tipo) necessariamente IMPLICA que , não sendo 
  exp full, vc VAI TER QUE criar as tablespaces, usuários, etc, no bd 
  destino. È ridiculamente simples, porém, a partir do bd origem, vc 
  montar um script pra isso e depois rodar o script no bd destino via 
  sqlplus :

  [EMAIL PROTECTED]:SQL>l
1  select 'CREATE USER ' || username || ' identified by values'
2   || chr(39) || password || chr(39)
3   || ' default tablespace ' || default_tablespace
4   || ' temporary tablespace ' || temporary_tablespace
5*  || ';' from dba_users
  [EMAIL PROTECTED]:SQL>/

  'CREATEUSER'||USERNAME||'IDENTIFIEDBYVALUES'||CHR(39)||PASSWORD||CHR
  (39)||'DEFAULTTABLESPACE'||DEFAULT_TABLESPACE||'TEMPORARYTABLE
  --
  
  CREATE USER SYS identified by values'D4C5016XYX6A' default tablespace 
  SYSTEM temporary tablespace TEMP;
  CREATE USER SYSTEM identified by values'CDB5XYZDEC9E4E95' default 
  tablespace ORAUSERS temporary tablespace TEMP;
  CREATE USER OUTLN identified by values'4A3BAXYZ08595C81' default 
  tablespace ORAUSERS temporary tablespace TEMP;
  CREATE USER DBSNMP identified by values'E066AGBDF5421CCC' default 
  tablespace ORAUSERS temporary tablespace TEMP;
  

  --- Em oracle_br@yahoogrupos.com.br, "Akira" <[EMAIL PROTECTED]> 
  escreveu
  > 
  > Valeu pela dica Chiappa... vou tentar esse caminho na próxima vez.
  > 
  > Me deixe apenas colocar umas dúvidas que tive.
  > Eu até pensei em fazer algo assim... imp constraints=n indexes=n 
  rows=y, depois um imp rows=n, o que acha?
  > Mas a situação estava ruim... o export eu já tinha feito full=y 
  apenas... e a base do windows já tinha sido queimada. O export full 
  simples ou ** impróprio ** era a minha única ficha naquela hora. Eu 
  fiquei na dúvida se poderia cancelar o imp (ctrl+C) e fazer novamente 
  sem os índices e constraints... fiquei com medo de acabar 

Re: RES: [oracle_br] Export/Import Lento

[jlchiappa]

iando schemas diferentes, acho que 
isso ia perder (claro, se eu gerar o scripts de criação das 
constrains, isso não seria problema). Quanto aos usuários, tem jeito 
de serem importados antes ou depois, com senha e tudo?
> 
> Desde já, agradeço a colaboração de todos.
> 
> []'s
> Akira
>   - Original Message - 
>   From: jlchiappa 
>   To: oracle_br@yahoogrupos.com.br 
>   Sent: Thursday, July 07, 2005 1:56 PM
>   Subject: Re: RES: [oracle_br] Export/Import Lento
> 
> 
>   Esses comandos foram bem simples mas também bem ** impróprios ** 
para 
>   performance, pois os defaults do exp/imp nem de longe são os 
ideais. 
>   Antes de falar deles, porém, uma obs : exp/imp full significa que 
vc 
>   vai SERIALIZAR, ie : um único programa vaie ler os objetos UM por 
UM 
>   (o exp), e depois vai gravar (o imp). Se o seu hardware permite 
>   (normalmente servidores permitem), não seria *** muito *** mais 
>   lógico vc ter vários programas lendo coisas diferentes ao mesmo 
>   tempo, e depois vc ter vários gravando ??? Só seria, então pra 
obter 
>   isso é ao invés de ter um único, ter-se ** vários ** exps em 
>   paralelo, cada um gravando um schema, ou cada um gravando um 
grupo de 
>   tabelas diferentes, em arquivos .dmp diferentes, e depois vc vai 
ter 
>   vários imps lendo os vários .dmps 
> 
>   Quanto aos comandos que ao não informar vc aceitou o default , e 
que 
>   eu recomendo NÂO fazer isso, são : direct=y, buffer (coloque um 
valor 
>   alto mas factível, digamos uns 10 Mb), compress=N (porque senão 
os 
>   extents que o imp cria são gigantescos, demora ** mesmo ** e usa 
>   espaço horrivelmente!), recordlength=65535 (todo servidor aceita 
>   isso, em tese), STATISTICS=NONE (é muito + rápido se recoletar as 
>   stst depois no bd destino via DBMS_STATS)... 
> Outro ponto é que o imp faz ** TUDO ** em modo logging e 
serial, E 
>   as constraints são validadas,  pode ser ** muito ** interessante 
vc 
>   não exportar e constraints, depois gera num script o comando de 
>   criação dos índices adicionando um NOLOGGING e PARALLEL (se o 
>   hardware permite), e script das constraints com a opção ENABLE 
>   NOVALIDATE. 
> 
> Essas coisas certamente devem melhorar ** enormemente ** a 
>   performance, vc acha as sintaxes e refs no manual "Oracle 
Utilies" e 
>   no "SQL reference".
> 
> []s
> 
>  Chiappa
>  
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]




__

Cancelar assinatura...: [EMAIL PROTECTED]
Moderadores da lista:Dorian Anderson Soutto [EMAIL PROTECTED] 
Fernanda Damous [EMAIL PROTECTED] 
Alisson Aguiar [EMAIL PROTECTED]
__
http://br.groups.yahoo.com/group/oracle_br/ 
__

Sair da Lista...: [EMAIL PROTECTED] 
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: RES: [oracle_br] Export/Import Lento

[Akira]

Valeu pela dica Chiappa... vou tentar esse caminho na próxima vez.

Me deixe apenas colocar umas dúvidas que tive.
Eu até pensei em fazer algo assim... imp constraints=n indexes=n rows=y, depois 
um imp rows=n, o que acha?
Mas a situação estava ruim... o export eu já tinha feito full=y apenas... e a 
base do windows já tinha sido queimada. O export full simples ou ** impróprio 
** era a minha única ficha naquela hora. Eu fiquei na dúvida se poderia 
cancelar o imp (ctrl+C) e fazer novamente sem os índices e constraints... 
fiquei com medo de acabar de estragar tudo. Já tinha se passado 4 horas nesse 
momento, e meu tempo estava ficando curto. Vc sabe se o cancelamento poderia 
danificar algo? Minha dúvida era se sem constraints, o import não duplicaria 
registros, no caso de se cancelar e fazer novamente. Se ocorresse isso, eu 
teria que partir do zero novamente. Vc sabe se isso pode acontecer 
(duplicidade) ou foi pura variação da minha cabeça depois de uns redbulls? 
:-)

Ahhh, sobre fazer paralelo por schemas, eu pensei em dois problemas nisso... um 
eram os usuários que eu teria que recriar, com senhas e tudo... outro eram as 
fks referenciando schemas diferentes, acho que isso ia perder (claro, se eu 
gerar o scripts de criação das constrains, isso não seria problema). Quanto aos 
usuários, tem jeito de serem importados antes ou depois, com senha e tudo?

Desde já, agradeço a colaboração de todos.

[]'s
Akira
  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Thursday, July 07, 2005 1:56 PM
  Subject: Re: RES: [oracle_br] Export/Import Lento


  Esses comandos foram bem simples mas também bem ** impróprios ** para 
  performance, pois os defaults do exp/imp nem de longe são os ideais. 
  Antes de falar deles, porém, uma obs : exp/imp full significa que vc 
  vai SERIALIZAR, ie : um único programa vaie ler os objetos UM por UM 
  (o exp), e depois vai gravar (o imp). Se o seu hardware permite 
  (normalmente servidores permitem), não seria *** muito *** mais 
  lógico vc ter vários programas lendo coisas diferentes ao mesmo 
  tempo, e depois vc ter vários gravando ??? Só seria, então pra obter 
  isso é ao invés de ter um único, ter-se ** vários ** exps em 
  paralelo, cada um gravando um schema, ou cada um gravando um grupo de 
  tabelas diferentes, em arquivos .dmp diferentes, e depois vc vai ter 
  vários imps lendo os vários .dmps 

  Quanto aos comandos que ao não informar vc aceitou o default , e que 
  eu recomendo NÂO fazer isso, são : direct=y, buffer (coloque um valor 
  alto mas factível, digamos uns 10 Mb), compress=N (porque senão os 
  extents que o imp cria são gigantescos, demora ** mesmo ** e usa 
  espaço horrivelmente!), recordlength=65535 (todo servidor aceita 
  isso, em tese), STATISTICS=NONE (é muito + rápido se recoletar as 
  stst depois no bd destino via DBMS_STATS)... 
Outro ponto é que o imp faz ** TUDO ** em modo logging e serial, E 
  as constraints são validadas,  pode ser ** muito ** interessante vc 
  não exportar e constraints, depois gera num script o comando de 
  criação dos índices adicionando um NOLOGGING e PARALLEL (se o 
  hardware permite), e script das constraints com a opção ENABLE 
  NOVALIDATE. 

Essas coisas certamente devem melhorar ** enormemente ** a 
  performance, vc acha as sintaxes e refs no manual "Oracle Utilies" e 
  no "SQL reference".

[]s

 Chiappa
 


[As partes desta mensagem que não continham texto foram removidas]



__

Cancelar assinatura...: [EMAIL PROTECTED]
Moderadores da lista:Dorian Anderson Soutto [EMAIL PROTECTED] 
Fernanda Damous [EMAIL PROTECTED] 
Alisson Aguiar [EMAIL PROTECTED]
__
http://br.groups.yahoo.com/group/oracle_br/ 
__

Sair da Lista...: [EMAIL PROTECTED] 
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: RES: [oracle_br] Export/Import Lento

[jlchiappa]

Esses comandos foram bem simples mas também bem ** impróprios ** para 
performance, pois os defaults do exp/imp nem de longe são os ideais. 
Antes de falar deles, porém, uma obs : exp/imp full significa que vc 
vai SERIALIZAR, ie : um único programa vaie ler os objetos UM por UM 
(o exp), e depois vai gravar (o imp). Se o seu hardware permite 
(normalmente servidores permitem), não seria *** muito *** mais 
lógico vc ter vários programas lendo coisas diferentes ao mesmo 
tempo, e depois vc ter vários gravando ??? Só seria, então pra obter 
isso é ao invés de ter um único, ter-se ** vários ** exps em 
paralelo, cada um gravando um schema, ou cada um gravando um grupo de 
tabelas diferentes, em arquivos .dmp diferentes, e depois vc vai ter 
vários imps lendo os vários .dmps 

Quanto aos comandos que ao não informar vc aceitou o default , e que 
eu recomendo NÂO fazer isso, são : direct=y, buffer (coloque um valor 
alto mas factível, digamos uns 10 Mb), compress=N (porque senão os 
extents que o imp cria são gigantescos, demora ** mesmo ** e usa 
espaço horrivelmente!), recordlength=65535 (todo servidor aceita 
isso, em tese), STATISTICS=NONE (é muito + rápido se recoletar as 
stst depois no bd destino via DBMS_STATS)... 
  Outro ponto é que o imp faz ** TUDO ** em modo logging e serial, E 
as constraints são validadas,  pode ser ** muito ** interessante vc 
não exportar e constraints, depois gera num script o comando de 
criação dos índices adicionando um NOLOGGING e PARALLEL (se o 
hardware permite), e script das constraints com a opção ENABLE 
NOVALIDATE. 
  
  Essas coisas certamente devem melhorar ** enormemente ** a 
performance, vc acha as sintaxes e refs no manual "Oracle Utilies" e 
no "SQL reference".
  
  []s
  
   Chiappa
   
> 
>   -Mensagem original- 
>   De: oracle_br@yahoogrupos.com.br em nome de Akira 
>   Enviada: qui 07/07/2005 10:00 
>   Para: oracle_br@yahoogrupos.com.br 
>   Cc: 
>   Assunto: [oracle_br] Export/Import Lento
>   
>   
>   Bom dia!
>   
>   Para fazer uma migração de banco 9.2.0.4 de um servidor 
Windows2003 para um RedHat 8, tive que fazer um export full e um 
import full.
>   O problema é o seguinte, o imp full demora muuuiiito!
>   Alguém sabe algum macete pra fazer isso mais rápido?
>   
>   Esse banco não tem tabelas muito grandes, as maiores não 
tem chegam a 1 millhão de registros e são poucas. Durante o import 
percebi (fiquei mais de 6 horas olhando pra ele) que até tabelas 
vazias demoram bastante tempo. Me parece que o import fica 
recompilando ou verificando consistências num modo bem recursivo, 
mas não sei se é isso mesmo que ele faz. Minhas tabelas são 
normais, tem índices, constraints pks, cks e fks. Tem bastante 
packages, procedures e functions no banco e bastante tabelas também, 
mas tinham poucos dados.
>   
>   Já fiz pela rede, num disco local, no mesmo disco, etc... 
sempre demora. Na primeira vez que precisei fazer, fiquei mais de 10 
horas esperando esse import, mas era um banco muito maior, por isso 
achei que fosse até normal. Nessa última vez foi um banco bem 
pequeno, por isso fiquei indignado. Deve ter alguma forma de fazer 
isso mais rápido e melhor.
>   
>   Os comandos usados foram bem simples: 
>   exp [EMAIL PROTECTED] full=y file=banco.dmp log=banco.log 
>   imp [EMAIL PROTECTED] full=y file=banco.dmp log=banco.log
>   
>   []'s
>   AKIRA
>   
>   [As partes desta mensagem que não continham texto foram 
removidas]
>   
>   
>   
> 
__

>   
>   Cancelar assinatura...: [EMAIL PROTECTED]
>   Moderadores da lista:Dorian Anderson Soutto [EMAIL PROTECTED] 
>   Fernanda Damous [EMAIL PROTECTED] 
>   Alisson Aguiar [EMAIL PROTECTED]
> 
__

>   http://br.groups.yahoo.com/group/oracle_br/ 
> 
__

>   
>   Sair da Lista...: [EMAIL PROTECTED] 
>   
>   
>   
>   _  
> 
>   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 Termos do Serviço do Yahoo! 
 . 
> 
> 
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]




__

Cancelar assinatura...: [EMAIL PROTECTED]
Moderadores da lista:Dorian Anderson Soutto [EMAIL PROTECTED] 
Fernanda Damous [EMAIL PROTECT