Re: [oracle_br] Re: IMPORT/EXPORT 8I/9I - WRAPED PROCEDURES - END COMMUNICATION

[Marcelo Cauduro]

Todo mundo indo para frente e eu querendo para tras !

realmente é desenvolvimento  vou testar o q vc falou !!!

Muito Obrigado !

On 4/3/06, jlchiappa <[EMAIL PROTECTED]> wrote:
>
>  Colega, primeiro de tudo : erros tipo ORA-03113, 0600 e assemelhados
> em princípio significam "chame Suporte", é isso, etão esse é que
> deveria ser o seu procedimento, ponto. Mas já que vc está tentando
> importar em 8i, que há muito tempo perdeu Suporte, imagino que seja
> um banco de teste/desenvolvimento, então vou dar alguns palpites pra
> tentar contornar (já que resolver mesmo erros do tipo, só o Suporte
> Oracle), veja, se te ajudam :
>
> a) primeira coisa, dou como garantido que o .dmp está íntegro (ie,
> não foi feito ftp em modo ascii, não foi editado, enfim), que ele é
> MENOR DO QUE 4 Gb, que é o limite de .dmps no 8i se hardware de 32
> bits, enfim, ele está ok e é válido
>
> b) segunda, também assumo que NÃO há problemas de config de
> hardware/soft - por exemplo como mostrado em
> http://asktom.oracle.com/pls/ask/f?
> p=4950:8:F4950_P8_DISPLAYID:1492331695311 , onde a suspeita era
> ulimit
>
> c) normalmente erros do tipo geram LOGs no servidor, contendo entre
> outras o SQL que causou o erro, vc checou isso ?
>
> ==> Com a, b e c verificados, os procedimentos que te sugeriria são :
>
> 1. tentar usar 9i nesse banco de desenv/teste para onde vc quer
> passar as procs, isso tanto deve ajudar a contornar eventuais bugs
> (nem tão raros assim, em http://asktom.oracle.com/pls/ask/f?
> p=4950:8:F4950_P8_DISPLAYID:1338602652320 por exemplo há um
> exemplo em 8ir2 onde uma simples chamada à package causava 3113)
>
> 2. se não for possível 9i nesse banco :  SE vc encontrou o
> SQL/comando que causava o erro em c , vc pode tentar não exportar
> essa proc, ou pedir que o import a ignore usando ignore=y e antes do
> import criando uma outra proc no bd destino com o mesmo nome . Outra
> opção é pegar o fonte dessas procs, que IMAGINO vc deve ter, e re-
> criá-las no bd destino pelo fonte.
>
> De momento é o que me ocorre.
>
>
> []s
>
>   Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro"
> <[EMAIL PROTECTED]> escreveu
> >
> > Segui as recomendaçoes, foi bem mais rapido...
> > mas deu o erro de novo
> > IMP-3: ORACLE error 3113 encountered
> > ORA-03113: end-of-file on communication channel
> >
> > isso aconteceu em menos de uma hora...
> >
> > outro erro que aconteceu foi de nao conseguir alocar segmentos na
> > tabelespace de rollback... mas para esse acredito que seja
> necessario
> > somente criar mais segmentos de rolllback, certo ?
> >
> > agora nao sei se esse problema de segmento possa ter gerado o de
> cima, mas
> > acho dificil , tb naum sei se uma hora eh pouco para nao perder a
> sessao...
> > nao imagino o que possa ser...
> >
> > On 4/2/06, jlchiappa <[EMAIL PROTECTED]> wrote:
> > >
> > >  As procedures não tem, realmente, params para ser exportadas
> apenas
> > > elas, mas elas SEMPRE vêm ou num exp full=y ou num exp com
> > > owner=(listadeusuarios)- logicamente, vc vai especificar no export
> > > rows=n indexes=n contraints=n triggers=n grants=n
> statistics=none, o
> > > que sobra pra ter no .dmp será mesmo só o DDL das tabelas (que
> como eu
> > > disse em outra msg sempre vêm), os objetos programados(
> > > procedures/functions/packages), e itens que pertencem aos
> usuários mas
> > > não contém dados, como views, sequences, sinônimos
> > > Na hora de importar só não esqueça , claro, do IGNORE=y para que
> os
> > > objetos já existentes no banco mas que ainda assim constam do .dmp
> > > (como as tabelas) tenham a msg de erro correspondente ignorada, e
> o
> > > imp continue depois disso.
> > >
> > >
> > > []s
> > >
> > > Chiappa
> > >
> > > --- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro"
> <[EMAIL PROTECTED]>
> > > escreveu
> > > >
> > > > Vc diz uma sessao de imp criando soh as procedures mas para
> isso eu
> > > > teria de fazer um exp full=y com rows=n para pegar as
> procedures, e
> > > depois
> > > > um imp desse dump ?
> > > >
> > > > Digo isso porque olhando no documento de referencia dos
> utilitarios da
> > > > oracle, vi que as triggers tem um parametros para exporta-las
> > > sozinhas , mas
> > > > para procedure naum vi...
> > > >
> > > > Valeu.
> > > >
> > > > On 4/2/06, jlchiappa <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > >  Eu desconheço incompatibilidade per se entre procedures
> feitas (seja
> > > > > com código wrappado ou não) em 9i serem re-criadas em 8i, no
> máximo o
> > > > > que talvez poderia estar havendo é a procedure 9i estar
> usando algum
> > > > > recurso especial do 9i não reconhecido no 8i, e o import 8i
> por bug ao
> > > > > invés de acusar logo erro fica tentando criar e "se perde",
> mas isso é
> > > > > uma possibilidade remota. O que eu acho mais provável é , em
> o import
> > > > > demorando tantas e tantas horas assim, vc esteja é tendo a
> sessão dele
> > > > > na rede sendo encerrada por firewall ou filtro, 

RES: [oracle_br] Re: IMPORT/EXPORT 8I/9I - WRAPED PROCEDURES - END COMMUNICATION

[rodrigo]

Eu já tive esse tipo de problema também com objetos que passaram pelo WRAP e
não consegui resolver tive que criar eles com os fontes...

-Mensagem original-
De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em
nome de Marcelo Cauduro
Enviada em: domingo, 2 de abril de 2006 16:06
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: [oracle_br] Re: IMPORT/EXPORT 8I/9I - WRAPED PROCEDURES - END
COMMUNICATION

Segui as recomendaçoes, foi bem mais rapido...
mas deu o erro de novo
IMP-3: ORACLE error 3113 encountered
ORA-03113: end-of-file on communication channel

isso aconteceu em menos de uma hora...

outro erro que aconteceu foi de nao conseguir alocar segmentos na
tabelespace de rollback... mas para esse acredito que seja necessario
somente criar mais segmentos de rolllback, certo ?

agora nao sei se esse problema de segmento possa ter gerado o de cima, mas
acho dificil , tb naum sei se uma hora eh pouco para nao perder a sessao...
nao imagino o que possa ser...

On 4/2/06, jlchiappa <[EMAIL PROTECTED]> wrote:
>
>  As procedures não tem, realmente, params para ser exportadas apenas 
> elas, mas elas SEMPRE vêm ou num exp full=y ou num exp com
> owner=(listadeusuarios)- logicamente, vc vai especificar no export 
> rows=n indexes=n contraints=n triggers=n grants=n statistics=none, o 
> que sobra pra ter no .dmp será mesmo só o DDL das tabelas (que como eu 
> disse em outra msg sempre vêm), os objetos programados( 
> procedures/functions/packages), e itens que pertencem aos usuários mas 
> não contém dados, como views, sequences, sinônimos
> Na hora de importar só não esqueça , claro, do IGNORE=y para que os 
> objetos já existentes no banco mas que ainda assim constam do .dmp 
> (como as tabelas) tenham a msg de erro correspondente ignorada, e o 
> imp continue depois disso.
>
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" <[EMAIL PROTECTED]> 
> escreveu
> >
> > Vc diz uma sessao de imp criando soh as procedures mas para isso 
> > eu teria de fazer um exp full=y com rows=n para pegar as procedures, 
> > e
> depois
> > um imp desse dump ?
> >
> > Digo isso porque olhando no documento de referencia dos utilitarios 
> > da oracle, vi que as triggers tem um parametros para exporta-las
> sozinhas , mas
> > para procedure naum vi...
> >
> > Valeu.
> >
> > On 4/2/06, jlchiappa <[EMAIL PROTECTED]> wrote:
> > >
> > >  Eu desconheço incompatibilidade per se entre procedures feitas 
> > > (seja com código wrappado ou não) em 9i serem re-criadas em 8i, no 
> > > máximo o que talvez poderia estar havendo é a procedure 9i estar 
> > > usando algum recurso especial do 9i não reconhecido no 8i, e o 
> > > import 8i por bug ao invés de acusar logo erro fica tentando criar 
> > > e "se perde", mas isso é uma possibilidade remota. O que eu acho 
> > > mais provável é , em o import demorando tantas e tantas horas 
> > > assim, vc esteja é tendo a sessão dele na rede sendo encerrada por 
> > > firewall ou filtro, ou mesmo por configs de seu usuário na 
> > > rede/servidor, então a sugestão é : USE os procedimentos citados 
> > > pra acelerar, na hora de importar tenha vários .dmps sendo 
> > > importados em paralelo, depois crie os índices/constraints 
> > > rapidamente com as opções de performance citadas, e só *** depois 
> > > *** dos dados ok aí sim vc tenha uma sessão de imp criando as 
> > > procedures , pois aí terá menos coisas pro imp fazer, deve demorar 
> > > menos, menos chance de vc ter a conexão de rede  derrubada, que é o
que deve estar havendo, imagino eu.
> > >
> > > []s
> > >
> > > Chiappa
> > >
> > > --- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" 
> > > <[EMAIL PROTECTED]> escreveu
> > >
> > > >
> > > > Tinha uma base no 9i (linux) e queria exportar ela para o 8i
> (windows) ,
> > > > então conectei
> > > > no 9i pelo 8i e fiz um export full. Deu certo !!
> > > > Sem warnings !!!
> > > >
> > > > Dai criei as tablespaces (deu um grep [existe tb] pelo windows)...
> > > > tudo ok...
> > > >
> > > > comecei o import depois de horas (naum segui os conselhos 
> > > > para acelerar)..
> > > > deu um erro...
> > > > falou de "end of comunication" do arquivo.
> > > > Parou .
> > > >
> > > > Alguem tem ideia do pq ??
> > > >
> > > > Notem, deu erro na parte de import das procedures, e quando
> par

[oracle_br] Re: IMPORT/EXPORT 8I/9I - WRAPED PROCEDURES - END COMMUNICATION

[jlchiappa]

Ah, sobre o erro de rollback : imagino que foi "unable to extend", e 
não "snapshot too old", certo ? Se sim, não é só aumentar segmentos, 
é aumentar o TAMANHO da tablespace. Coloque essa tablespace de UNDO 
em Gbs (e não em Mbs), tenha ela como LMT, tenha segmentos de 
rollback de tamanho uniforme de 1 Mb, ou próximo a isso, e tenha 
diversos segtos , nunca um ou dois ou três só, isso deve ajudar muito 
a resolver eventuais erros de rollback.
 E é claro, erros do tipo numa sessão que faz DDLs e uns poucos 
SELECTs (e algum SQL recursivo) como é o caso do imp num .dmp com 
rows=n, normalmente implicam que OUTRAs sessões estão/estavam ativas, 
experimente fazer o import sem nada rodando...

[]s

 Chiappa

--- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> 
escreveu
>
> Colega, primeiro de tudo : erros tipo ORA-03113, 0600 e 
assemelhados 
> em princípio significam "chame Suporte", é isso, etão esse é que 
> deveria ser o seu procedimento, ponto. Mas já que vc está tentando 
> importar em 8i, que há muito tempo perdeu Suporte, imagino que seja 
> um banco de teste/desenvolvimento, então vou dar alguns palpites 
pra 
> tentar contornar (já que resolver mesmo erros do tipo, só o Suporte 
> Oracle), veja, se te ajudam :
> 
>  a) primeira coisa, dou como garantido que o .dmp está íntegro (ie, 
> não foi feito ftp em modo ascii, não foi editado, enfim), que ele é 
> MENOR DO QUE 4 Gb, que é o limite de .dmps no 8i se hardware de 32 
> bits, enfim, ele está ok e é válido
>  
>  b) segunda, também assumo que NÃO há problemas de config de 
> hardware/soft - por exemplo como mostrado em 
> http://asktom.oracle.com/pls/ask/f?
> p=4950:8:F4950_P8_DISPLAYID:1492331695311 , onde a suspeita era 
> ulimit
>  
>  c) normalmente erros do tipo geram LOGs no servidor, contendo 
entre 
> outras o SQL que causou o erro, vc checou isso ?
>  
>  ==> Com a, b e c verificados, os procedimentos que te sugeriria 
são :
>  
>  1. tentar usar 9i nesse banco de desenv/teste para onde vc quer 
> passar as procs, isso tanto deve ajudar a contornar eventuais bugs 
> (nem tão raros assim, em http://asktom.oracle.com/pls/ask/f?
> p=4950:8:F4950_P8_DISPLAYID:1338602652320 por exemplo há um 
> exemplo em 8ir2 onde uma simples chamada à package causava 3113) 
>  
>  2. se não for possível 9i nesse banco :  SE vc encontrou o 
> SQL/comando que causava o erro em c , vc pode tentar não exportar 
> essa proc, ou pedir que o import a ignore usando ignore=y e antes 
do 
> import criando uma outra proc no bd destino com o mesmo nome . 
Outra 
> opção é pegar o fonte dessas procs, que IMAGINO vc deve ter, e re-
> criá-las no bd destino pelo fonte. 
>  
>  De momento é o que me ocorre.
>  
>  []s
>  
>   Chiappa
>   
> --- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" 
> <[EMAIL PROTECTED]> escreveu
> >
> > Segui as recomendaçoes, foi bem mais rapido...
> > mas deu o erro de novo
> > IMP-3: ORACLE error 3113 encountered
> > ORA-03113: end-of-file on communication channel
> > 
> > isso aconteceu em menos de uma hora...
> > 
> > outro erro que aconteceu foi de nao conseguir alocar segmentos na
> > tabelespace de rollback... mas para esse acredito que seja 
> necessario
> > somente criar mais segmentos de rolllback, certo ?
> > 
> > agora nao sei se esse problema de segmento possa ter gerado o de 
> cima, mas
> > acho dificil , tb naum sei se uma hora eh pouco para nao perder a 
> sessao...
> > nao imagino o que possa ser...
> > 
> > On 4/2/06, jlchiappa <[EMAIL PROTECTED]> wrote:
> > >
> > >  As procedures não tem, realmente, params para ser exportadas 
> apenas
> > > elas, mas elas SEMPRE vêm ou num exp full=y ou num exp com
> > > owner=(listadeusuarios)- logicamente, vc vai especificar no 
export
> > > rows=n indexes=n contraints=n triggers=n grants=n 
> statistics=none, o
> > > que sobra pra ter no .dmp será mesmo só o DDL das tabelas (que 
> como eu
> > > disse em outra msg sempre vêm), os objetos programados(
> > > procedures/functions/packages), e itens que pertencem aos 
> usuários mas
> > > não contém dados, como views, sequences, sinônimos
> > > Na hora de importar só não esqueça , claro, do IGNORE=y para 
que 
> os
> > > objetos já existentes no banco mas que ainda assim constam 
do .dmp
> > > (como as tabelas) tenham a msg de erro correspondente ignorada, 
e 
> o
> > > imp continue depois disso.
> > >
> > >
> > > []s
> > >
> > > Chiappa
> > >
> > > --- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" 
> <[EMAIL PROTECTED]>
> > > escreveu
> > > >
> > > > Vc diz uma sessao de imp criando soh as procedures mas 
para 
> isso eu
> > > > teria de fazer um exp full=y com rows=n para pegar as 
> procedures, e
> > > depois
> > > > um imp desse dump ?
> > > >
> > > > Digo isso porque olhando no documento de referencia dos 
> utilitarios da
> > > > oracle, vi que as triggers tem um parametros para exporta-las
> > > sozinhas , mas
> > > > para procedure naum vi...
> > > >
> > > > Valeu.
> > > >
> > > > On 4/2/06

[oracle_br] Re: IMPORT/EXPORT 8I/9I - WRAPED PROCEDURES - END COMMUNICATION

[jlchiappa]

Colega, primeiro de tudo : erros tipo ORA-03113, 0600 e assemelhados 
em princípio significam "chame Suporte", é isso, etão esse é que 
deveria ser o seu procedimento, ponto. Mas já que vc está tentando 
importar em 8i, que há muito tempo perdeu Suporte, imagino que seja 
um banco de teste/desenvolvimento, então vou dar alguns palpites pra 
tentar contornar (já que resolver mesmo erros do tipo, só o Suporte 
Oracle), veja, se te ajudam :

 a) primeira coisa, dou como garantido que o .dmp está íntegro (ie, 
não foi feito ftp em modo ascii, não foi editado, enfim), que ele é 
MENOR DO QUE 4 Gb, que é o limite de .dmps no 8i se hardware de 32 
bits, enfim, ele está ok e é válido
 
 b) segunda, também assumo que NÃO há problemas de config de 
hardware/soft - por exemplo como mostrado em 
http://asktom.oracle.com/pls/ask/f?
p=4950:8:F4950_P8_DISPLAYID:1492331695311 , onde a suspeita era 
ulimit
 
 c) normalmente erros do tipo geram LOGs no servidor, contendo entre 
outras o SQL que causou o erro, vc checou isso ?
 
 ==> Com a, b e c verificados, os procedimentos que te sugeriria são :
 
 1. tentar usar 9i nesse banco de desenv/teste para onde vc quer 
passar as procs, isso tanto deve ajudar a contornar eventuais bugs 
(nem tão raros assim, em http://asktom.oracle.com/pls/ask/f?
p=4950:8:F4950_P8_DISPLAYID:1338602652320 por exemplo há um 
exemplo em 8ir2 onde uma simples chamada à package causava 3113) 
 
 2. se não for possível 9i nesse banco :  SE vc encontrou o 
SQL/comando que causava o erro em c , vc pode tentar não exportar 
essa proc, ou pedir que o import a ignore usando ignore=y e antes do 
import criando uma outra proc no bd destino com o mesmo nome . Outra 
opção é pegar o fonte dessas procs, que IMAGINO vc deve ter, e re-
criá-las no bd destino pelo fonte. 
 
 De momento é o que me ocorre.
 
 []s
 
  Chiappa
  
--- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" 
<[EMAIL PROTECTED]> escreveu
>
> Segui as recomendaçoes, foi bem mais rapido...
> mas deu o erro de novo
> IMP-3: ORACLE error 3113 encountered
> ORA-03113: end-of-file on communication channel
> 
> isso aconteceu em menos de uma hora...
> 
> outro erro que aconteceu foi de nao conseguir alocar segmentos na
> tabelespace de rollback... mas para esse acredito que seja 
necessario
> somente criar mais segmentos de rolllback, certo ?
> 
> agora nao sei se esse problema de segmento possa ter gerado o de 
cima, mas
> acho dificil , tb naum sei se uma hora eh pouco para nao perder a 
sessao...
> nao imagino o que possa ser...
> 
> On 4/2/06, jlchiappa <[EMAIL PROTECTED]> wrote:
> >
> >  As procedures não tem, realmente, params para ser exportadas 
apenas
> > elas, mas elas SEMPRE vêm ou num exp full=y ou num exp com
> > owner=(listadeusuarios)- logicamente, vc vai especificar no export
> > rows=n indexes=n contraints=n triggers=n grants=n 
statistics=none, o
> > que sobra pra ter no .dmp será mesmo só o DDL das tabelas (que 
como eu
> > disse em outra msg sempre vêm), os objetos programados(
> > procedures/functions/packages), e itens que pertencem aos 
usuários mas
> > não contém dados, como views, sequences, sinônimos
> > Na hora de importar só não esqueça , claro, do IGNORE=y para que 
os
> > objetos já existentes no banco mas que ainda assim constam do .dmp
> > (como as tabelas) tenham a msg de erro correspondente ignorada, e 
o
> > imp continue depois disso.
> >
> >
> > []s
> >
> > Chiappa
> >
> > --- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" 
<[EMAIL PROTECTED]>
> > escreveu
> > >
> > > Vc diz uma sessao de imp criando soh as procedures mas para 
isso eu
> > > teria de fazer um exp full=y com rows=n para pegar as 
procedures, e
> > depois
> > > um imp desse dump ?
> > >
> > > Digo isso porque olhando no documento de referencia dos 
utilitarios da
> > > oracle, vi que as triggers tem um parametros para exporta-las
> > sozinhas , mas
> > > para procedure naum vi...
> > >
> > > Valeu.
> > >
> > > On 4/2/06, jlchiappa <[EMAIL PROTECTED]> wrote:
> > > >
> > > >  Eu desconheço incompatibilidade per se entre procedures 
feitas (seja
> > > > com código wrappado ou não) em 9i serem re-criadas em 8i, no 
máximo o
> > > > que talvez poderia estar havendo é a procedure 9i estar 
usando algum
> > > > recurso especial do 9i não reconhecido no 8i, e o import 8i 
por bug ao
> > > > invés de acusar logo erro fica tentando criar e "se perde", 
mas isso é
> > > > uma possibilidade remota. O que eu acho mais provável é , em 
o import
> > > > demorando tantas e tantas horas assim, vc esteja é tendo a 
sessão dele
> > > > na rede sendo encerrada por firewall ou filtro, ou mesmo por 
configs
> > > > de seu usuário na rede/servidor, então a sugestão é : USE os
> > > > procedimentos citados pra acelerar, na hora de importar tenha 
vários
> > > > .dmps sendo importados em paralelo, depois crie os 
índices/constraints
> > > > rapidamente com as opções de performance citadas, e só *** 
depois ***
> > > > dos dados ok aí sim vc tenha uma 

Re: [oracle_br] Re: IMPORT/EXPORT 8I/9I - WRAPED PROCEDURES - END COMMUNICATION

[Marcelo Cauduro]

Segui as recomendaçoes, foi bem mais rapido...
mas deu o erro de novo
IMP-3: ORACLE error 3113 encountered
ORA-03113: end-of-file on communication channel

isso aconteceu em menos de uma hora...

outro erro que aconteceu foi de nao conseguir alocar segmentos na
tabelespace de rollback... mas para esse acredito que seja necessario
somente criar mais segmentos de rolllback, certo ?

agora nao sei se esse problema de segmento possa ter gerado o de cima, mas
acho dificil , tb naum sei se uma hora eh pouco para nao perder a sessao...
nao imagino o que possa ser...

On 4/2/06, jlchiappa <[EMAIL PROTECTED]> wrote:
>
>  As procedures não tem, realmente, params para ser exportadas apenas
> elas, mas elas SEMPRE vêm ou num exp full=y ou num exp com
> owner=(listadeusuarios)- logicamente, vc vai especificar no export
> rows=n indexes=n contraints=n triggers=n grants=n statistics=none, o
> que sobra pra ter no .dmp será mesmo só o DDL das tabelas (que como eu
> disse em outra msg sempre vêm), os objetos programados(
> procedures/functions/packages), e itens que pertencem aos usuários mas
> não contém dados, como views, sequences, sinônimos
> Na hora de importar só não esqueça , claro, do IGNORE=y para que os
> objetos já existentes no banco mas que ainda assim constam do .dmp
> (como as tabelas) tenham a msg de erro correspondente ignorada, e o
> imp continue depois disso.
>
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" <[EMAIL PROTECTED]>
> escreveu
> >
> > Vc diz uma sessao de imp criando soh as procedures mas para isso eu
> > teria de fazer um exp full=y com rows=n para pegar as procedures, e
> depois
> > um imp desse dump ?
> >
> > Digo isso porque olhando no documento de referencia dos utilitarios da
> > oracle, vi que as triggers tem um parametros para exporta-las
> sozinhas , mas
> > para procedure naum vi...
> >
> > Valeu.
> >
> > On 4/2/06, jlchiappa <[EMAIL PROTECTED]> wrote:
> > >
> > >  Eu desconheço incompatibilidade per se entre procedures feitas (seja
> > > com código wrappado ou não) em 9i serem re-criadas em 8i, no máximo o
> > > que talvez poderia estar havendo é a procedure 9i estar usando algum
> > > recurso especial do 9i não reconhecido no 8i, e o import 8i por bug ao
> > > invés de acusar logo erro fica tentando criar e "se perde", mas isso é
> > > uma possibilidade remota. O que eu acho mais provável é , em o import
> > > demorando tantas e tantas horas assim, vc esteja é tendo a sessão dele
> > > na rede sendo encerrada por firewall ou filtro, ou mesmo por configs
> > > de seu usuário na rede/servidor, então a sugestão é : USE os
> > > procedimentos citados pra acelerar, na hora de importar tenha vários
> > > .dmps sendo importados em paralelo, depois crie os índices/constraints
> > > rapidamente com as opções de performance citadas, e só *** depois ***
> > > dos dados ok aí sim vc tenha uma sessão de imp criando as procedures ,
> > > pois aí terá menos coisas pro imp fazer, deve demorar menos, menos
> > > chance de vc ter a conexão de rede  derrubada, que é o que deve estar
> > > havendo, imagino eu.
> > >
> > > []s
> > >
> > > Chiappa
> > >
> > > --- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" <[EMAIL PROTECTED]>
> > > escreveu
> > >
> > > >
> > > > Tinha uma base no 9i (linux) e queria exportar ela para o 8i
> (windows) ,
> > > > então conectei
> > > > no 9i pelo 8i e fiz um export full. Deu certo !!
> > > > Sem warnings !!!
> > > >
> > > > Dai criei as tablespaces (deu um grep [existe tb] pelo windows)...
> > > > tudo ok...
> > > >
> > > > comecei o import depois de horas (naum segui os conselhos para
> > > > acelerar)..
> > > > deu um erro...
> > > > falou de "end of comunication" do arquivo.
> > > > Parou .
> > > >
> > > > Alguem tem ideia do pq ??
> > > >
> > > > Notem, deu erro na parte de import das procedures, e quando
> parou estava
> > > > importando um
> > > > wraped procedure. Será que é isso ? Uma incompatibilidade ^?
> > > >
> > > > O que posso fazer ?
> > > >
> > > > Foi essa a minha maneira de transferir os dados a melhor ? (sem
> contar o
> > > > tempo...
> > > > afinal poderia ter usado indexfile... :-) )
> > > >
> > > >
> > > > [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/
> > >
> > >
>
> --__
> > >
> > > Este Grupo recebe o apoio da SQL Magazine -
> > > www.devmedia.com.br/sqlmagazine
> > > __

[oracle_br] Re: IMPORT/EXPORT 8I/9I - WRAPED PROCEDURES - END COMMUNICATION

[jlchiappa]

As procedures não tem, realmente, params para ser exportadas apenas
elas, mas elas SEMPRE vêm ou num exp full=y ou num exp com
owner=(listadeusuarios)- logicamente, vc vai especificar no export
rows=n indexes=n contraints=n triggers=n grants=n statistics=none, o
que sobra pra ter no .dmp será mesmo só o DDL das tabelas (que como eu
disse em outra msg sempre vêm), os objetos programados(
procedures/functions/packages), e itens que pertencem aos usuários mas
não contém dados, como views, sequences, sinônimos 
 Na hora de importar só não esqueça , claro, do IGNORE=y para que os
objetos já existentes no banco mas que ainda assim constam do .dmp
(como as tabelas) tenham a msg de erro correspondente ignorada, e o
imp continue depois disso.

[]s

 Chiappa

--- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" <[EMAIL PROTECTED]>
escreveu
>
> Vc diz uma sessao de imp criando soh as procedures mas para isso eu
> teria de fazer um exp full=y com rows=n para pegar as procedures, e
depois
> um imp desse dump ?
> 
> Digo isso porque olhando no documento de referencia dos utilitarios da
> oracle, vi que as triggers tem um parametros para exporta-las
sozinhas , mas
> para procedure naum vi...
> 
> Valeu.
> 
> On 4/2/06, jlchiappa <[EMAIL PROTECTED]> wrote:
> >
> >  Eu desconheço incompatibilidade per se entre procedures feitas (seja
> > com código wrappado ou não) em 9i serem re-criadas em 8i, no máximo o
> > que talvez poderia estar havendo é a procedure 9i estar usando algum
> > recurso especial do 9i não reconhecido no 8i, e o import 8i por bug ao
> > invés de acusar logo erro fica tentando criar e "se perde", mas isso é
> > uma possibilidade remota. O que eu acho mais provável é , em o import
> > demorando tantas e tantas horas assim, vc esteja é tendo a sessão dele
> > na rede sendo encerrada por firewall ou filtro, ou mesmo por configs
> > de seu usuário na rede/servidor, então a sugestão é : USE os
> > procedimentos citados pra acelerar, na hora de importar tenha vários
> > .dmps sendo importados em paralelo, depois crie os índices/constraints
> > rapidamente com as opções de performance citadas, e só *** depois ***
> > dos dados ok aí sim vc tenha uma sessão de imp criando as procedures ,
> > pois aí terá menos coisas pro imp fazer, deve demorar menos, menos
> > chance de vc ter a conexão de rede  derrubada, que é o que deve estar
> > havendo, imagino eu.
> >
> > []s
> >
> > Chiappa
> >
> > --- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" <[EMAIL PROTECTED]>
> > escreveu
> >
> > >
> > > Tinha uma base no 9i (linux) e queria exportar ela para o 8i
(windows) ,
> > > então conectei
> > > no 9i pelo 8i e fiz um export full. Deu certo !!
> > > Sem warnings !!!
> > >
> > > Dai criei as tablespaces (deu um grep [existe tb] pelo windows)...
> > > tudo ok...
> > >
> > > comecei o import depois de horas (naum segui os conselhos para
> > > acelerar)..
> > > deu um erro...
> > > falou de "end of comunication" do arquivo.
> > > Parou .
> > >
> > > Alguem tem ideia do pq ??
> > >
> > > Notem, deu erro na parte de import das procedures, e quando
parou estava
> > > importando um
> > > wraped procedure. Será que é isso ? Uma incompatibilidade ^?
> > >
> > > O que posso fazer ?
> > >
> > > Foi essa a minha maneira de transferir os dados a melhor ? (sem
contar o
> > > tempo...
> > > afinal poderia ter usado indexfile... :-) )
> > >
> > >
> > > [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/
> >
> >
--__
> >
> > Este Grupo recebe o apoio da SQL Magazine -
> > www.devmedia.com.br/sqlmagazine
> > __
> > O grupo Oracle_br não aceita anexos. Quando oferecer algum
arquivo, tenha
> > o link do mesmo para evitar trafego(pedidos) desnecessário.
> >
> >
> >  *Yahoo! Grupos, um serviço oferecido por:*  PUBLICIDADE
> >
> >

> > --
> > *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]<[EMAIL PROTECTED]>
> >
> >- O uso que você faz do Yahoo! Grupos está sujeito aos Termos do
> >Serviço do Yahoo! 

Re: [oracle_br] Re: IMPORT/EXPORT 8I/9I - WRAPED PROCEDURES - END COMMUNICATION

[Marcelo Cauduro]

Vc diz uma sessao de imp criando soh as procedures mas para isso eu
teria de fazer um exp full=y com rows=n para pegar as procedures, e depois
um imp desse dump ?

Digo isso porque olhando no documento de referencia dos utilitarios da
oracle, vi que as triggers tem um parametros para exporta-las sozinhas , mas
para procedure naum vi...

Valeu.

On 4/2/06, jlchiappa <[EMAIL PROTECTED]> wrote:
>
>  Eu desconheço incompatibilidade per se entre procedures feitas (seja
> com código wrappado ou não) em 9i serem re-criadas em 8i, no máximo o
> que talvez poderia estar havendo é a procedure 9i estar usando algum
> recurso especial do 9i não reconhecido no 8i, e o import 8i por bug ao
> invés de acusar logo erro fica tentando criar e "se perde", mas isso é
> uma possibilidade remota. O que eu acho mais provável é , em o import
> demorando tantas e tantas horas assim, vc esteja é tendo a sessão dele
> na rede sendo encerrada por firewall ou filtro, ou mesmo por configs
> de seu usuário na rede/servidor, então a sugestão é : USE os
> procedimentos citados pra acelerar, na hora de importar tenha vários
> .dmps sendo importados em paralelo, depois crie os índices/constraints
> rapidamente com as opções de performance citadas, e só *** depois ***
> dos dados ok aí sim vc tenha uma sessão de imp criando as procedures ,
> pois aí terá menos coisas pro imp fazer, deve demorar menos, menos
> chance de vc ter a conexão de rede  derrubada, que é o que deve estar
> havendo, imagino eu.
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" <[EMAIL PROTECTED]>
> escreveu
>
> >
> > Tinha uma base no 9i (linux) e queria exportar ela para o 8i (windows) ,
> > então conectei
> > no 9i pelo 8i e fiz um export full. Deu certo !!
> > Sem warnings !!!
> >
> > Dai criei as tablespaces (deu um grep [existe tb] pelo windows)...
> > tudo ok...
> >
> > comecei o import depois de horas (naum segui os conselhos para
> > acelerar)..
> > deu um erro...
> > falou de "end of comunication" do arquivo.
> > Parou .
> >
> > Alguem tem ideia do pq ??
> >
> > Notem, deu erro na parte de import das procedures, e quando parou estava
> > importando um
> > wraped procedure. Será que é isso ? Uma incompatibilidade ^?
> >
> > O que posso fazer ?
> >
> > Foi essa a minha maneira de transferir os dados a melhor ? (sem contar o
> > tempo...
> > afinal poderia ter usado indexfile... :-) )
> >
> >
> > [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/
>
> --__
>
> Este Grupo recebe o apoio da SQL Magazine -
> www.devmedia.com.br/sqlmagazine
> __
> O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha
> o link do mesmo para evitar trafego(pedidos) desnecessário.
>
>
>  *Yahoo! Grupos, um serviço oferecido por:*  PUBLICIDADE
>
> 
> --
> *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]<[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]



--
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/ 
--__

Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine 
__
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o 
link do mesmo para evitar trafego(pedidos) desnecessário. 
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 

[oracle_br] Re: IMPORT/EXPORT 8I/9I - WRAPED PROCEDURES - END COMMUNICATION

[jlchiappa]

Eu desconheço incompatibilidade per se entre procedures feitas (seja
com código wrappado ou não) em 9i serem re-criadas em 8i, no máximo o
que talvez poderia estar havendo é a procedure 9i estar usando algum
recurso especial do 9i não reconhecido no 8i, e o import 8i por bug ao
invés de acusar logo erro fica tentando criar e "se perde", mas isso é
uma possibilidade remota. O que eu acho mais provável é , em o import
demorando tantas e tantas horas assim, vc esteja é tendo a sessão dele
na rede sendo encerrada por firewall ou filtro, ou mesmo por configs
de seu usuário na rede/servidor, então a sugestão é : USE os
procedimentos citados pra acelerar, na hora de importar tenha vários
.dmps sendo importados em paralelo, depois crie os índices/constraints
rapidamente com as opções de performance citadas, e só *** depois ***
dos dados ok aí sim vc tenha uma sessão de imp criando as procedures ,
pois aí terá menos coisas pro imp fazer, deve demorar menos, menos
chance de vc ter a conexão de rede  derrubada, que é o que deve estar
havendo, imagino eu.

[]s

 Chiappa

--- Em oracle_br@yahoogrupos.com.br, "Marcelo Cauduro" <[EMAIL PROTECTED]>
escreveu
>
> Tinha uma base no 9i (linux) e queria exportar ela para o 8i (windows) ,
> então conectei
> no 9i pelo 8i e fiz um export full. Deu certo !!
> Sem warnings !!!
> 
> Dai criei as tablespaces (deu um grep [existe tb] pelo windows)...
> tudo ok...
> 
> comecei o import depois de horas (naum segui os conselhos para
> acelerar)..
> deu um erro...
> falou de "end of comunication" do arquivo.
> Parou .
> 
> Alguem tem ideia do pq ??
> 
> Notem, deu erro na parte de import das procedures, e quando parou estava
> importando um
> wraped procedure. Será que é isso ? Uma incompatibilidade ^?
> 
> O que posso fazer ?
> 
> Foi essa a minha maneira de transferir os dados a melhor ? (sem contar o
> tempo...
> afinal poderia ter usado indexfile... :-) )
> 
> 
> [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/ 
--__

Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine 
__
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o 
link do mesmo para evitar trafego(pedidos) desnecessário. 
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