Re: [oracle_br] Re: Migração Oracle 8.

[Daniel Mello]

Show de bola Chiappa.

Realmente não havia pensado na hipótese de criar dblink, criar faixas de 
execuções (no meu caso são poucas tabelas, porém gigantes) e disparar sessões 
em paralelo consumindo as faixas previamente criadas. 
Com insert + append e bulk collect imagino que a performance realmente será 
melhor do que exp/imp. Vou começar a testar para encontrar o melhor equilíbrio 
de "faixas x sessões" que meu hardware irá suportar. De qualquer forma respondo 
pra vocês qual foi a melhor alternativa pro meu cenário.

Muito obrigado.
Daniel.
 



Em Terça-feira, 29 de Outubro de 2013 18:30, J. Laurindo Chiappa 
 escreveu:
 
Sim, é isso mesmo... Apenas friso que :

a. sem a menor dúvida o procedimento de conversão/upgrade do banco que já 
existe vai ser Pelo Menos umas 3x mais rápido do criar banco vazio e 
transferir/exportar dados para ele, mas para saber exatamente o quanto mais, 
PLZ faça uma comparação ** JUSTA ** , usando os procedimentos Corretos - mandar 
um exp e um imp full com tudo default é Óbvio que vai demorar uma imensidão...
  Dá uma olhada nas msgs arquivadas do Grupo sobre o assunto, mas PELO MENOS vc 
deveria :
  
    1. para as relativamente poucas tabelas Realmente gigantes que normalmente 
se tem num database , ao invés de exp+imp tente um INSERT /*+ APPEND */ via 
dblink, em paralelo
    
    2. vc vai exportar APENAS e TÃO SOMENTE dados : índices, constraints, 
estatísticas, grants, triggers e quetais vc só extrai o DDL, altera-o para 
permitir paralelismo/novalidate/nologging e só DEPOIS dos dados todos 
importados/inseridos vc os cria... 
     Teste também o quanto melhora a performance da importação vc pré-criar 
antes as tablespaces/tabelas usando apenas tablespaces LMT, segmentos ASSM, 
initial/next/pctincrease controlado default pela tablespace, PCTFREE/PCTUSED 
otimizado para INSERTs (sem reservar espaço, ou reservando o mínimo para 
UPDATEs)...
    
    3. vc vai ter múltiplas sessões de exportação e depois múltiplas de 
importação, em paralelo : quantas vai depender do seu hardware, mas teus testes 
vão indicar isso, fatalmente vc aumentando sessões simultâneas chega 
rapidamente uma hora que o retorno é negativo
    
    4. se forem servidores diferentes, vc vai testar mas via de regra é mais 
performático vc gerar os arquivos de export localmente primeiro e só depois os 
transferir para o servidor-destino via ftp ou qquer coisa assim do que os gerar 
diretamente no servidor-destino via rede
    
    5. as OPÇÕES , principalmente para a exportação , NUNCA devem ser default : 
se vc for usar exp tradicional (provável, já que 8i não aceita expdp/datapump), 
assegure-se de ao menos incluir (em todas as sessões) DIRECT=Y 
BUFFER=algunsmbytesnúmerograndemasquevcteemRAM RECORDLENGTH=65535 
STATISTICS=NONE RECORD=N COMPRESS=N 
    
b . Não deixe de aproveitar essas migrações-teste para TESTAR também a 
Aplicação contra o banco mais recente : não é de jeito nenhum impossível vc ter 
alterações até radicais de comportamento/performance no novo release do RDBMS, 
que podem demandar upgrade também do middleware, e/ou ajustes em SQLs, ou 
coisas assim...

   []s
  
     Chiappa

--- Em oracle_br@yahoogrupos.com.br, Daniel Mello  escreveu
>
> Muito obrigado a todos pela ajuda.
> Pra eu encontrar a média de tempo para janela de migração, terei que 
> ensaia-la algumas vezes, vou tentar todas as alternativas para escolher a que 
> se sair melhor.
> 
> Agradecido.
> Daniel.
> 
> 
> 
> Em Segunda-feira, 28 de Outubro de 2013 18:13, J. Laurindo Chiappa 
>  escreveu:
>  
>   Tudo jóia, Daniel ? Deixe-me aproveitar e esclarecer um pouco o assunto, 
> para vc poder fazer uma análise mais criteriosa aí das suas opções e tomar 
> uma decisão mais informada 
>   
>   1. Quando a gente fala em database , no mundo Oracle, a gente está se 
> referendo aos arquivos em disco que contém dados e metadados (ie, datafiles, 
> tempfiles, controlfiles, etc), arquivos esses que são abertos/controlados 
> pelo software RDBMS Oracle, formando a instância Oracle...
>    Para podermos passar a utilizar uma versão mais recente do RDBMS Oracle (o 
> software), vc primeiro precisa (tirando um BACKUP COMPLETO antes, óbvio :) 
> instalar a nova versão do software no servidor em questão (no mesmo 
> diretório/oracle home ou em um diferente, embora o mais recomnendado seja num 
> HOME novo), E depois aí sim : ** OU ** vc cria um database vazio com esses 
> binários da nova versão e transporta/transfere os dados do banco velho para o 
> novo banco vazio, ** OU ** vc CONVERTE esse database (esse conjunto todo de 
> arquivos de dados e metadados) já existente para poder ser aberto e usado 
> pela nova versão de RDBMS...
>    Ambos os procedimentos tem vantagens e desvantagens : para a opção de 
> transferir os dados para um novo database, a Vantagem principal é que, como 
> vc criou um database vazio, com tablespaces novas, tudo novo, vc Obviamente 
> usou/vai usar as features de armazenamento e controle introduzida

Re: [oracle_br] Re: Migração Oracle 8.

[Roland Martins]

Talvez você já tenha ido atrás, mas não custa mencionar:
Master Note For Oracle Database Upgrades and Migrations (Doc ID 1152016.1)




Em Terça-feira, 29 de Outubro de 2013 15:30, Daniel Mello 
 escreveu:
 
  
Muito obrigado a todos pela ajuda.
Pra eu encontrar a média de tempo para janela de migração, terei que ensaia-la 
algumas vezes, vou tentar todas as alternativas para escolher a que se sair 
melhor.

Agradecido.
Daniel.



Em Segunda-feira, 28 de Outubro de 2013 18:13, J. Laurindo Chiappa 
 escreveu:
 
  Tudo jóia, Daniel ? Deixe-me aproveitar e esclarecer um pouco o assunto, para 
vc poder fazer uma análise mais criteriosa aí das suas opções e tomar uma 
decisão mais informada 
  
  1. Quando a gente fala em database , no mundo Oracle, a gente está se 
referendo aos arquivos em disco que contém dados e metadados (ie, datafiles, 
tempfiles, controlfiles, etc), arquivos esses que são abertos/controlados pelo 
software RDBMS Oracle, formando a instância Oracle...
   Para podermos passar a utilizar uma versão mais
 recente do RDBMS Oracle (o software), vc primeiro precisa (tirando um BACKUP 
COMPLETO antes, óbvio :) instalar a nova versão do software no servidor em 
questão (no mesmo diretório/oracle home ou em um diferente, embora o mais 
recomnendado seja num HOME novo), E depois aí sim : ** OU ** vc cria um 
database vazio com esses binários da nova versão e transporta/transfere os 
dados do banco velho para o novo banco vazio, ** OU ** vc CONVERTE esse 
database (esse conjunto todo de arquivos de dados e metadados) já existente 
para poder ser aberto e usado pela nova versão de RDBMS...
   Ambos os procedimentos tem vantagens e desvantagens : para a opção de 
transferir os dados para um novo database, a Vantagem principal é que, como vc 
criou um database vazio, com tablespaces novas, tudo novo, vc Obviamente 
usou/vai usar as features de armazenamento e controle introduzidas pelo novo 
RDBMS que te sejam úteis e que vc não usava na
 antiga, como (digamos) ASSM, undo automático , tablespace SYSTEM criada como 
LMT, etc, etc... A Desvantagem é que realmente criar E transferir os dados 
demora Muito Mais do que só a conversão, que é relativamente simples e rápida.. 
Vice-versa as vantagens/desvantagens de usar a conversão...
  
  2. Rigorosamente NÃO É só o tamanho do teu database que vai ser o seu único 
guia, mas sim TAMBÉM o tamanho da tua janela de manutenção : Lógico que se vc 
tiver, digamos, os dois dias do fim de semana para fazer o upgrade E as 
vantagens de recriar o database são atrativas para vc, Não Tem porque deixar de 
considerar as técnicas de export/transferência de dados do database velho para 
um novo recém criado vazio...
  
  3. A sua performance NECESSARIAMENTE vai variar grandemente dependendo do teu 
hardware, Óbvio, mas tipicamente em hardware de Produção eu vi
 conversão de database de 500 GB demorar coisa de 4 ou 5 horas, e 
transporte/export de dados (USANDO as técnicas corretas/adequadas. como 
Paralelismo, múltiplas instâncias, não-validação de constraints, etc, etc) para 
esses mesmos 500 GB levar coisa de umas 15 horas

   []s
      
        Chiappa


--- Em oracle_br@yahoogrupos.com.br, Daniel Mello  escreveu
>
> Boa tarde pessoal.
> 
>    Por favor, tenho um banco para migrar e por ele ser uma versão antiga, a 
> 8i (vai para a 11g),
 não sei ao certo qual estratégia usar, levando em consideração seu tamanho, 
aproximadamente 500gb, pensei em expdp, mas acredito que o tempo será mto alto 
para esse cenário. Alguém já fez algo semelhante?
> 
> Obrigado.
> Daniel.
>






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

Re: [oracle_br] Re: Migração Oracle 8.

[Daniel Mello]

Muito obrigado a todos pela ajuda.
Pra eu encontrar a média de tempo para janela de migração, terei que ensaia-la 
algumas vezes, vou tentar todas as alternativas para escolher a que se sair 
melhor.

Agradecido.
Daniel.



Em Segunda-feira, 28 de Outubro de 2013 18:13, J. Laurindo Chiappa 
 escreveu:
 
  Tudo jóia, Daniel ? Deixe-me aproveitar e esclarecer um pouco o assunto, para 
vc poder fazer uma análise mais criteriosa aí das suas opções e tomar uma 
decisão mais informada 
  
  1. Quando a gente fala em database , no mundo Oracle, a gente está se 
referendo aos arquivos em disco que contém dados e metadados (ie, datafiles, 
tempfiles, controlfiles, etc), arquivos esses que são abertos/controlados pelo 
software RDBMS Oracle, formando a instância Oracle...
   Para podermos passar a utilizar uma versão mais recente do RDBMS Oracle (o 
software), vc primeiro precisa (tirando um BACKUP COMPLETO antes, óbvio :) 
instalar a nova versão do software no servidor em questão (no mesmo 
diretório/oracle home ou em um diferente, embora o mais recomnendado seja num 
HOME novo), E depois aí sim : ** OU ** vc cria um database vazio com esses 
binários da nova versão e transporta/transfere os dados do banco velho para o 
novo banco vazio, ** OU ** vc CONVERTE esse database (esse conjunto todo de 
arquivos de dados e metadados) já existente para poder ser aberto e usado pela 
nova versão de RDBMS...
   Ambos os procedimentos tem vantagens e desvantagens : para a opção de 
transferir os dados para um novo database, a Vantagem principal é que, como vc 
criou um database vazio, com tablespaces novas, tudo novo, vc Obviamente 
usou/vai usar as features de armazenamento e controle introduzidas pelo novo 
RDBMS que te sejam úteis e que vc não usava na antiga, como (digamos) ASSM, 
undo automático , tablespace SYSTEM criada como LMT, etc, etc... A Desvantagem 
é que realmente criar E transferir os dados demora Muito Mais do que só a 
conversão, que é relativamente simples e rápida.. Vice-versa as 
vantagens/desvantagens de usar a conversão...
  
  2. Rigorosamente NÃO É só o tamanho do teu database que vai ser o seu único 
guia, mas sim TAMBÉM o tamanho da tua janela de manutenção : Lógico que se vc 
tiver, digamos, os dois dias do fim de semana para fazer o upgrade E as 
vantagens de recriar o database são atrativas para vc, Não Tem porque deixar de 
considerar as técnicas de export/transferência de dados do database velho para 
um novo recém criado vazio...
  
  3. A sua performance NECESSARIAMENTE vai variar grandemente dependendo do teu 
hardware, Óbvio, mas tipicamente em hardware de Produção eu vi conversão de 
database de 500 GB demorar coisa de 4 ou 5 horas, e transporte/export de dados 
(USANDO as técnicas corretas/adequadas. como Paralelismo, múltiplas instâncias, 
não-validação de constraints, etc, etc) para esses mesmos 500 GB levar coisa de 
umas 15 horas

   []s
      
        Chiappa


--- Em oracle_br@yahoogrupos.com.br, Daniel Mello  escreveu
>
> Boa tarde pessoal.
> 
>    Por favor, tenho um banco para migrar e por ele ser uma versão antiga, a 
> 8i (vai para a 11g), não sei ao certo qual estratégia usar, levando em 
> consideração seu tamanho, aproximadamente 500gb, pensei em expdp, mas 
> acredito que o tempo será mto alto para esse cenário. Alguém já fez algo 
> semelhante?
> 
> Obrigado.
> Daniel.
>






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

    http://info.yahoo.com/legal/br/yahoo/utos/terms/

Re: [oracle_br] Re: Migração de banco entre plataformas diferentes

[Rodrigo Mufalani]

Daniel.. Da uma olhada no meu blog que no passado eu fiz um post sobre migração 
de solaris para linux.


Enviado por Samsung Mobile

 Mensagem original 
De : Daniel Mello  
Data:  
Para: oracle_br@yahoogrupos.com.br 
Assunto: Re: [oracle_br] Re: Migração de banco entre plataformas diferentes 
 
Muito obrigado pelas respostas de todos.
Realmente um ponto que não destaquei é que nesta migração em específico teremos 
um bom tempo de indisponibilidade aceitável pelo cliente, ou seja, acredito que 
a forma mais simples seja realmente o "Cross-Platform Transportable 
Tablespaces". Terei que ensaiar um pouco essa migração, pois realmente é algo 
totalmente novo. Um ponto que não ficou bem claro na documentação é em relação 
à criação da instância e database, vocês já usaram esse recurso?

Att
Daniel.
 


De: J. Laurindo Chiappa 
Para: oracle_br@yahoogrupos.com.br 
Enviadas: Quinta-feira, 11 de Julho de 2013 18:00
Assunto: [oracle_br] Re: Migração de banco entre plataformas diferentes


  Joinha, Miltão ?  Bem, primeiro sobre o tamanho, não sei se eu chamaria hoje 
em dia 2 TB de VLDB, já que essa capacidade cabe (por um taxa até decente em 
termos de gigabyte x obamas) em coisinhas tipo aqui :  
http://www.wdc.com/pt/products/products.aspx?id=20 , e que INCLUSIVE pode ser 
montada em RAID-0 cfrme 
http://gizmodo.com/5939236/of-course-you-need-a-2tb-1rpm-hard-drive-with-two-thunderbolt-ports
 
  Anyway, no caso específico de migração que estamos discutindo, o busílis é 
que esta é uma migração cross-endianness - fosse uma migração para outro 
SO/plataforma mas de mesmo endianness simplesmente faríamos um backup para um 
disk device do tipo e restore+convert na outra ponta 
  Nessa situação aí sim realmente uma das opções com a menor indisponibilidade 
seria sim enviar os dados via rede de modo consistente e com banco disponível 
(por DG, por GG, por um software de terceiros que seja capaz de processar logs 
Oracle como é o caso do shareplex, por um software residente na máquina-destino 
que leia via rede os dados da origem e os insira no banco-destino de maneira 
consistente no tempo, via flashback ou quetais - existem diversos no mercado -, 
etc) , mas a NECESSIDADE aí é, Óbvio, uma rede de alta-performance ligando os 
dois servidores
  Isso TEM que ficar escrupulosamente Claro aí na sua cabeça, Daniel : se a tua 
infra de rede tá engargalada, e/ou vc não dispõe de rede Particular e de 
alta-performance entre os dois servers (não dá pra pensar em usar a rede 
Pública comum da Empresa, normalmente) aí pode ficar inviável usar tecnologias 
de transferência via rede, e nesses casos Tranquilamente pode ser mais 
economicamente viável ao invés de upgradear a rede se investir num disco 
externo rápido Infelizmente,sendo (como é) cross-endianness, a opção aí 
nesse cenário aonde a rede não é confiável e performática seria muito 
certamente partir para Cross-Platform Transportable Tablespaces , que implica 
em colocar cada tablespace em read-only e portanto é menos disponível .
    
    Para vc ter um overview das opções, dá um look na nota metalink "Migration 
Of An Oracle Database Across OS Platforms (Generic Platform)" [ID 733205.1] que 
vc acha links para as principais opções todas ...

  []s
  
    Chiappa

--- Em oracle_br@yahoogrupos.com.br, Rodrigo Mufalani  escreveu
>
> Meu caro,
> 
> Dê uma boa lida nesse paper e na(s) nota(s) do metalink que ele referencia. 
> Na minha opinião, a melhor forma para migrar VLDBs é com Dataguard e 
> tecnologias similares (Goldengate/Shareplex), mesmo assim ainda prefiro o DG.
> 
>  Onde o seu downtime é mínimo.
> 
> http://www.oracle.com/technetwork/database/features/availability/twp-dataguard-11gr2-1-131981.pdf
> 
> 
> Obs.: O GUOB está chegando, 10/08/2013 não deixe de ir no maior evento de 
> Oracle do brasil, faça sua inscrição em www.guob.com.br.
> 
> 
> Atenciosamente,
> Rodrigo Mufalani
> rodrigo@...
> www.mufalani.com.br
> 
> 
> 
> 
> 
> On 11/07/2013, at 16:27, Daniel Mello  wrote:
> 
> > Boa tarde.
> > 
> > Assim como um pergunta respondida de nosso amigo Victor, tenho uma migração 
> > entre plataformas, mas no meu caso muda o Endian_Format " BIG >> Little", a 
> > mudança será de um Solaris Sparc para Solaris x86-64. A versão do oracle é 
> > a 11.2.0.2. 
> > Alguém já fez esse tipo de conversão?
> > Conhecem o melhor método?
> > A base tem aproximadamente 2tb, por isso descartei o imp/impdp a princípio.
> > 
> > Obrigado.
> > Daniel.
> > 
> > [As partes desta mensagem que não continham texto foram removidas]
> > 
> > 
> 
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>



---

Re: [oracle_br] Re: Migração de banco entre plataformas diferentes

[Milton Bastos Henriquis Jr.]

Tudo jóia Chiappa, e vc?
O e-mail não era meu não... rs

Abraço!

http://certificacaobd.com.br



2013/7/11 J. Laurindo Chiappa 

> **
>
>
> Joinha, Miltão ? Bem, primeiro sobre o tamanho, não sei se eu chamaria
> hoje em dia 2 TB de VLDB, já que essa capacidade cabe (por um taxa até
> decente em termos de gigabyte x obamas) em coisinhas tipo aqui :
> http://www.wdc.com/pt/products/products.aspx?id=20 , e que INCLUSIVE pode
> ser montada em RAID-0 cfrme
> http://gizmodo.com/5939236/of-course-you-need-a-2tb-1rpm-hard-drive-with-two-thunderbolt-ports
> Anyway, no caso específico de migração que estamos discutindo, o busílis é
> que esta é uma migração cross-endianness - fosse uma migração para outro
> SO/plataforma mas de mesmo endianness simplesmente faríamos um backup para
> um disk device do tipo e restore+convert na outra ponta
> Nessa situação aí sim realmente uma das opções com a menor
> indisponibilidade seria sim enviar os dados via rede de modo consistente e
> com banco disponível (por DG, por GG, por um software de terceiros que seja
> capaz de processar logs Oracle como é o caso do shareplex, por um software
> residente na máquina-destino que leia via rede os dados da origem e os
> insira no banco-destino de maneira consistente no tempo, via flashback ou
> quetais - existem diversos no mercado -, etc) , mas a NECESSIDADE aí é,
> Óbvio, uma rede de alta-performance ligando os dois servidores
> Isso TEM que ficar escrupulosamente Claro aí na sua cabeça, Daniel : se a
> tua infra de rede tá engargalada, e/ou vc não dispõe de rede Particular e
> de alta-performance entre os dois servers (não dá pra pensar em usar a rede
> Pública comum da Empresa, normalmente) aí pode ficar inviável usar
> tecnologias de transferência via rede, e nesses casos Tranquilamente pode
> ser mais economicamente viável ao invés de upgradear a rede se investir num
> disco externo rápido Infelizmente,sendo (como é) cross-endianness, a
> opção aí nesse cenário aonde a rede não é confiável e performática seria
> muito certamente partir para Cross-Platform Transportable Tablespaces , que
> implica em colocar cada tablespace em read-only e portanto é menos
> disponível .
>
> Para vc ter um overview das opções, dá um look na nota metalink "Migration
> Of An Oracle Database Across OS Platforms (Generic Platform)" [ID 733205.1]
> que vc acha links para as principais opções todas ...
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, Rodrigo Mufalani 
> escreveu
>
> >
> > Meu caro,
> >
> > Dê uma boa lida nesse paper e na(s) nota(s) do metalink que ele
> referencia. Na minha opinião, a melhor forma para migrar VLDBs é com
> Dataguard e tecnologias similares (Goldengate/Shareplex), mesmo assim ainda
> prefiro o DG.
> >
> > Onde o seu downtime é mínimo.
> >
> >
> http://www.oracle.com/technetwork/database/features/availability/twp-dataguard-11gr2-1-131981.pdf
> >
> >
> > Obs.: O GUOB está chegando, 10/08/2013 não deixe de ir no maior evento
> de Oracle do brasil, faça sua inscrição em www.guob.com.br.
> >
> >
> > Atenciosamente,
> > Rodrigo Mufalani
> > rodrigo@...
> > www.mufalani.com.br
>
> >
> >
> >
> >
> >
> > On 11/07/2013, at 16:27, Daniel Mello  wrote:
> >
> > > Boa tarde.
> > >
> > > Assim como um pergunta respondida de nosso amigo Victor, tenho uma
> migração entre plataformas, mas no meu caso muda o Endian_Format " BIG >>
> Little", a mudança será de um Solaris Sparc para Solaris x86-64. A versão
> do oracle é a 11.2.0.2.
> > > Alguém já fez esse tipo de conversão?
> > > Conhecem o melhor método?
> > > A base tem aproximadamente 2tb, por isso descartei o imp/impdp a
> princípio.
> > >
> > > Obrigado.
> > > Daniel.
> > >
> > > [As partes desta mensagem que não continham texto foram removidas]
> > >
> > >
> >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>  
>


[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á suje

Re: [oracle_br] Re: Migração de banco entre plataformas diferentes

[Daniel Mello]

Muito obrigado pelas respostas de todos.
Realmente um ponto que não destaquei é que nesta migração em específico teremos 
um bom tempo de indisponibilidade aceitável pelo cliente, ou seja, acredito que 
a forma mais simples seja realmente o "Cross-Platform Transportable 
Tablespaces". Terei que ensaiar um pouco essa migração, pois realmente é algo 
totalmente novo. Um ponto que não ficou bem claro na documentação é em relação 
à criação da instância e database, vocês já usaram esse recurso?

Att
Daniel.
 



 De: J. Laurindo Chiappa 
Para: oracle_br@yahoogrupos.com.br 
Enviadas: Quinta-feira, 11 de Julho de 2013 18:00
Assunto: [oracle_br] Re: Migração de banco entre plataformas diferentes
 

  Joinha, Miltão ?  Bem, primeiro sobre o tamanho, não sei se eu chamaria hoje 
em dia 2 TB de VLDB, já que essa capacidade cabe (por um taxa até decente em 
termos de gigabyte x obamas) em coisinhas tipo aqui :  
http://www.wdc.com/pt/products/products.aspx?id=20 , e que INCLUSIVE pode ser 
montada em RAID-0 cfrme 
http://gizmodo.com/5939236/of-course-you-need-a-2tb-1rpm-hard-drive-with-two-thunderbolt-ports
 
  Anyway, no caso específico de migração que estamos discutindo, o busílis é 
que esta é uma migração cross-endianness - fosse uma migração para outro 
SO/plataforma mas de mesmo endianness simplesmente faríamos um backup para um 
disk device do tipo e restore+convert na outra ponta 
   Nessa situação aí sim realmente uma das opções com a menor indisponibilidade 
seria sim enviar os dados via rede de modo consistente e com banco disponível 
(por DG, por GG, por um software de terceiros que seja capaz de processar logs 
Oracle como é o caso do shareplex, por um software residente na máquina-destino 
que leia via rede os dados da origem e os insira no banco-destino de maneira 
consistente no tempo, via flashback ou quetais - existem diversos no mercado -, 
etc) , mas a NECESSIDADE aí é, Óbvio, uma rede de alta-performance ligando os 
dois servidores
   Isso TEM que ficar escrupulosamente Claro aí na sua cabeça, Daniel : se a 
tua infra de rede tá engargalada, e/ou vc não dispõe de rede Particular e de 
alta-performance entre os dois servers (não dá pra pensar em usar a rede 
Pública comum da Empresa, normalmente) aí pode ficar inviável usar tecnologias 
de transferência via rede, e nesses casos Tranquilamente pode ser mais 
economicamente viável ao invés de upgradear a rede se investir num disco 
externo rápido Infelizmente,sendo (como é) cross-endianness, a opção aí 
nesse cenário aonde a rede não é confiável e performática seria muito 
certamente partir para Cross-Platform Transportable Tablespaces , que implica 
em colocar cada tablespace em read-only e portanto é menos disponível .
    
     Para vc ter um overview das opções, dá um look na nota metalink "Migration 
Of An Oracle Database Across OS Platforms (Generic Platform)" [ID 733205.1] que 
vc acha links para as principais opções todas ...

  []s
  
    Chiappa

--- Em oracle_br@yahoogrupos.com.br, Rodrigo Mufalani  escreveu
>
> Meu caro,
> 
> Dê uma boa lida nesse paper e na(s) nota(s) do metalink que ele referencia. 
> Na minha opinião, a melhor forma para migrar VLDBs é com Dataguard e 
> tecnologias similares (Goldengate/Shareplex), mesmo assim ainda prefiro o DG.
> 
>  Onde o seu downtime é mínimo.
> 
> http://www.oracle.com/technetwork/database/features/availability/twp-dataguard-11gr2-1-131981.pdf
> 
> 
> Obs.: O GUOB está chegando, 10/08/2013 não deixe de ir no maior evento de 
> Oracle do brasil, faça sua inscrição em www.guob.com.br.
> 
> 
> Atenciosamente,
> Rodrigo Mufalani
> rodrigo@...
> www.mufalani.com.br
> 
> 
> 
> 
> 
> On 11/07/2013, at 16:27, Daniel Mello  wrote:
> 
> > Boa tarde.
> > 
> > Assim como um pergunta respondida de nosso amigo Victor, tenho uma migração 
> > entre plataformas, mas no meu caso muda o Endian_Format " BIG >> Little", a 
> > mudança será de um Solaris Sparc para Solaris x86-64. A versão do oracle é 
> > a 11.2.0.2. 
> > Alguém já fez esse tipo de conversão?
> > Conhecem o melhor método?
> > A base tem aproximadamente 2tb, por isso descartei o imp/impdp a princípio.
> > 
> > Obrigado.
> > Daniel.
> > 
> > [As partes desta mensagem que não continham texto foram removidas]
> > 
> > 
> 
> 
> 
> [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 ES

Re: [oracle_br] Re: Migração

[Fernando Franquini 'capin']

Concordo com o Vitor, tem que entender porque não compila.
Se fosse alguma coisa de mudança que ficou em desuso na versão 9i que não
tem na 11g blz, mas se não for isso é bom investigar o que está acontecendo.
Uso muito o P SQL Developer para isso e SEMPRE funciona.
Quando não funciona é porque realmente a package/procedre teve alterações e
está errada.

Att,
capin

2012/11/8 Vitor Jr. 

> Mas PORQUE estão inválidos?
> Tente compilar um objeto e depois execute um "show error"
> Qual erro aparece? Está concedendo as permissões de SYS do banco origem no
> banco destino?
> Ex.: Owner A na origem tem grant na V$SESSION, possui um objeto que faz
> select nessa view. Está concedendo esse grant na base de destino?
>
>
> Att,/Regards,
>
>
> Vitor Jr.
> Infraestrutura / Infrastructure Team
> Oracle 11g DBA Certified Professional - OCP
> Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid
> Infrastructure Administrator - OCE
> Oracle Database 11g Performance Tuning Certified Expert - OCE
> Oracle Exadata 11g Certified Implementation Specialist
> Oracle Certified Associate, MySQL 5
> mail, gtalk e msn: vitorj...@gmail.com
> http://certificacaobd.com.br/
> skype: vjunior1981
>
>
>
>
> On 08/11/2012, at 11:14, "netodba"  wrote:
>
> > Fernando tentei recompilar os objetos invalidos pelo PL SQL Developer e
> não consegui, por esse motivo que tenho preocupação.
> >
> > Luis, não estou fazendo impdp full, mas apenas dos schemas das
> aplicações, ou seja não mexo no SYS, a base de dados ja ta criada, com
> todas as tablespaces.
> >
> > se eu fizer:
> >
> > impdp system/senha directory=*** dumpfile=*** schemas=HR
> TABLE_EXISTS_ACTION=REPLACE
> >
> > ele irá dropar e recriar as tabelas com os indices e constraints né?
> >
> > como eu faria isso no imp pra instancia 9i??
> >
> > imp system/*** file=*** fromuser=HR touser=HR ignore=y data_only=y
> >
> > ??
> >
> > --- Em oracle_br@yahoogrupos.com.br, Luis Freitas 
> escreveu
> > >
> > > Neto,
> > >
> > > Quando fiz isso normalmente mantinha os usuarios e removia todos
> os objetos dentro deles.
> > >
> > >Depois de remover os objetos é preciso limpar a recyclebin, senão o
> espaço não é liberado.
> > >
> > > Normalmente os problemas de objetos invalidos que encontrei eram
> devido a grants faltando para os schemas.
> > >
> > >O exp/imp não copia grants de objetos que não foram importados, por
> exemplo, mesmo em um full import grants em views do sys ou grants de
> sistema não são recriados. Verifique na dba_sys_privs, dba_role_privs e
> dba_tab_privs where owner = 'SYS', na base de origem, e copie os grants que
> estiverem faltando.
> > >
> > > O proposito de manter os usuarios e apagar apenas os objetos é
> justamente manter estes grants, desta forma no proximo import devem ter bem
> menos objetos invalidos.
> > >
> > > Uma coisa que acontece com menos frequencia é ter alguma diferença
> no PL/SQL da versão nova. Por exemplo um sql invalido que era aceito na
> versão antiga devido a bugs, mas não funciona mais na versão nova. Nesse
> caso é preciso corrigir os objetos. Se for uma aplicação "pacote" o proprio
> fornecedor deve ter um patch para corrigir estes casos.
> > >
> > >Apenas truncar as tabelas não é uma boa idéia, pois elas vão manter
> os índicies, e se forem grandes o proximo import vai demorar muito mais
> tempo por causa dos indices. Voce precisa remover os indices e recria
> manualmente, o imp não vai recriar mas pode gerar um script com o show=yes.
> Para o impdp há um parametro para substitituir as tabelas, e nesse caso ele
> mesmo "dropa" as tabelas e recria.
> > >
> > >
> > >
> > > Atc,
> > > Luis
> > >
> > >
> > > 
> > > From: Fernando Franquini 'capin' 
> > > To: oracle_br@yahoogrupos.com.br
> > > Sent: Thursday, November 8, 2012 1:58 AM
> > > Subject: Re: [oracle_br] Migração
> > >
> > >
> > >
> > > Neto,
> > >
> > > se seu problema foi somente compilar os objetos acredito que pode
> resolver
> > > isso através do PL SQL Developer.
> > > Mas se teve correção, você pode exportar todos os objetos alterados
> > > (procedures, triggers, packages e views) e depois subi-las novamente.
> > >
> > > Mas creio que da forma que você vai fazer também está ok.
> > >
> > > Att,
> > > capin
> > >
> > > 2012/11/7 netodba 
> > >
> > > > Pessoal, preciso de uma luz.
> > > >
> > > > Estou migrando 2 bases de produção, uma 10g e outra 9i pra uma unica
> base
> > > > 11g.
> > > >
> > > > Bem, fiz a migração de teste usando impdp pra 10g e imp pra 9i, a
> migração
> > > > de teste foi feita direta no servidor que substituirá o antigo de
> produção.
> > > > Agora alguns objetos dos schemas importados ficaram inválidos, não
> rodei o
> > > > utlrp.sql pra recompilar os objetos inválidos. A equipe de
> desenvolvimento
> > > > esta fazendo os testes e até agora sucesso.
> > > >
> > > > Como eu vou migrar novamente, pra virar ambiente de produção, vou
> ter que
> > > > usar os mesmos schemas, só que eu nã

Re: [oracle_br] Re: Migração

[Vitor Jr.]

Mas PORQUE estão inválidos?
Tente compilar um objeto e depois execute um "show error"
Qual erro aparece? Está concedendo as permissões de SYS do banco origem no 
banco destino?
Ex.: Owner A na origem tem grant na V$SESSION, possui um objeto que faz select 
nessa view. Está concedendo esse grant na base de destino? 


Att,/Regards,


Vitor Jr.
Infraestrutura / Infrastructure Team
Oracle 11g DBA Certified Professional - OCP
Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid 
Infrastructure Administrator - OCE
Oracle Database 11g Performance Tuning Certified Expert - OCE
Oracle Exadata 11g Certified Implementation Specialist
Oracle Certified Associate, MySQL 5
mail, gtalk e msn: vitorj...@gmail.com
http://certificacaobd.com.br/
skype: vjunior1981




On 08/11/2012, at 11:14, "netodba"  wrote:

> Fernando tentei recompilar os objetos invalidos pelo PL SQL Developer e não 
> consegui, por esse motivo que tenho preocupação.
> 
> Luis, não estou fazendo impdp full, mas apenas dos schemas das aplicações, ou 
> seja não mexo no SYS, a base de dados ja ta criada, com todas as tablespaces.
> 
> se eu fizer:
> 
> impdp system/senha directory=*** dumpfile=*** schemas=HR 
> TABLE_EXISTS_ACTION=REPLACE
> 
> ele irá dropar e recriar as tabelas com os indices e constraints né?
> 
> como eu faria isso no imp pra instancia 9i??
> 
> imp system/*** file=*** fromuser=HR touser=HR ignore=y data_only=y
> 
> ??
> 
> --- Em oracle_br@yahoogrupos.com.br, Luis Freitas  escreveu
> >
> > Neto,
> > 
> > Quando fiz isso normalmente mantinha os usuarios e removia todos os 
> > objetos dentro deles. 
> > 
> >Depois de remover os objetos é preciso limpar a recyclebin, senão o 
> > espaço não é liberado.
> > 
> > Normalmente os problemas de objetos invalidos que encontrei eram devido 
> > a grants faltando para os schemas.
> > 
> >O exp/imp não copia grants de objetos que não foram importados, por 
> > exemplo, mesmo em um full import grants em views do sys ou grants de 
> > sistema não são recriados. Verifique na dba_sys_privs, dba_role_privs e 
> > dba_tab_privs where owner = 'SYS', na base de origem, e copie os grants que 
> > estiverem faltando.
> > 
> > O proposito de manter os usuarios e apagar apenas os objetos é 
> > justamente manter estes grants, desta forma no proximo import devem ter bem 
> > menos objetos invalidos.
> > 
> > Uma coisa que acontece com menos frequencia é ter alguma diferença no 
> > PL/SQL da versão nova. Por exemplo um sql invalido que era aceito na versão 
> > antiga devido a bugs, mas não funciona mais na versão nova. Nesse caso é 
> > preciso corrigir os objetos. Se for uma aplicação "pacote" o proprio 
> > fornecedor deve ter um patch para corrigir estes casos.
> > 
> >Apenas truncar as tabelas não é uma boa idéia, pois elas vão manter os 
> > índicies, e se forem grandes o proximo import vai demorar muito mais tempo 
> > por causa dos indices. Voce precisa remover os indices e recria 
> > manualmente, o imp não vai recriar mas pode gerar um script com o show=yes. 
> > Para o impdp há um parametro para substitituir as tabelas, e nesse caso ele 
> > mesmo "dropa" as tabelas e recria.
> >  
> > 
> > 
> > Atc,
> > Luis
> >   
> > 
> > 
> > From: Fernando Franquini 'capin' 
> > To: oracle_br@yahoogrupos.com.br 
> > Sent: Thursday, November 8, 2012 1:58 AM
> > Subject: Re: [oracle_br] Migração
> > 
> > 
> >   
> > Neto,
> > 
> > se seu problema foi somente compilar os objetos acredito que pode resolver
> > isso através do PL SQL Developer.
> > Mas se teve correção, você pode exportar todos os objetos alterados
> > (procedures, triggers, packages e views) e depois subi-las novamente.
> > 
> > Mas creio que da forma que você vai fazer também está ok.
> > 
> > Att,
> > capin
> > 
> > 2012/11/7 netodba 
> > 
> > > Pessoal, preciso de uma luz.
> > >
> > > Estou migrando 2 bases de produção, uma 10g e outra 9i pra uma unica base
> > > 11g.
> > >
> > > Bem, fiz a migração de teste usando impdp pra 10g e imp pra 9i, a migração
> > > de teste foi feita direta no servidor que substituirá o antigo de 
> > > produção.
> > > Agora alguns objetos dos schemas importados ficaram inválidos, não rodei o
> > > utlrp.sql pra recompilar os objetos inválidos. A equipe de desenvolvimento
> > > esta fazendo os testes e até agora sucesso.
> > >
> > > Como eu vou migrar novamente, pra virar ambiente de produção, vou ter que
> > > usar os mesmos schemas, só que eu não acho que dropar e recriar os 
> > > usuarios
> > > seja a melhor solução, justamente pelos objetos invalidos. Estou pensando
> > > em truncar as mais de 300 tabelas e fazer o impdp com content=data_only e
> > > imp com rows=Y e ignore=y
> > >
> > > o que vcs acham disso??? e como vcs fariam??
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 
> > >
> > >
> > > --
> > > >Atenção! As mensagens do g

Re: [oracle_br] Re: Migração schemas de EE para SE

[Milton Bastos Henriquis Jr.]

Nossa, mas trocar índices bitmap por índices b-tree é um verdadeiro tiro no
pé!
Seria muito melhor deixar sem índice!




2012/8/30 ederson2001br 

> **
>
>
> Alô Vitor,
>
> Permita-me dar um pitaco.
>
> Estava lendo as respostas do Chiappa e me lembrei de um caso que
> participei. No meu caso não tinha particionamento, mas haviam vários
> indices BITMAP (que também não tem no SE).
>
> Isto obrigou uma remodelagem, pois a performance cairia bastante devido ao
> problema dos indices bitmap (compostos, mais de duas colunas). A solução
> (que eu não gostei), foi criar novos indices compostos em ordem diferente,
> onde houve a necessidade.
>
> Se houver indices bitmap compostos na sua base EE, ao converter para
> indice simples na SE, haverá problemas de performance em algumas queries,
> mesmo exportando estatíticas.
>
> Ederson Elias
> DBA Oracle
> http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
>
> --- Em oracle_br@yahoogrupos.com.br, "Vitor Jr."  escreveu
>
> >
> > Bom dia.
> >
> > Cenário origem:
> > Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
> > PL/SQL Release 10.2.0.4.0 - Production
> > CORE 10.2.0.4.0 Production
> > TNS for Linux: Version 10.2.0.4.0 - Production
> > NLSRTL Version 10.2.0.4.0 - Production
> >
> > Cenário destino:
> > Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
> > PL/SQL Release 10.2.0.4.0 - Production
> > CORE 10.2.0.4.0 Production
> > TNS for Linux: Version 10.2.0.4.0 - Production
> > NLSRTL Version 10.2.0.4.0 - Production
> >
> > Ou seja, resumindo, estamos migrando de Enterprise para Standard.
> >
> > Me deparei com a seguinte situação: um dos schemas está usando
> particionamento, e o mesmo não precisa. Estava levando os schemas com
> exp/imp.
> > Qual a melhor forma de migrar um schema de EE para SE que possui objetos
> particionados?
> >
> >
> >
> >
> > Att,/Regards,
> >
> >
> > Vitor Jr.
> > Infraestrutura / Infrastructure Team
> > Oracle 11g DBA Certified Professional - OCP
> > Oracle Database 11g Performance Tuning Certified Expert - OCE
> > Oracle Exadata 11g Certified Implementation Specialist
> > Oracle Certified Associate, MySQL 5
> > mail, gtalk e msn: vitorjr81@...
>
> > http://certificacaobd.com.br/
> > skype: vjunior1981
> >
> >
> >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>  
>



-- 
Att,


[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

Re: [oracle_br] Re: Migração RAC 11.1.0.6 para 11.2.0.2 - Sugestões

[Diego Leite]

Amigo,

Acho que nao precisa falar mais nada apos a explicacao chiappa, porem nao
custa palpitar em solucoes.


Solucao1: Vc tbm pode fazer de uma forma mais segura, como vc tem um
terceiro no vc pode utilizar ele como uma maquina ponte.

1 - Vc pode prepar esta maquina ponte com o a nova versao do SO e com o
ultimo release da versao do oracle, apos isso migrar os dados para
homologacao sua e dos usuarios finais.
2 - Apos a Homologacao desta maquina ponte(com o a nova versao do SO e com o
ultimo release da versao do oracle) ai sim, pode migrar a producao para a
sua maquina ponte;
3 - Apos isso prepa o rac nos outros 2 nos com mais tranquilidade dai libera
para testes tbm no rac.

Com isso vc tera um tempo suficiente para homologacao da atualizacao na
maquina ponte e sem riscos.

Obs: É importante para esta situacao é saber se o seu banco vai aguentar a
carga neste nó ponte.




 Solucao2: A Sua ideia tbm eh muito boa, porem caso ainda nao teve a
oportunidade de aplica-la nao aconselharia fazer isto em um ambiente
critico.

Pelo que intendi esse rac de 2 nos passara a ter 3 nos, entao para nao
mecher no mesmo storage que estao os dados de producao, vc poderia tbm
migrar 1 dos seus nos atuais de rac para single-instance FILE SYSTEM. Desta
forma vc estaria *isolando* completamente os dados desta maquina e com isso
trabalharia no storage de forma mais segura.

1 - Com isso vc trabalharia nos outros 2 nos, apos os nos prontos faria as
homologacoes;
2 - Apos as homologacoes migraria a producao que neste momento esta em
single + 11gr1 + rh5.2 + FS para o rac + 11gr2 + rh5.5 + ASM;
3 - Ai sim o terceiro no vc iria estar mais tranquilo ainda para adicionalo
como 3º no;

Obs: Com isso vc so teria indisponibilidade em um momento que eh a virada da
chave de single para o rac.


Espero ter ajudado a ter mais uma possivel solucao, logo aparecera mais
solucoes legais dai vc aplica a que se enquadra melhor com o seu ambiente.

-- 
Att,


Diego Leite
DBA ORACLE

m 2 de agosto de 2011 20:30, José Laurindo escreveu:

> **
>
>
> Colega, antes uma obs : se tem qualquer criticidade acima de medíocre esse
> database, vc ** nunca ** pode fazer um upgrade (e nem sequer qualquer outra
> manutenção, como aplicação de patches, por exemplo) diretamente em Produção,
> necessariamente vc ** TEM ** que testar antes direitinho num ambiente
> teste/homologação, okdoc ??? A questão não é que seja um procedimento
> complexo e obscuro, o ponto é que é um procedimento Extenso (absolutamente
> Não É só rodar um "setup.exe" da vida e cabou) ,e além disso novos releases
> necessariamente podem trazer novos bugs, podem mudar ,métodos de
> acesso/conexão/sintaxes, ALÉM dos inevitáveis novos bugs - esses bichinhos
> utilizam as novas versões como "táxi" preferencial... OU SEJA, ao contrário
> da aplicação de patchsets , quase Tudo é permitido acontecer/mudar quando vc
> fala de upgrade de versão, então vc antes tem que testar, testar E testar
>  Assim, se esse ambiente que vc pretende migrar no fim de semana é
> produção, tem alguma criticidade E vc ainda não fez o teste num ambiente
> teste/homo antes, eu recomendo que vc ABORTE isso e faça o procedimento fora
> da Prod antes, blz ?
>
> Agora sim, respondo : começando pelo upgrade de Linux de 5.2 para 5.5 , ao
> que entendo (CONFIRME com o Suporte da redHat e boas refs, mas afaik) isso
> requer apenas um patch de SO, E os programas que rodavam antes sob 5.2 podem
> continuar sem mudanças no 5.5 , então é simplesmente o caso de instalar o
> 5.5 na máquina 3, parar o CRS e as instâncias (DB e ASM) na máquina 2,
> aplicar o patch para 5.5 na máquina 2, restart de tudo e blz, aí vc repete o
> mesmo processo na máquina 1.
>
> Indo pra dentro do ambiente Oracle agora, a tua referência Maior vai ser o
> manual de Upgrade, e a (crucial) nota metalink 785351.1 "Upgrade Companion
> 11g Release2", bem como a nota "RAC Assurance Support Team: RAC and Oracle
> Clusterware Starter Kit and Best Practices (Generic)", Doc ID:810394.1 .
>
> Muito bem, Próximo passo é o upgrade do CRS : ele pode ser feito em
> rolling, sem indisponibilidade (um nó por vez), veja a nota metalink "Oracle
> Clusterware (formerly CRS) Rolling Upgrades", Doc ID 338706.1 .
>
> Para o ASM, é possível se fazer rolling upgrade também, veja no manual
> "Oracle® Automatic Storage Management Administrator's Guide" o cap. 3 -
> Administering Oracle ASM Instances" o item "Using Oracle ASM Rolling
> Upgrade", ou até mesmo não fazer o upgrade neste momento : confira no
> metalink mas afaik ASM 11gr1 no último patchset é Sim suportado para ser
> usado por um database 11gr2...
>
> Finalmente, para vc não ter indisponibilidade em upgrade de versão do
> database, a Recomendação é que vc monte um stanbdby físico temporário, a
> nota "Oracle11g Data Guard: Database Rolling Upgrade Shell Script", Doc ID
> 949322.1 documenta esta opção.
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "luzizardba"  escreveu
>
> >

Re: [oracle_br] Re: Migração reports e forms 6i para 10g

[Nelson Frade]

Chiappa,
vlw, muito obrigado... a documentação é muito boa...
vou atras da doc do reports pelos links q me passou.
Abcs
 
FRADE, Nelson A.

--- Em qua, 27/4/11, José Laurindo  escreveu:


De: José Laurindo 
Assunto: [oracle_br] Re: Migração reports e forms 6i para 10g
Para: oracle_br@yahoogrupos.com.br
Data: Quarta-feira, 27 de Abril de 2011, 22:08


  



Colega, não sei se vc sabia e/ou já te tinha dito, mas 
http://technet.oracle.com é o site de tecnologia da Oracle , vc encontra LOTES 
de excelente informação técnica, dicas , artigos e Fóruns especializados lá pra 
quase TODOS os produtos da Oracle ... O Oracle Forms e o Oracle Reports não são 
exceção, 
http://www.oracle.com/technetwork/developer-tools/forms/overview/index.html é a 
página do Forms no site e 
http://www.oracle.com/technetwork/middleware/reports/overview/index.html é a do 
reports... lendo/acessando os links de artigos técnicos nessas páginas, vc por 
exemplo cai em 
http://www.oracle.com/technetwork/developer-tools/forms/forms-upgrade-reference-128184.pdf
 , que é ** EXATAMENTE ** o que vc vai precisar, ie, a Referência exata e 
detalhada de Tudo que mudou do Forms 6i pro Forms 9i (que foi a primeira versão 
do Forms a ir pro modo web)...

[]s

Chiappa

--- Em oracle_br@yahoogrupos.com.br, "nelson.frade@..."  
escreveu
>
> OK, vlw a dica... estamos fazendo uma documentação com todas as dicas,
> assim se ocorrer erro, é minimo.
> Abcs
> 
> FRADE
> 
> --- Em oracle_br@yahoogrupos.com.br, "Lucimar dos Santos"  escreveu
> >
> > Acrescentando mais uns detalhes, o fonte do forms 6 pode se compilado pelo 
> > 9 
> > sem problemas
> > apenas a chamada de relatórios é diferente, e precisa levantgar o serviço 
> > de 
> > relatórios no servidor,
> > fica uma dica que o fonte uma vez compilado na versão 9 não é possível 
> > voltar a compilar em 6 tome cuidado...
> > 
> > 
> > - Original Message - 
> > From: "Fernando Nati" 
> > To: 
> > Sent: Wednesday, April 27, 2011 12:46 PM
> > Subject: Re: [oracle_br] Migração reports e forms 6i para 10g
> > 
> > 
> > Nelson,
> > É uma empreitada...
> > A d2kwutil não existe mais.
> > Deve-se trocar pela webutil.
> > O reports são executados no servidor de relatórios (página web)
> > Nos forms, até que não muda muita coisa a nivel da construção no builder,
> > etc. mas é outra Runtime (agora seus forms serão executados no jinitiator ou
> > no java) Depende só do sue ambiente servidor.
> > 
> > Me contate no mail particular, já liderei migração de grandes sistemas do 6i
> > para o 10 e também estamos em uma migração. do 6i direto para o 11g.
> > 
> > 
> > 
> > Atenciosamente,
> > Fernando Nati.
> > fernandonati@
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 2011/4/27 nelson.frade@ 
> > 
> > >
> > >
> > > Bom dia!
> > > Aqui na empresa faremos a migração do reports e forms 6i para o 10g e
> > > gostaria de saber se vcs tem alguma documentação, dicas, o passo a passo
> > > para essa empreitada. Estamos finalizando o levantamento dos forms
> > > existentes, reports e alguma coisa do banco.
> > > Se puderem dar uma luz para o START agradeço.
> > > Abcs
> > >
> > > Nelson A. Frade
> > > Analista de Sistemas ORACLE
> > > Stefanini IT Solution
> > >
> > >
> > >
> > 
> > 
> > [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
> >
>








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

Re: [oracle_br] Re: Migração de banse de dados

[Raul Francisco Costa F. de Andrade, DBA]

Olá Welvis... Beleza?
Cara eu faço assim, export e import full com consistent=y...



Em 10 de maio de 2010 10:57, Welvis Douglas  escreveu:

>
>
> Certo,
>
> Caso eu faça via export faço um único export com full=y, consistent=y e
> importo usuário por usuário ou gero de acordo com o usuário?
>
> Ou isso vai de pessoa para pessoa, tipo cada um faz do seu jeito, o
> importante é que tenha lá o consistent=y?
>
> Obrigado.
>
> Att,
>
> _
>
> De: oracle_br@yahoogrupos.com.br  [mailto:
> oracle_br@yahoogrupos.com.br ] Em
> nome de José Laurindo
> Enviada em: segunda-feira, 10 de maio de 2010 10:44
> Para: oracle_br@yahoogrupos.com.br 
> Assunto: RES: [oracle_br] Re: Migração de banse de dados
>
> O MÍNIMO que se tem que saber é mesmo tamanho, a janela / tempo que vão te
> dar, o que roda hoje, o tempo de indisponibilidade aceitável, e se é
> aceitável vc fazer uma migração mesmo (ie, obter o mesmíssimo banco aberto
> pelo binário de versão superior) OU se há correções de
> estrutura/usabilidade
> que seriam recomendadas de se fazer (nesse caso uma RECRIAÇÃo do banco
> vazio
> com as correções seria de bom tom, com o import dos dados depois)  Sem
> isso é ABSOLUTAMENTE IMPOSSÍVEl se dizer qquer coisa que não seja CHUTE, ok
> ?
>
> []s
>
> Chiappa
>
> --- Em oracle...@yahoogrup 
>  >
> os.com.br, "Welvis Douglas"  escreveu
> >
> > Bom dia Chiappa,
> >
> >
> >
> > Obrigado pela dica, acho que o problema é que ainda não sei o tamanho
> deste
> > banco. A empresa ainda não disponibilizou a máquina para fazer as
> > verificações.
> >
> >
> >
> > Não sei o tamanho da base e nem o que roda nela, mais ou menos um kinder
> > ovo.
> >
> >
> >
> > No caso de um emp/imp faço um para cada usuário com consistent=y? ou é
> > melhor fazer um único export com full=y e depois importar usuário por
> > usuário?
> >
> >
> >
> > O que vc recomendaria? Eu sempre faço isso, mas coloco a base de produção
> > para homologação. Mas apenas de um usuário x para um y. não uma migração.
> >
> >
> >
> > Att,
> >
> >
> >
> > _
> >
> > De: oracle...@yahoogrup 
> > 
> os.com.br
> [mailto:oracle...@yahoogrup 
>  >
> os.com.br] Em
> > nome de José Laurindo
> > Enviada em: sábado, 8 de maio de 2010 18:18
> > Para: oracle...@yahoogrup 
> >  >
> os.com.br
> > Assunto: [oracle_br] Re: Migração de banse de dados
> >
> >
> >
> >
> >
> > pessoal, pmfji mas deixem-me fazer algumas adições : não tive também
> > experiência com stand-by no 8.0.x , mas EM TESE deve funcionar : o
> mecanismo
> > de recover de banco com aplicação de archived redo logs foi introduzido
> > l longe (na versão 6.0.x iirc) , na época do byte lascado, mas SE o
> > Welvis tiver uma mínimo downtime, eu recomendaria fortemente ele pensar
> na
> > hipótese de simplesmente MIGRAR o banco, ie : parar a instância e fechar
> o
> > banco 8.0.x NORMALMENTE (sem NENHUM TIPO DE ABORT!), ter os binários
> novos
> > instalados na máquina (em outro ORACLE_HOME , preferencialmente) ,
> startar
> > uma instância com os binários NOVOS e pedir pra essa instância NOVA abrir
> e
> > ler os arqs do banco antigo : a nota metalink "Complete Upgrade Checklist
> > for Manual Upgrades from 8.X / 9.0.1 to Oracle9iR2 (9.2.0)" (Doc ID
> > 159657.1) vai ser sua grande Amiga nesse processo... A vantagem disso é
> que
> > via de regra é Mito mais rápido do que exp/imp, a desvantagem é que
> vc
> > obterá um banco IGUALZINHO ao que estava no 8.0.x , não utilizando as new
> > features 8i/9i (tal como tablespaces LMT, bitmap indexes, e tantas
> outras)
> e
> > também vc perde a oportunidade de fazer as eventuais correções em tamanho
> de
> > extents, alocação/distribuição de disco, parâmetros de STORAGE A
> > vantagem do exp/imp é que, como vc na prática estará RECRIANDO os dados
> num
> > database zerado, Obviamente vc já aproveita para ter o database criado o
> > melhor possível E os segmentos também...
> >
> > []s
> >
> > Chiappa
> >
> >
> > --- Em oracle...@yahoogrup 
> >  >
> > os.com.br, Marcos Braga  escreveu
> > >
> > > Welvis,
> > >
> > > Eu não sei sobre standby para a versão 8, mas para a versão 9 e 10, fiz
> um
> > > documento utilizando a versão standard (não há dataguard habilitado),
> > então
> > > muita coisa é manual, acompanhe em:
> > >
> > > http://trilha0.  
> blogspot.com/2007/12/standby-oracle.html>
> > blogspot.com/2007/12/standby-oracle.html
> > >
> > > Tenho outro standby criado na versão 11.2 enterprise utilizando
> dataguard
> > > broker e rman para tanto, acompanhe em:
> > >
> > > http://sites.
> >  
> google.com/site/universodobraga/oracle/standby-11g>
> > google.com/site/universodobraga/oracle/standby-11g
> > >
> > 

Re: [oracle_br] Re: Migração de base de dados gran de

[Duilio Bruniera Junior]

Vai lá então.
< export >
1.> primeiro voce cria um arquivo de pipe
$ mknod pipe p

2. depois voce cria um arquivo parfile para chamar do export (se quiser
fazer um string só tambem pode)
## vi exp_dump_full.par 
userid='/ as sysdba'
file= pipe
log= dump_full.log
full=y
statistics=none
compress=N
direct=Y
#


3.> Agora voce da um gzip no arquivo de pipe e aponta ele para o nome que
voce quer gerar seu dump.
$ gzip < pipe > exp_dump_full.dmp.gz &

4.> execute o commando de export apontando para o arquivo de parametro que
voce criou. (o nohup é para não ter perigo de cair a sessão)
$ nohup exp parfile=exp_dump_full.par &

5.> beleza  agora voce da um tail no arquivo do nohup para assistir o
log passar.
$ tail -f nohup.out
< fim >
< import >
1.> crie o arquivo parfile para chamar o import
### vi imp_dump_full.par

userid='/ as sysdba'
file=pipe
log=imp_full.log
full=y
ignore = Y
statistics=none
commit=y
#

2.> se voce não tem crie o arquivo de pipe
$ mknod pipe p

3.> descompacte seu arquivo zipado apontando para o arquivo pipe
$ gunzip -c exp_dump_full.dmp.gz > pipe &

4.> execute o comando de import apontando para o arquivo de parametro que
voce criou.
$ nohup imp parfile=imp_dump_schemas.par &

5.> beleza  agora voce da um tail no arquivo do nohup para assistir o
log passar. e fim.
$ tail -f nohup.out

Lembre isso só funciona em ambiente Unix/Linux, talves seja possivel em
Windows porem não tenho conhecimento sobre isso.

Duvidas mandem um e-mail.

Em 9 de abril de 2010 09:45, Raul Francisco Costa F. de Andrade, DBA <
raulf...@gmail.com> escreveu:

>
>
> Bom dia amigo!!!
>
> Estou interessado no script sim, por favor se puder me mandar irá me ajudar
> muito.
>
> Att.
>
> Raul
>
> Em 8 de abril de 2010 18:39, Duilio Bruniera Junior
> >escreveu:
>
>
> > E ai bunitão da pra fazer export e import compactado com pipe isso se o
> seu
> > sistema operacional for um Linux ou Unix.
> > voce gera o dump ja compactado. sai mais ou menos umas 7 menor que o
> > tamanho
> > original, se tiver interessado me da um toque eu te mando o script de
> como
> > fazer!
> > porem o seu downtime sera maior doque se voce fizer um upgrade.
> >
> >
> >
> > Em 8 de abril de 2010 17:45, José Laurindo 
> > 
> > >escreveu:
> >
> > >
> > >
> > > Colega, se é outro equipamento, E (obviamente) deve haver comunicação
> de
> > > rede entre os dois, sem criar arqs intermediários grandes, uma opção
> que
> > > salta aos olhos em primeiro lugar é vc instalar os binários , criar uma
> > > instância 10g, criar um database vazio, criar as estruturas do 9i nele
> e
> > > trazer os dados do bd original : criar a estrutura seria um export com
> > > ROWS=N CONSTRAINTS=N INDEXES=N (isso ocuparia uns poucos Mbs, um export
> > sem
> > > dados é bem pequeno), e depois ir trazendo os dados (via INSERT /*+
> > APPEND
> > > */ into tabela select * from tab...@dblinkparao9i , pequenos exports
> > > feitos a partir do 10g conectando no 9i via dblink, E quando os dados
> > > estarem ok aí vc executa um script que crie os índices em parallel e
> > > nologging e crie as constraints SEM validar os dados (que vc já sabe
> que
> > > estão bons) - via de regra essa opção é bem rápida, em especial se a
> sua
> > > rede e o I/O são bons, vc pod ter várias sessões trazendo dados do 9i
> ao
> > > mesmo tempo... Pra te ajudar a extrair os scripts de criação de
> > estruturas,
> > > índices e constraints vc pode usar o freeware DDL Wizard em
> > > http://ddlwizard.com/ . E é claro, ainda sem trafegar grandes arqs, vc
> > Não
> > > vai deixar de mensurar as outras possibilidades já citadas na thread
> por
> > > ouros colegas, como voltar um backup do RMAN no novo servidor (ele tem
> > > comandos para fazer o upgrade dos arqs), se for em fita e a fita puder
> > ser
> > > atachada no novo server Se nenhuma das duas outras possibilidades
> for
> > > viável, aí caímos na necessidade de se Transferir os arquivos do 9i pro
> > 10g
> > > e lá fazer o upgrade/conversão deles, via de regra isso deve ser um
> pouco
> > > mais demorado...
> > >
> > > O resumo da ópera é , então, é : no SEU ambiente, teste quanto tempo
> leva
> > > (sob condições ótimas, com o mínimo de usuários usando, com Parallel
> DML
> > > ativo, com db_file_multiblock_read_count no talo máximo, etc) quanto
> > tempo
> > > leva um INSERT /*+ APPEND */ via dblink, quanto tempo leva o restore
> dos
> > > maiores arqs e quanto tempo leva a transferência de arqs via rede (o
> > > upgrade/conversão é rapidinho) , que aí vc terá condição de dizer qual
> é
> > o
> > > melhor em tempo ...
> > >
> > > É claro, vc TEM que dar uma gordurinha na sua estimativa total clause
> > > ativada seja qual for o método (pois no caso de INSERT vc terá que
> > rebuildar
> > >

Re: [oracle_br] Re: Migração de base de dados gran de

[Raul Francisco Costa F. de Andrade, DBA]

Bom dia amigo!!!

Estou interessado no script sim, por favor se puder me mandar irá me ajudar
muito.


Att.

Raul

Em 8 de abril de 2010 18:39, Duilio Bruniera Junior
escreveu:

> E ai bunitão da pra fazer export e import compactado com pipe isso se o seu
> sistema operacional for um Linux ou Unix.
> voce gera o dump ja compactado. sai mais ou menos umas 7 menor que o
> tamanho
> original, se tiver interessado me da um toque eu te mando o script de como
> fazer!
> porem o seu downtime sera maior doque se voce fizer um upgrade.
>
>
>
> Em 8 de abril de 2010 17:45, José Laurindo  >escreveu:
>
> >
> >
> > Colega, se é outro equipamento, E (obviamente) deve haver comunicação de
> > rede entre os dois, sem criar arqs intermediários grandes, uma opção que
> > salta aos olhos em primeiro lugar é vc instalar os binários , criar uma
> > instância 10g, criar um database vazio, criar as estruturas do 9i nele e
> > trazer os dados do bd original : criar a estrutura seria um export com
> > ROWS=N CONSTRAINTS=N INDEXES=N (isso ocuparia uns poucos Mbs, um export
> sem
> > dados é bem pequeno), e depois ir trazendo os dados (via INSERT /*+
> APPEND
> > */ into tabela select * from tab...@dblinkparao9i , pequenos exports
> > feitos a partir do 10g conectando no 9i via dblink, E quando os dados
> > estarem ok aí vc executa um script que crie os índices em parallel e
> > nologging e crie as constraints SEM validar os dados (que vc já sabe que
> > estão bons) - via de regra essa opção é bem rápida, em especial se a sua
> > rede e o I/O são bons, vc pod ter várias sessões trazendo dados do 9i ao
> > mesmo tempo... Pra te ajudar a extrair os scripts de criação de
> estruturas,
> > índices e constraints vc pode usar o freeware DDL Wizard em
> > http://ddlwizard.com/ . E é claro, ainda sem trafegar grandes arqs, vc
> Não
> > vai deixar de mensurar as outras possibilidades já citadas na thread por
> > ouros colegas, como voltar um backup do RMAN no novo servidor (ele tem
> > comandos para fazer o upgrade dos arqs), se for em fita e a fita puder
> ser
> > atachada no novo server Se nenhuma das duas outras possibilidades for
> > viável, aí caímos na necessidade de se Transferir os arquivos do 9i pro
> 10g
> > e lá fazer o upgrade/conversão deles, via de regra isso deve ser um pouco
> > mais demorado...
> >
> > O resumo da ópera é , então, é : no SEU ambiente, teste quanto tempo leva
> > (sob condições ótimas, com o mínimo de usuários usando, com Parallel DML
> > ativo, com db_file_multiblock_read_count no talo máximo, etc) quanto
> tempo
> > leva um INSERT /*+ APPEND */ via dblink, quanto tempo leva o restore dos
> > maiores arqs e quanto tempo leva a transferência de arqs via rede (o
> > upgrade/conversão é rapidinho) , que aí vc terá condição de dizer qual é
> o
> > melhor em tempo ...
> >
> > É claro, vc TEM que dar uma gordurinha na sua estimativa total clause
> > ativada seja qual for o método (pois no caso de INSERT vc terá que
> rebuildar
> > os índices, no caso de conversão de datafiles normalmente após o STARTUP
> > UPGRADE vc tem que recriar parte do dicionário/catálogo, recompilar objs
> > inválidos, E no seu caso sendo 32 -> 64 bits a conversão vai ter que
> > recompilar PL/SQLs)... Blz ?
> >
> > []s
> >
> > Chiappa
> >
> >
>  > --- Em oracle_br@yahoogrupos.com.br ,
> > "Raul Francisco Costa F. de Andrade, DBA"  escreveu
> >
> > >
> > > Grande Chiappa!!! Mais uma vez obrigado pelo interesse em
> > responder/ajudar.
> > >
> > > Então os dados que não falei:
> > > São no mesmo SO, porém em servidores diferentes, e ainda no 9i está em
> > > estrutura de FS e na 10G vai para RAC com ASM.
> > > Ah também vão de 32 para 64 bits.
> > >
> > > Att.
> > >
> > > Raul
> > >
> > > Em 8 de abril de 2010 14:21, José Laurindo escreveu:
> >
> > >
> > > >
> > > >
> > > > Bem, vc não dá os detalhes cruciais (ie, se é migração pro mesmo
> > servidor
> > > > ou pra um outro, os Sistemas Operacionais exatos envolvidos e
> > > > características de hardware se forem servers diferentes), mas de modo
> > geral
> > > > :
> > > >
> > > > a) se for no mesmo servidor E no mesmo SO/etc, sem dúvida a maneira
> > mais
> > > > fácil é vc fazer a migração (ie, a Conversão) desse banco de dados
> pra
> > 10g
> > > > (só lembrando, a definição de "banco de dados" é que ele é a soma dos
> > > > ARQUIVOS, como datafiles, controlfiles, redo files, etc, e a
> Instância
> > são
> > > > os binários, fazendo a Instância ler os arqs vc tem um banco Aberto).
> O
> > > > procedimento é relativamente simples, vc instala os binários 10g,
> > starta a
> > > > instância 10g e aí pede para ela ler os arquivos 9i, convertendo-os
> > para o
> > > > formato 10g via STARTUP MIGRATE . Consulte no metalink a nota
> metalink
> > > > 466181.1 "10g Upgrade Companion", que ela dá os detalhes todos
> > > >
> > > > b) se for de um server pra outro a´pode haver variações , dependendo
> se
> > o
> > > > So muda, se a qruitetura (32/64 bits) muda... Se for isso, passa os
> > dets,

Re: [oracle_br] Re: Migração de base de dados gran de

[Ivan Ricardo Schuster]

Raul

Um note que pode te ajudar bastante:

Best Practices to Minimize Downtime During Upgrade [ID 455744.1]

Este note ja aborda praticamente tudo o que você precisa para passar
de 9i para 10g com o mínimo de downtime.

Além disso, o que "pega" na tua migração é a transferencia dos dados
de FS para ASM. Vejo duas opções para contornar isso:

1) Migrar inicialmente para FS, depois com RMAN transferir os
datafiles para ASM via "backup as copy". Ao final, fazer o switch para
a copia - Neste caso você precisa de mais espaço em disco.

2) Fazer upgrade na maquina atual. Criar no RAC um standby do banco de
produção atual usando ASM. Baixar o banco atual, aplicar os archives
restantes e subir o "standby RAC" como produção.

Pra qualquer um dos cenários, muito teste!

att

Ivan R. Schuster
OCP 10g/11g
OCE RAC


2010/4/8 Duilio Bruniera Junior :
> E ai bunitão da pra fazer export e import compactado com pipe isso se o seu
> sistema operacional for um Linux ou Unix.
> voce gera o dump ja compactado. sai mais ou menos umas 7 menor que o tamanho
> original, se tiver interessado me da um toque eu te mando o script de como
> fazer!
> porem o seu downtime sera maior doque se voce fizer um upgrade.
>
>
>
> Em 8 de abril de 2010 17:45, José Laurindo escreveu:
>
>>
>>
>> Colega, se é outro equipamento, E (obviamente) deve haver comunicação de
>> rede entre os dois, sem criar arqs intermediários grandes, uma opção que
>> salta aos olhos em primeiro lugar é vc instalar os binários , criar uma
>> instância 10g, criar um database vazio, criar as estruturas do 9i nele e
>> trazer os dados do bd original : criar a estrutura seria um export com
>> ROWS=N CONSTRAINTS=N INDEXES=N (isso ocuparia uns poucos Mbs, um export sem
>> dados é bem pequeno), e depois ir trazendo os dados (via INSERT /*+ APPEND
>> */ into tabela select * from tab...@dblinkparao9i , pequenos exports
>> feitos a partir do 10g conectando no 9i via dblink, E quando os dados
>> estarem ok aí vc executa um script que crie os índices em parallel e
>> nologging e crie as constraints SEM validar os dados (que vc já sabe que
>> estão bons) - via de regra essa opção é bem rápida, em especial se a sua
>> rede e o I/O são bons, vc pod ter várias sessões trazendo dados do 9i ao
>> mesmo tempo... Pra te ajudar a extrair os scripts de criação de estruturas,
>> índices e constraints vc pode usar o freeware DDL Wizard em
>> http://ddlwizard.com/ . E é claro, ainda sem trafegar grandes arqs, vc Não
>> vai deixar de mensurar as outras possibilidades já citadas na thread por
>> ouros colegas, como voltar um backup do RMAN no novo servidor (ele tem
>> comandos para fazer o upgrade dos arqs), se for em fita e a fita puder ser
>> atachada no novo server Se nenhuma das duas outras possibilidades for
>> viável, aí caímos na necessidade de se Transferir os arquivos do 9i pro 10g
>> e lá fazer o upgrade/conversão deles, via de regra isso deve ser um pouco
>> mais demorado...
>>
>> O resumo da ópera é , então, é : no SEU ambiente, teste quanto tempo leva
>> (sob condições ótimas, com o mínimo de usuários usando, com Parallel DML
>> ativo, com db_file_multiblock_read_count no talo máximo, etc) quanto tempo
>> leva um INSERT /*+ APPEND */ via dblink, quanto tempo leva o restore dos
>> maiores arqs e quanto tempo leva a transferência de arqs via rede (o
>> upgrade/conversão é rapidinho) , que aí vc terá condição de dizer qual é o
>> melhor em tempo ...
>>
>> É claro, vc TEM que dar uma gordurinha na sua estimativa total clause
>> ativada seja qual for o método (pois no caso de INSERT vc terá que rebuildar
>> os índices, no caso de conversão de datafiles normalmente após o STARTUP
>> UPGRADE vc tem que recriar parte do dicionário/catálogo, recompilar objs
>> inválidos, E no seu caso sendo 32 -> 64 bits a conversão vai ter que
>> recompilar PL/SQLs)... Blz ?
>>
>> []s
>>
>> Chiappa
>>
>>
>> --- Em oracle_br@yahoogrupos.com.br ,
>> "Raul Francisco Costa F. de Andrade, DBA"  escreveu
>>
>> >
>> > Grande Chiappa!!! Mais uma vez obrigado pelo interesse em
>> responder/ajudar.
>> >
>> > Então os dados que não falei:
>> > São no mesmo SO, porém em servidores diferentes, e ainda no 9i está em
>> > estrutura de FS e na 10G vai para RAC com ASM.
>> > Ah também vão de 32 para 64 bits.
>> >
>> > Att.
>> >
>> > Raul
>> >
>> > Em 8 de abril de 2010 14:21, José Laurindo escreveu:
>>
>> >
>> > >
>> > >
>> > > Bem, vc não dá os detalhes cruciais (ie, se é migração pro mesmo
>> servidor
>> > > ou pra um outro, os Sistemas Operacionais exatos envolvidos e
>> > > características de hardware se forem servers diferentes), mas de modo
>> geral
>> > > :
>> > >
>> > > a) se for no mesmo servidor E no mesmo SO/etc, sem dúvida a maneira
>> mais
>> > > fácil é vc fazer a migração (ie, a Conversão) desse banco de dados pra
>> 10g
>> > > (só lembrando, a definição de "banco de dados" é que ele é a soma dos
>> > > ARQUIVOS, como datafiles, controlfiles, redo files, etc, e a Instância
>> são
>> > > os binários, fazen

Re: [oracle_br] Re: Migração de base de dados gran de

[Duilio Bruniera Junior]

E ai bunitão da pra fazer export e import compactado com pipe isso se o seu
sistema operacional for um Linux ou Unix.
voce gera o dump ja compactado. sai mais ou menos umas 7 menor que o tamanho
original, se tiver interessado me da um toque eu te mando o script de como
fazer!
porem o seu downtime sera maior doque se voce fizer um upgrade.



Em 8 de abril de 2010 17:45, José Laurindo escreveu:

>
>
> Colega, se é outro equipamento, E (obviamente) deve haver comunicação de
> rede entre os dois, sem criar arqs intermediários grandes, uma opção que
> salta aos olhos em primeiro lugar é vc instalar os binários , criar uma
> instância 10g, criar um database vazio, criar as estruturas do 9i nele e
> trazer os dados do bd original : criar a estrutura seria um export com
> ROWS=N CONSTRAINTS=N INDEXES=N (isso ocuparia uns poucos Mbs, um export sem
> dados é bem pequeno), e depois ir trazendo os dados (via INSERT /*+ APPEND
> */ into tabela select * from tab...@dblinkparao9i , pequenos exports
> feitos a partir do 10g conectando no 9i via dblink, E quando os dados
> estarem ok aí vc executa um script que crie os índices em parallel e
> nologging e crie as constraints SEM validar os dados (que vc já sabe que
> estão bons) - via de regra essa opção é bem rápida, em especial se a sua
> rede e o I/O são bons, vc pod ter várias sessões trazendo dados do 9i ao
> mesmo tempo... Pra te ajudar a extrair os scripts de criação de estruturas,
> índices e constraints vc pode usar o freeware DDL Wizard em
> http://ddlwizard.com/ . E é claro, ainda sem trafegar grandes arqs, vc Não
> vai deixar de mensurar as outras possibilidades já citadas na thread por
> ouros colegas, como voltar um backup do RMAN no novo servidor (ele tem
> comandos para fazer o upgrade dos arqs), se for em fita e a fita puder ser
> atachada no novo server Se nenhuma das duas outras possibilidades for
> viável, aí caímos na necessidade de se Transferir os arquivos do 9i pro 10g
> e lá fazer o upgrade/conversão deles, via de regra isso deve ser um pouco
> mais demorado...
>
> O resumo da ópera é , então, é : no SEU ambiente, teste quanto tempo leva
> (sob condições ótimas, com o mínimo de usuários usando, com Parallel DML
> ativo, com db_file_multiblock_read_count no talo máximo, etc) quanto tempo
> leva um INSERT /*+ APPEND */ via dblink, quanto tempo leva o restore dos
> maiores arqs e quanto tempo leva a transferência de arqs via rede (o
> upgrade/conversão é rapidinho) , que aí vc terá condição de dizer qual é o
> melhor em tempo ...
>
> É claro, vc TEM que dar uma gordurinha na sua estimativa total clause
> ativada seja qual for o método (pois no caso de INSERT vc terá que rebuildar
> os índices, no caso de conversão de datafiles normalmente após o STARTUP
> UPGRADE vc tem que recriar parte do dicionário/catálogo, recompilar objs
> inválidos, E no seu caso sendo 32 -> 64 bits a conversão vai ter que
> recompilar PL/SQLs)... Blz ?
>
> []s
>
> Chiappa
>
>
> --- Em oracle_br@yahoogrupos.com.br ,
> "Raul Francisco Costa F. de Andrade, DBA"  escreveu
>
> >
> > Grande Chiappa!!! Mais uma vez obrigado pelo interesse em
> responder/ajudar.
> >
> > Então os dados que não falei:
> > São no mesmo SO, porém em servidores diferentes, e ainda no 9i está em
> > estrutura de FS e na 10G vai para RAC com ASM.
> > Ah também vão de 32 para 64 bits.
> >
> > Att.
> >
> > Raul
> >
> > Em 8 de abril de 2010 14:21, José Laurindo escreveu:
>
> >
> > >
> > >
> > > Bem, vc não dá os detalhes cruciais (ie, se é migração pro mesmo
> servidor
> > > ou pra um outro, os Sistemas Operacionais exatos envolvidos e
> > > características de hardware se forem servers diferentes), mas de modo
> geral
> > > :
> > >
> > > a) se for no mesmo servidor E no mesmo SO/etc, sem dúvida a maneira
> mais
> > > fácil é vc fazer a migração (ie, a Conversão) desse banco de dados pra
> 10g
> > > (só lembrando, a definição de "banco de dados" é que ele é a soma dos
> > > ARQUIVOS, como datafiles, controlfiles, redo files, etc, e a Instância
> são
> > > os binários, fazendo a Instância ler os arqs vc tem um banco Aberto). O
> > > procedimento é relativamente simples, vc instala os binários 10g,
> starta a
> > > instância 10g e aí pede para ela ler os arquivos 9i, convertendo-os
> para o
> > > formato 10g via STARTUP MIGRATE . Consulte no metalink a nota metalink
> > > 466181.1 "10g Upgrade Companion", que ela dá os detalhes todos
> > >
> > > b) se for de um server pra outro a´pode haver variações , dependendo se
> o
> > > So muda, se a qruitetura (32/64 bits) muda... Se for isso, passa os
> dets,
> > > plz.
> > >
> > > []s
> > >
> > > Chiappa
> > >
> > > --- Em oracle_br@yahoogrupos.com.br 
> > >  40yahoogrupos.com.br>,
> > > "Raul Francisco Costa F. de Andrade, DBA"  escreveu
> > >
> > > >
> > > > Pessoal, estou com um problema que talvez possam me ajudar.
> > > > Preciso fazer a migração de uma base de dados do Oracle 9i para 10G
> > > > (10.2.0.4).
> > > > Porém a base tem 300GB e não tenho este espa

Re: [oracle_br] Re: Migração de base de dados gran de

[Raul Francisco Costa F. de Andrade, DBA]

Grande Chiappa!!! Mais uma vez obrigado pelo interesse em responder/ajudar.

Então os dados que não falei:
São no mesmo SO, porém em servidores diferentes, e ainda no 9i está em
estrutura de FS e na 10G vai para RAC com ASM.
Ah também vão de 32 para 64 bits.

Att.

Raul

Em 8 de abril de 2010 14:21, José Laurindo escreveu:

>
>
> Bem, vc não dá os detalhes cruciais (ie, se é migração pro mesmo servidor
> ou pra um outro, os Sistemas Operacionais exatos envolvidos e
> características de hardware se forem servers diferentes), mas de modo geral
> :
>
> a) se for no mesmo servidor E no mesmo SO/etc, sem dúvida a maneira mais
> fácil é vc fazer a migração (ie, a Conversão) desse banco de dados pra 10g
> (só lembrando, a definição de "banco de dados" é que ele é a soma dos
> ARQUIVOS, como datafiles, controlfiles, redo files, etc, e a Instância são
> os binários, fazendo a Instância ler os arqs vc tem um banco Aberto). O
> procedimento é relativamente simples, vc instala os binários 10g, starta a
> instância 10g e aí pede para ela ler os arquivos 9i, convertendo-os para o
> formato 10g via STARTUP MIGRATE . Consulte no metalink a nota metalink
> 466181.1 "10g Upgrade Companion", que ela dá os detalhes todos
>
> b) se for de um server pra outro a´pode haver variações , dependendo se o
> So muda, se a qruitetura (32/64 bits) muda... Se for isso, passa os dets,
> plz.
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br ,
> "Raul Francisco Costa F. de Andrade, DBA"  escreveu
>
> >
> > Pessoal, estou com um problema que talvez possam me ajudar.
> > Preciso fazer a migração de uma base de dados do Oracle 9i para 10G
> > (10.2.0.4).
> > Porém a base tem 300GB e não tenho este espaço em hd para gerar o EXPORT
> > para depois fazer o import.
> > Também não posso usar o Datapump por ser Oracle 9i a base origem.
> >
> > Gostaria de algumas dicas se possível.
> >
> >
> > Att.
> >
> > Raul
> >
> > --
> > --
> > Raul Francisco da Costa Ferreira de Andrade
> > DBA - OCA - Oracle Certified Associate
> > COBIT Foundation 4.1
> > Fone: (41)8855-8874 Brt
> > email: raulf...@...
>
> > Skype: raul.andrade
> > www.clickdba.com
> > "Para conhecermos os amigos é necessário passar
> > pelo sucesso e pela desgraça.
> > No sucesso, verificamos a quantidade e,
> > na desgraça, a qualidade. " Confúcio
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>  
>



-- 
--
Raul Francisco da Costa Ferreira de Andrade
DBA - OCA - Oracle Certified Associate
COBIT Foundation 4.1
Fone: (41)8855-8874 Brt
email: raulf...@gmail.com
Skype: raul.andrade
www.clickdba.com
"Para conhecermos os amigos é necessário passar
pelo sucesso e pela desgraça.
No sucesso, verificamos a quantidade e,
na desgraça, a qualidade. " Confúcio


[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

Re: [oracle_br] Re: Migração de banco de Oracle 9i para Oracle 10g - criação e remoção de parâmetros

[Fernando Mariano]

chiappa... Obrigado pela ajuda, porém acabamos fazendo o export e import dos
dados através uma ferramenta da própria aplicação que utiliza a base de
dados do oracle...


Abraço
Fernando

2009/10/15 jlchiappa 

>
>
> Então :
>
> > Em relação a versão do Oracle, no site para linux na arquitetura x86_64
> só
> > existe a versão 10.2.0.1 para baixar, vou verificar se existe o patch no
> > metalink...
>
> óbvio que existe, sim, é um patch já disponível há bastante tempo... Na
> verdade no technet (esse deve ser o site a que vc se referiu) normalmente
> fica a versão-base só, os patches todos só quem tem acesso ao metalink (o
> Suporte pago) pode baixar...
>
> Em relação à situação, primeiro, cadê o DUMP que citei ??? É esse cara que
> vai nos mostrar ** EXATAMENTE ** o que está gravado lá dentro da string, é
> simplesmente fazer um :
>
> SELECT nomedacoluna, dump(nomedacoluna) FROM nomedatabela WHERE
> nomedacoluna like '%condiçãoquetrazalgunsregistros%';
>
> se houver espaços, caracteres ocultos, ou o que for esse dump nos mostrará
>  E nos diga o datatype dessa string, é CHAR, VARCHAR2, NCHAR, o que
> exatamente ??
>
> Segundo, sim, é EXATAMENTE a NLS_LANG à qual me referi quando disse 'setar
> NLS na linha de comando' : só estranhei que vc está usando characterset de
> 32 bits, isso é coisa de banco globalizado, que vai armazenar strings com
> caracteres orientais e coisa do tipo, é REALMENTE isso que vc queria ? E
> normalmente se indica a língua e o território junto com o characterset, tipo
> :
>
> NLS_LANG=AMERICAN_AMERICA.AL32UTF8
>
> Enfim, SE realmente vc fez correto o DUMP vai mostrar isso pra nós..
>
> Aí chegamos no TERCEIRO ponto, outro q que vc não nos diz, que é : testes
> feitos com sqlplus (OBVIAMENTE com a NLS_LANG setada) . Isso é importante
> porque o characterset no database ** não ** sobrepõe o setting no cliente,
> tranquilamente PODE SER que o teu programa-cliente não esteja trabalhando
> com o characterset correto e alguma conversão com perda esteja acontecendo :
> o sqlplus é facilmente ajustado com as vars de ambiente em linha de comando,
> por isso sugeri estes testes...
>
> Quanto ao assistente de migração : eu não o uso (prefiro sempre fazer a
> migração via linha de comando, controlando o processo em detalhes), mas sei
> que num banco Oracle ** necessariamente ** os datafiles TEM que estarem
> locais, diretamente acessíveis pelo servidor , absolutamente Não Há como vc
> migrar (e nem sequer abrir) um database aonde os datafiles estão remotos, em
> princípio Sendo assim se vc fosse migrar esse banco os arquivos TERIAM
> que ser copiados até o novo servidor, NÂO TEM COMO o novo servidor
> 'enxergar' os arquivos lá na outra máquina, ok ? Em tese vc até poderia
> montar um Samba/NFS para fazer o servidor 10g 'pensar' que os arquivos são
> locais, mas isso é uma gambi danada, não recomendaria, é mesmo copiar os
> arqs pro local definitivo em que eles ficam...
>
> []s
>
> Chiappa
>
>  
>


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

Re: [oracle_br] Re: Migração de banco de Oracle 9i para Oracle 10g - criação e remoção de parâmetros

[Fernando Mariano]

jlchiappa realmente foi um erro de digitação o = e * a mais... :). A string
não possui acentos são apenas números.
Em relação a versão do Oracle, no site para linux na arquitetura x86_64 só
existe a versão 10.2.0.1 para baixar, vou verificar se existe o patch no
metalink...

Bom tive pesquisando mais um pouco na internet e descobri uma variável a ser
setada antes do export do banco de dados. Com ela o character set do export
é realizado de acordo com o que foi configurado no banco de dados.

Para fazer o export fiz o seguinte:

*export NLS_LANG=.AL32UTF8
exp erp/se...@dberp TABLESPACES=ERP FILE=erp_9.2.0.4.dmp LOG=erp_9.2.0.4.log
*

E na hora de fazer o import na outra máquina:

*export NLS_LANG=.AL32UTF8
imp system/ise...@erp full=yes file=erp_9.2.0.4.dmp log=erp_import_9204.log*

Desta forma a mensagem de conversão abaixo não aparece mais no export e nem
no import:

*Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses AL32UTF8 character set (possible charset conversion)*

Após a utilização da variável NLS_LANG, a única mensagem que aparece é a
seguinte no exp e imp.

*import done in AL32UTF8 character set and AL16UTF16 NCHAR character set*

Tanto a importação quanto a exportação apresentam a mensagem no final da
execução do comando.

*Import terminated successfully without warnings.

*Em relação a configuração de character set do banco 9i e 10g eles estão
iguais. Salvei a query *"select * from nls_database_parameters;" **através
do comando spool e depois fiz um diff entre os arquivos. A única diferença
foi a versão do banco de dados, vejam:

r...@sfera:/home/fernando/tmp/oracle# diff charsetOracle9i.txt
charsetOracle10g.txt
95c95
<
9.2.0.4.0

---
> 10.2.0.1.0

*Até agora fiz a migração do banco através dos comandos exp e imp. Sei que
existe o dbua para migração dos dados, tentei utiliza-lo porém não consegui
fazer ele exergar a base no meu outro servidor com Oracle 9i. É possível
migrar um banco de dados 9i que está em um outro servidor ?

Caso alguém tenha alguma sugestão... fico agradecido.



Abraço*
Fernando


*











2009/10/14 jlchiappa 

>
>
> Bem, imagino que o '=' e o '*' a mais na tua msg é defeito do seu programa
> de emails, o que digo sobre a pergunta é : não, isso NÃO faz sentido,
> rigorosamente NÂO EXISTE diferença alguma entre o LIKE do 9i e do 10g :
>
> SQL*Plus: Release 9.2.0.8.0 - Production
> Conectado a:
> Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
>
> SQL> select empno, ename, sal from emp;
>
> EMPNO ENAME SAL
> -- -- --
> 7369 SMITH 800
> 7788 SCOTT 3000
> 
>
> SQL> select empno, ename, sal from emp where ename like 'SMITH';
>
> EMPNO ENAME SAL
> -- -- --
> 7369 SMITH 800
>
> e no 10g :
>
> SQL*Plus: Release 10.2.0.4.0 - Production
> Conectado a:
> Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
>
> sc...@o10gr2:SQL>select empno, ename, sal from emp;
>
> EMPNO ENAME SAL
> -- -- --
> 7369 SMITH 800
> 7499 ALLEN 1600
> 
>
> sc...@o10gr2:SQL>select empno, ename, sal from emp where ename like
> 'SMITH';
>
> EMPNO ENAME SAL
> -- -- --
> 7369 SMITH 800
>
> sei que teve n+1! bugzinhos no 10.2.0.1, rigorosamente ** não ** faz o
> menor sentido migrar pra ele , o 10.2.0.4 é o recomendado mas afaik nenhum
> deles interfere com like, não Pra mim foi falha tua no export/import
> (não setou o characterset correto na linha de comando na hora de fazer o
> exp, talvez, e tem acentos/caracteres especiais na string ?), ou há espaços
> em branco antes e depois da string... Faz um dump da coluna pra ver o que tá
> efetivamente gravado lá dentro, faça os testes via sqlplus e veja o que vc
> vai ver...
>
>
> []s
>
> Chiappa
> --- Em oracle_br@yahoogrupos.com.br ,
> Fernando Mariano  escreveu
> >
> > Pessoal,
> >
> > consegui realizar a migração do Oracle 9i para Oracle 10g. Vejam a
> mensagem
> > abaixo após executar o @utlu102i.sql no Oracle 10g.
> >
> > --
> > *
> > SQL> @utlu102i.sql
> > Oracle Database 10.2 Upgrade Information Utility 10-30-2009 22:07:51
> > .
> > **
> > Database:
> > **
> > --> name: ERP
> > --> version: 10.2.0.1.0
> > --> compatible: 10.2.0.1.0
> > .
> > Database already upgraded; to rerun upgrade use rdbms/admin/catupgrd.sql.
> >
> > PL/SQL procedure successfully completed.
> > *
> > --
> >
> > Porém tem um problema, tem uma query que executo em meu servidor Oracle
> 9i
> > que funciona corretamente, mas no Oracle 10g na clausula where em um
> campo
> > do tipo char eu preciso adicionar o % para funcionar:
> >
> > Por exemplo:
> > *Isto funciona no Oracle 9i:
> > select * from TABELA where CAMPOCHAR like ='STRING';*
> >
> >

Re: [oracle_br] Re: Migração de banco de Oracle 9i para Oracle 10g - criação e remoção de parâmetros

[Fernando Mariano]

Pessoal,

consegui realizar a migração do Oracle 9i para Oracle 10g. Vejam a mensagem
abaixo após executar o @utlu102i.sql no Oracle 10g.

--
*
SQL> @utlu102i.sql
Oracle Database 10.2 Upgrade Information Utility10-30-2009 22:07:51
.
**
Database:
**
--> name:ERP
--> version:10.2.0.1.0
--> compatible: 10.2.0.1.0
.
Database already upgraded; to rerun upgrade use rdbms/admin/catupgrd.sql.

PL/SQL procedure successfully completed.
*
--

Porém tem um problema, tem uma query que executo em meu servidor Oracle 9i
que funciona corretamente, mas no Oracle 10g na clausula where em um campo
do tipo char eu preciso adicionar o % para funcionar:

Por exemplo:
*Isto funciona no Oracle 9i:
select * from TABELA where CAMPOCHAR like ='STRING';*


*Para funcionar no Oracle 10g Rg eu preciso fazer o seguinte:
select * from TABELA where CAMPOCHAR like ='%STRING%';*

Ou seja preciso adicionar o % para que a query funcione. Alguém tem alguma
idéia do que pode ter acontecido ? Isto é uma caracterisca do "like" do
Oracle 10g ?

O estranho que quando fiz o import para o Oracle 10g o comando me deu a
seguinte mensagem:

.
.
.
. . importing table   "WFA990"  0 rows imported
. . importing table   "ZZC020"371 rows imported
Import terminated successfully without warnings.


Não tenho idéia de como resolver este problema... Alguma segestão pessoal ?


Obrigado
Fernando


2009/10/14 jlchiappa 

>
>
> >> Segundo as mensagem acima preciso adicionar o parâmetro
> "streams_pool_size" no meu banco de dados no Oracle 9i,
>
> não, não, não : os parâmetros ajustáveis de databases Oracle *** não ***
> ficam 'dentro do banco' , e sim em ARQUIVOS EXTERNOS, que vc PODE SIM
> alterar (fazendo cópia antes é claro)... O que o script está te dizendo é
> que QUANDO vc for migrar o ARQUIVO EXTERNO com os params que vc for usar
> para inicializar a instãncia 10g deverá ter o tal parâmetro presente, é
> isso Esses arquivos podem ser do tipo TEXTO (os chamados pfiles), que vc
> simplesmente edita com um editor de textos ASCII puro, ou podem ser
> binários, caso em que vc os edita com a instância 9i ativa usando os
> comandos ALTER próprios : meu conselho é que vc se hoje tem spfiles no 9i
> crie um pfile texto com o comando CREATE PFILE e use esse como o arquivo
> externo de params da instância 10g
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br ,
> Fernando Mariano  escreveu
>
> >
> > Pessoal,
> >
> > estou realizando a migração de um banco Oracle na seguinte
> plaforma/sistema:
> >
> > Origem:
> > Suse enterprise Linux 9 (i586)
> > Oracle 9i (9.2.0.4)
> >
> > Destino:
> > Suse enterprise Linux 10 (x86_64)
> > Oracle 10g Release 2
> >
> > Antes de realizar a migração dos dados tive que realizar o upgrade do
> Oracle
> > 9.2.0.1 para o 9.2.0.4, isso até que foi tranquilo. Porém, agora estou no
> > passo da execução do script utlu102i.sql para verificar as pendências a
> > serem realizadas antes do "transporte dos dados":
> >
> > O script me da a seguinte mensagem:
> >
> > SQL> @utlu102i.sql
> > Oracle Database 10.2 Upgrade Information Utility 10-14-2009 12:24:26
> > .
> > **
> > Database:
> > **
> > --> name: DBICARO
> > --> version: 9.2.0.4.0
> > --> compatible: 9.2.0.0.0
> > **
> > Update Parameters: [Update Oracle Database 10.2 init.ora or spfile]
> > **
> > WARNING: --> "streams_pool_size" is not currently defined and needs a
> value
> > of
> > at least 50331648
> > .
> > **
> > Obsolete Parameters: [Update Oracle Database 10.2 init.ora or spfile]
> > **
> > --> "hash_join_enabled"
> > .
> >
> > Segundo as mensagem acima preciso adicionar o parâmetro
> "streams_pool_size"
> > no meu banco de dados no Oracle 9i, porém não encontrei nenhuma forma de
> > adiciona-lo.
> > Pesquisando na internet descobri que o parâmetro "streams_pool_size" não
> > existe no Oracle 9i [1][2]. A pergunta é: como eu faço para adicionar
> este
> > parâmetro e remover o parâmetro "hash_join_enabled" que está obsoleto ?
> >
> > Apenas para constar estou seguindo o tópico de migração da página:
> >
> http://download.oracle.com/docs/cd/B19306_01/server.102/b14238/upgrade.htm#CACHIDJD
> >
> > [1] http://www.orafaq.com/parms/parm1952.htm
> > [2]
> http://www.juliandyke.com/Internals/Parameters/streams_pool_size.html
> >
> >
> > Quem puder m

Re: [oracle_br] Re: migração

[Willian Fernando Frasson]

Tem janela? se tiver faça assim:

1) Faça um backup Full do Banco

2) Pare o banco

2) Copie os datafiles para o storage

3) Faça o rename dos datafiles apontando para o storage
(alter database rename file 'local_antigo/arquivo.dbf' to 
'local_novo/arquivo.dbf')


  - Original Message - 
  From: candiurudba 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Tuesday, May 05, 2009 2:24 PM
  Subject: [oracle_br] Re: migração






  Particularmente, eu usaria o seguinte 

  alter tablespace x offline;

  ! cp old.dbf new.dbf

  alter tablespace x
  rename datafile 'old.dbf' to 'new.dbf';

  alter tablespace x online;

  Apenas, por favor, garanto um backup Ok no caso de algum problema... ;-)

  --- Em oracle_br@yahoogrupos.com.br, Fabio Cesario  escreveu
  >
  > Bom dia a todos, gostaria de saber que procedimento devo adotar para migrar
  > uma base inteira de produção para o storage, pois hoje o banco é salvo
  > localmente no servidor, oracle 10g, não utilizo ASM.
  > Obrigado
  > 
  > 
  > [As partes desta mensagem que não continham texto foram removidas]
  >



  


--



  O Banco de Dados de Vírus interno expirou.
  Verificado por AVG - http://www.avgbrasil.com.br 
  Versão: 8.0.233 / Banco de dados de vírus: 270.10.16/1926 - Data de 
Lançamento: 30/1/2009 17:31


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

Re: [oracle_br] Re: Migração para Storage !!

[Mosan Santos]

Oi;
 
  Antes de responder sua pergunta, passando o script, me diz o seguinte:
 
    Está migrando para ASM ou OCFS?
 
 
Abs


Mosán Santos 
__

OCP DBA 10g   - OCE SQL
OCE   Managing  Oracle on Linux
OCA DBA 10g   -  OCA PL/SQL 
FCP Master  - FCP Fundamental 
CCNA  - JNCIA-ER 
OCE RAC. ..LOAD
__


--- Em qua, 25/3/09, amorrimm  escreveu:

De: amorrimm 
Assunto: [oracle_br] Re: Migração para Storage !!
Para: oracle_br@yahoogrupos.com.br
Data: Quarta-feira, 25 de Março de 2009, 11:16






Grande Mosán, tudo certinho ??

Na verdade estou pensando em utilizar o Rman para iniciar atividades de 
monitoramento por aqui...acho uma excelente ferramenta.. .

Só fiquei na dúvida do seguinte...apó s o backup via Rman de todos os 
datafiles, ainda precisarei alterar o controlfile correto ? Gero um 
ceontrolfile to trace e em seguida altero na mão, ou tem alguma feature no rman 
que eu possa restaurar meu backup para qualquer lugar e ele mesmo já altera meu 
controlfile ??

--- Em oracle...@yahoogrup os.com.br, Mosan Santos  escreveu
>
> 
> Colega;
>  
>  Já pensou usar o RMAN?
>  
> Abs
> 
> Mosán Santos 
>  _ _
> 
> OCP DBA 10g   - OCE SQL
> OCE   Managing  Oracle on Linux
> OCA DBA 10g   -  OCA PL/SQL 
> FCP Master  - FCP Fundamental 
> CCNA  - JNCIA-ER 
> OCE RAC. ..LOAD
>  _ _
> 
> 
> --- Em qua, 25/3/09, amorrimm  escreveu:
> 
> De: amorrimm 
> Assunto: [oracle_br] Migração para Storage !!
> Para: oracle...@yahoogrup os.com.br
> Data: Quarta-feira, 25 de Março de 2009, 10:41
> 
> 
> 
> 
> 
> 
> Bom dia pessoal...
> 
> Estou estudando uma melhor forma de migrar meus dados para uma storage 
> recentemente adquirida... e fiquei na dúvida de qual método utilizar...
> 
> Como não precisarei reinstalar o Oracle (o servidor continuara sendo o 
> mesmo), talvez eu use o tradicional EXDP / IMPDP...alguem teria alguma otra 
> sugestão ?
> 
> Fico meio receoso de utilizar o Datapump pois com relação aos grants de 
> objetos, sempre tive problemas na importação...eles perdem a referêcia...
> 
> A não ser que eu exporte somente os dados, sem os grants, faça a importação e 
> em seguida importe somente os grants...achoque desta forma não teria 
> problemas pois os objetos referenciados já estariam na base de dados...
> 
> Alguem teria alguma outroa sugestão ?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbusca dos.yahoo. com
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

















  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

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

Re: [oracle_br] Re: Migração 10.2.0.4

[Rodrigo Almeida]

Olá,

Nesse blog dá os passos para realizar o RELOAD do JVM.

http://profissionaloracle.com.br/blogs/drbs/2009/01/26/ora-29532/

Abraços,
Rodrigo Almeida

2009/2/2 Anderson 

>   Gari Einsfeldt, o patch baixado é o indicado pelo Metalink para
> Linux-086, que é o nosso caso (p6810189_10204_Linux-x86.zip).
>
> Mas vou pesquisar as notas mencionadas por você e informarei os
> resultados assim que fizermos novos testes.
>
> --- Em oracle_br@yahoogrupos.com.br , Gari
> Einsfeldt 
> escreveu
>
> >
> > Ja vi estes negócio de executáveis "sumirem".
> > Realmente os arquivos ficam zerados.
> >
> > Mas por acaso não estás tentando instalar uma mídia para uma plataforma
> > diferente da que estás? Exemplos: PA-RISC sobre Itanium ou 32 bits
> para 64
> > bits ou algo do gênero?
> >
> > Aqui migramos da 9i (9.2.0.6) para a 10g (10.2.0.4) e também tivemos
> > problemas com a JVM. O que fizemos foi desinstalar a JVM e reinstalá-la.
> > Scripts:
> > ?/javavm/install/initjvm.sql;
> > ?/xdk/admin/initxml.sql;
> > ?/xdk/admin/xmlja.sql;
> > ?/rdbms/admin/catjava.sql;
> > Tivemos que fazer também alguns ajustes nos parametros java_pool_size e
> > shared_pool.
> >
> > Dê uma olhada nas notas do metalink: ]
> > 133391.1
> > 156477.1
> > 159801.1
> > 149393.1
> > 204935.1
> > 316889.1
> >
> >
> > 2009/1/29 Rodrigo Almeida 
> >
> > > Olá Anderson,
> > >
> > > O problema que tivemos os executáveis não sumiram, somente teve
> problemas
> > > com os pacotes DBMS_JAVA e isso implicito em diversos problemas.
> > >
> > > Fizemos alguns relinks nas libs do Oracle e RELOAD do JVM que
> funcionou...
> > >
> > > Abraços
> > > Rodrigo Almeida
> > >
> > > 2009/1/28 Anderson >
>
> > >
> > > > Na verdade eles estavam todos lá, mas com arquivos zerados (0 Kb).
> > > >
> > > > E foi solicitado para substituir os atuais.
> > > >
> > > > --- Em oracle_br@yahoogrupos.com.br 
>  > > 40yahoogrupos.com.br>,
> > > > "Willian Fernando Frasson"
> > > >  escreveu
> > > >
> > > > >
> > > > > Executáveis que sumiram??
> > > > > No momento de rodar o root.sh pediu para substituir os atuais?
> > > > >
> > > > > - Original Message -
> > > > > From: Anderson
> > > > > To: oracle_br@yahoogrupos.com.br 
>  > > 40yahoogrupos.com.br>
> > > > > Sent: Tuesday, January 27, 2009 5:16 PM
> > > > > Subject: [oracle_br] Re: Migração 10.2.0.4
> > > > >
> > > > >
> > > > > Rodrigo, fizemos testes aqui com aplicação do 10.2.0.4 em RH4
> e também
> > > > > tivemos problemas com os executáveis, que 'sumiram'.
> > > > >
> > > > > Como vocês fizeram pra resolver o problema?
> > > > >
> > > > > --- Em oracle_br@yahoogrupos.com.br
>  > > 40yahoogrupos.com.br>,
> > > > Rodrigo Almeida 
> > > > > escreveu
> > > > > >
> > > > > > Olá,
> > > > > >
> > > > > > Tive problemas em aplicar o Patchset 10.2.0.4 para Linux em
> RedHat
> > > > > ES AS 4
> > > > > > 32Bits saindo do Patchset 10.2.0.3, os problemas foram desde a
> > > > > invalidação
> > > > > > das Packages JAVA até problemas em executáveis. E foi seguida
> > > > todos os
> > > > > > processos da Documentação para atualização.
> > > > > >
> > > > > > Segundo TAR aberto no Metalink, precisamente do 10.2.0.3 para
> > > > > 10.2.0.4 para
> > > > > > Linux Red Hat EL AS4 (Narah) teve problemas na aplicação do CPU.
> > > > > >
> > > > > > Abraços,
> > > > > > Rodrigo Almeida
> > > > > >
> > > > > > 2009/1/27 Willian Frasson 
> > > > > >
> > > > > > > Amigo já apliquei em vários cliente o Patchset 10.2.0.4 e
> não tive
> > > > > > > problemas, com relação a aplicar em RAC, basta aplicar
> primeiro no
> > > > > CRS,
> > > > > > > depois no RDBMS rodando o @catupgrd.sql e recompilar os
> objetos
> > > > > inválidos.
> > > > > > > Mas sempre faça isso em ambiente de homologação, de
> preferência
> 

Re: [oracle_br] Re: Migração 10.2.0.4

[Gari Einsfeldt]

Ja vi estes negócio de executáveis "sumirem".
Realmente os arquivos ficam zerados.

Mas por acaso não estás tentando instalar uma mídia para uma plataforma
diferente da que estás? Exemplos: PA-RISC sobre Itanium ou 32 bits para 64
bits ou algo do gênero?

Aqui migramos da 9i (9.2.0.6) para a 10g (10.2.0.4) e também tivemos
problemas com a JVM. O que fizemos foi desinstalar a JVM e reinstalá-la.
Scripts:
?/javavm/install/initjvm.sql;
?/xdk/admin/initxml.sql;
?/xdk/admin/xmlja.sql;
?/rdbms/admin/catjava.sql;
Tivemos que fazer também alguns ajustes nos parametros java_pool_size e
shared_pool.

Dê uma olhada nas notas do metalink: ]
133391.1
156477.1
159801.1
149393.1
204935.1
316889.1


2009/1/29 Rodrigo Almeida 

>   Olá Anderson,
>
> O problema que tivemos os executáveis não sumiram, somente teve problemas
> com os pacotes DBMS_JAVA e isso implicito em diversos problemas.
>
> Fizemos alguns relinks nas libs do Oracle e RELOAD do JVM que funcionou...
>
> Abraços
> Rodrigo Almeida
>
> 2009/1/28 Anderson >
>
> > Na verdade eles estavam todos lá, mas com arquivos zerados (0 Kb).
> >
> > E foi solicitado para substituir os atuais.
> >
> > --- Em oracle_br@yahoogrupos.com.br 
> >  40yahoogrupos.com.br>,
> > "Willian Fernando Frasson"
> >  escreveu
> >
> > >
> > > Executáveis que sumiram??
> > > No momento de rodar o root.sh pediu para substituir os atuais?
> > >
> > > - Original Message -
> > > From: Anderson
> > > To: oracle_br@yahoogrupos.com.br 
> > >  40yahoogrupos.com.br>
> > > Sent: Tuesday, January 27, 2009 5:16 PM
> > > Subject: [oracle_br] Re: Migração 10.2.0.4
> > >
> > >
> > > Rodrigo, fizemos testes aqui com aplicação do 10.2.0.4 em RH4 e também
> > > tivemos problemas com os executáveis, que 'sumiram'.
> > >
> > > Como vocês fizeram pra resolver o problema?
> > >
> > > --- Em oracle_br@yahoogrupos.com.br 
> > >  40yahoogrupos.com.br>,
> > Rodrigo Almeida 
> > > escreveu
> > > >
> > > > Olá,
> > > >
> > > > Tive problemas em aplicar o Patchset 10.2.0.4 para Linux em RedHat
> > > ES AS 4
> > > > 32Bits saindo do Patchset 10.2.0.3, os problemas foram desde a
> > > invalidação
> > > > das Packages JAVA até problemas em executáveis. E foi seguida
> > todos os
> > > > processos da Documentação para atualização.
> > > >
> > > > Segundo TAR aberto no Metalink, precisamente do 10.2.0.3 para
> > > 10.2.0.4 para
> > > > Linux Red Hat EL AS4 (Narah) teve problemas na aplicação do CPU.
> > > >
> > > > Abraços,
> > > > Rodrigo Almeida
> > > >
> > > > 2009/1/27 Willian Frasson 
> > > >
> > > > > Amigo já apliquei em vários cliente o Patchset 10.2.0.4 e não tive
> > > > > problemas, com relação a aplicar em RAC, basta aplicar primeiro no
> > > CRS,
> > > > > depois no RDBMS rodando o @catupgrd.sql e recompilar os objetos
> > > inválidos.
> > > > > Mas sempre faça isso em ambiente de homologação, de preferência
> > > com a mesma
> > > > > estrutura de SO/banco.
> > > > >
> > > > > Abçs.
> > > > >
> > > > > Willian Frasson
> > > > > Administrador de Banco de Dados Oracle.
> > > > >
> > > > > --- Em seg, 26/1/09, Eduardo
> > > >
> > > > > escreveu:
> > > > > De: Eduardo >
> > > > > Assunto: Re: [oracle_br] Re: Migração 10.2.0.4
> > > > > Para: 
> > > > > oracle_br@yahoogrupos.com.br 40yahoogrupos.com.br>
> > 
> > > > > Data: Segunda-feira, 26 de Janeiro de 2009, 16:14
> > > > >
> > > > >
> > > > > Exato.
> > > > >
> > > > > Eu tenho ambos ambientes aqui. Tanto RAC quanto 10.2.0.3.
> > > > >
> > > > > A única coisa que eu pisei na bola foi tentar aplicar um patch
> > 64 em
> > > > >
> > > > > uma máquina 32.
> > > > >
> > > > > Mas consegui desfazer e refazer da maneira correta e agora ta show
> > > de bola.
> > > > >
> > > > > Dá uma lida na documentação da oracle, ela explica como fazer
> > em RAC.
> > > > >
> > > > > Creio que o tempo que você irá levar será de aproximadamente
> > umas 2
> > &g

Re: [oracle_br] Re: Migração 10.2.0.4

[Rodrigo Almeida]

Olá Anderson,

O problema que tivemos os executáveis não sumiram, somente teve problemas
com os pacotes DBMS_JAVA e isso implicito em diversos problemas.

Fizemos alguns relinks nas libs do Oracle e RELOAD do JVM que funcionou...

Abraços
Rodrigo Almeida

2009/1/28 Anderson 

>   Na verdade eles estavam todos lá, mas com arquivos zerados (0 Kb).
>
> E foi solicitado para substituir os atuais.
>
> --- Em oracle_br@yahoogrupos.com.br ,
> "Willian Fernando Frasson"
>  escreveu
>
> >
> > Executáveis que sumiram??
> > No momento de rodar o root.sh pediu para substituir os atuais?
> >
> > - Original Message -
> > From: Anderson
> > To: oracle_br@yahoogrupos.com.br 
> > Sent: Tuesday, January 27, 2009 5:16 PM
> > Subject: [oracle_br] Re: Migração 10.2.0.4
> >
> >
> > Rodrigo, fizemos testes aqui com aplicação do 10.2.0.4 em RH4 e também
> > tivemos problemas com os executáveis, que 'sumiram'.
> >
> > Como vocês fizeram pra resolver o problema?
> >
> > --- Em oracle_br@yahoogrupos.com.br ,
> Rodrigo Almeida 
> > escreveu
> > >
> > > Olá,
> > >
> > > Tive problemas em aplicar o Patchset 10.2.0.4 para Linux em RedHat
> > ES AS 4
> > > 32Bits saindo do Patchset 10.2.0.3, os problemas foram desde a
> > invalidação
> > > das Packages JAVA até problemas em executáveis. E foi seguida
> todos os
> > > processos da Documentação para atualização.
> > >
> > > Segundo TAR aberto no Metalink, precisamente do 10.2.0.3 para
> > 10.2.0.4 para
> > > Linux Red Hat EL AS4 (Narah) teve problemas na aplicação do CPU.
> > >
> > > Abraços,
> > > Rodrigo Almeida
> > >
> > > 2009/1/27 Willian Frasson 
> > >
> > > > Amigo já apliquei em vários cliente o Patchset 10.2.0.4 e não tive
> > > > problemas, com relação a aplicar em RAC, basta aplicar primeiro no
> > CRS,
> > > > depois no RDBMS rodando o @catupgrd.sql e recompilar os objetos
> > inválidos.
> > > > Mas sempre faça isso em ambiente de homologação, de preferência
> > com a mesma
> > > > estrutura de SO/banco.
> > > >
> > > > Abçs.
> > > >
> > > > Willian Frasson
> > > > Administrador de Banco de Dados Oracle.
> > > >
> > > > --- Em seg, 26/1/09, Eduardo
> > >
> > > > escreveu:
> > > > De: Eduardo >
> > > > Assunto: Re: [oracle_br] Re: Migração 10.2.0.4
> > > > Para: oracle_br@yahoogrupos.com.br 
> 
> > > > Data: Segunda-feira, 26 de Janeiro de 2009, 16:14
> > > >
> > > >
> > > > Exato.
> > > >
> > > > Eu tenho ambos ambientes aqui. Tanto RAC quanto 10.2.0.3.
> > > >
> > > > A única coisa que eu pisei na bola foi tentar aplicar um patch
> 64 em
> > > >
> > > > uma máquina 32.
> > > >
> > > > Mas consegui desfazer e refazer da maneira correta e agora ta show
> > de bola.
> > > >
> > > > Dá uma lida na documentação da oracle, ela explica como fazer
> em RAC.
> > > >
> > > > Creio que o tempo que você irá levar será de aproximadamente
> umas 2
> > > >
> > > > horas por nó, no máximo 4 horas.
> > > >
> > > > Isso vai depender da sua experiência e da velocidade da máquina.
> > > >
> > > > Inté
> > > >
> > > > 2009/1/26 antonio_luiz3 :
> > > >
> > > > > Valeu Eduardo! Seu ambiente estava em RAC ou single instance?
> > > >
> > > > > Tenho que planejar a atualização de nosso ambiente de 10.2.0.3
> > em RAC.
> > > >
> > > > > Essa atualização é necessária para correção de bugs.
> > > >
> > > > >
> > > >
> > > > > --- Em oracle...@yahoogrup os.com.br, Eduardo
> 
> > > > escreveu
> > > >
> > > > >
> > > >
> > > > >>
> > > >
> > > > >> Migrar de onde para onde?
> > > >
> > > > >>
> > > >
> > > > >> Eu migrei da 10.2.0.2 para 10.2.0.4 e foi tranquilo.
> > > >
> > > > >> Nenhum erro, tudo explicado pelo manual da oracle.
> > > >
> > > > >>
> > > >
> > > > >> Té
> > > >
> > > > >>
> > > >
> > > > >> 2009/1/26 a

Re: [oracle_br] Re: Migração 10.2.0.4

[Willian Fernando Frasson]

Executáveis que sumiram??
No momento de rodar o root.sh pediu para substituir os atuais?

  - Original Message - 
  From: Anderson 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Tuesday, January 27, 2009 5:16 PM
  Subject: [oracle_br] Re: Migração 10.2.0.4


  Rodrigo, fizemos testes aqui com aplicação do 10.2.0.4 em RH4 e também
  tivemos problemas com os executáveis, que 'sumiram'.

  Como vocês fizeram pra resolver o problema?

  --- Em oracle_br@yahoogrupos.com.br, Rodrigo Almeida 
  escreveu
  >
  > Olá,
  > 
  > Tive problemas em aplicar o Patchset 10.2.0.4 para Linux em RedHat
  ES AS 4
  > 32Bits saindo do Patchset 10.2.0.3, os problemas foram desde a
  invalidação
  > das Packages JAVA até problemas em executáveis. E foi seguida todos os
  > processos da Documentação para atualização.
  > 
  > Segundo TAR aberto no Metalink, precisamente do 10.2.0.3 para
  10.2.0.4 para
  > Linux Red Hat EL AS4 (Narah) teve problemas na aplicação do CPU.
  > 
  > Abraços,
  > Rodrigo Almeida
  > 
  > 2009/1/27 Willian Frasson 
  > 
  > > Amigo já apliquei em vários cliente o Patchset 10.2.0.4 e não tive
  > > problemas, com relação a aplicar em RAC, basta aplicar primeiro no
  CRS,
  > > depois no RDBMS rodando o @catupgrd.sql e recompilar os objetos
  inválidos.
  > > Mas sempre faça isso em ambiente de homologação, de preferência
  com a mesma
  > > estrutura de SO/banco.
  > >
  > > Abçs.
  > >
  > > Willian Frasson
  > > Administrador de Banco de Dados Oracle.
  > >
  > > --- Em seg, 26/1/09, Eduardo
  >
  > > escreveu:
  > > De: Eduardo >
  > > Assunto: Re: [oracle_br] Re: Migração 10.2.0.4
  > > Para: oracle_br@yahoogrupos.com.br 
  > > Data: Segunda-feira, 26 de Janeiro de 2009, 16:14
  > >
  > >
  > > Exato.
  > >
  > > Eu tenho ambos ambientes aqui. Tanto RAC quanto 10.2.0.3.
  > >
  > > A única coisa que eu pisei na bola foi tentar aplicar um patch 64 em
  > >
  > > uma máquina 32.
  > >
  > > Mas consegui desfazer e refazer da maneira correta e agora ta show
  de bola.
  > >
  > > Dá uma lida na documentação da oracle, ela explica como fazer em RAC.
  > >
  > > Creio que o tempo que você irá levar será de aproximadamente umas 2
  > >
  > > horas por nó, no máximo 4 horas.
  > >
  > > Isso vai depender da sua experiência e da velocidade da máquina.
  > >
  > > Inté
  > >
  > > 2009/1/26 antonio_luiz3 :
  > >
  > > > Valeu Eduardo! Seu ambiente estava em RAC ou single instance?
  > >
  > > > Tenho que planejar a atualização de nosso ambiente de 10.2.0.3
  em RAC.
  > >
  > > > Essa atualização é necessária para correção de bugs.
  > >
  > > >
  > >
  > > > --- Em oracle...@yahoogrup os.com.br, Eduardo 
  > > escreveu
  > >
  > > >
  > >
  > > >>
  > >
  > > >> Migrar de onde para onde?
  > >
  > > >>
  > >
  > > >> Eu migrei da 10.2.0.2 para 10.2.0.4 e foi tranquilo.
  > >
  > > >> Nenhum erro, tudo explicado pelo manual da oracle.
  > >
  > > >>
  > >
  > > >> Té
  > >
  > > >>
  > >
  > > >> 2009/1/26 antonio_luiz3 :
  > >
  > > >> > Olá amigos,
  > >
  > > >> >
  > >
  > > >> > Alguém já fez a migração para a versão 10.2.0.4? Podem contar
  suas
  > >
  > > >> > experiências?
  > >
  > > >> >
  > >
  > > >> > Anteciosamente,
  > >
  > > >> >
  > >
  > > >> > Antonio Luiz.
  > >
  > > >> >
  > >
  > > >> >
  > >
  > > >>
  > >
  > > >
  > >
  > > >
  > >
  > >
  > >
  > >
  > >
  > >
  > >
  > >
  > >
  > >
  > >
  > > Veja quais são os assuntos do momento no Yahoo! +Buscados
  > > http://br.maisbuscados.yahoo.com
  > >
  > > [As partes desta mensagem que não continham texto foram removidas]
  > >
  > > 
  > >
  > 
  > 
  > 
  > -- 
  > Rodrigo Almeida
  > DBA Oracle
  > 
  > LinkedIn | http://www.linkedin.com/in/rodrigoalmeida
  > 
  > 
  > [As partes desta mensagem que não continham texto foram removidas]
  >



   


--



  Nenhum vírus encontrado nessa mensagem recebida.
  Verificado por AVG - http://www.avgbrasil.com.br 
  Versão: 8.0.176 / Banco de dados de vírus: 270.10.14/1917 - Data de 
Lançamento: 26/1/2009 18:37


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

Re: [oracle_br] Re: Migração 10.2.0.4

[Willian Frasson]

o 10.2.0.4 / CPU em single instance apliquei e não tive problemas

--- Em ter, 27/1/09, Rodrigo Almeida  escreveu:
De: Rodrigo Almeida 
Assunto: Re: [oracle_br] Re: Migração 10.2.0.4
Para: oracle_br@yahoogrupos.com.br
Data: Terça-feira, 27 de Janeiro de 2009, 11:28











Olá,



Tive problemas em aplicar o Patchset 10.2.0.4 para Linux em RedHat ES AS 4

32Bits saindo do Patchset 10.2.0.3, os problemas foram desde a invalidação

das Packages JAVA até problemas em executáveis. E foi seguida todos os

processos da Documentação para atualização.



Segundo TAR aberto no Metalink, precisamente do 10.2.0.3 para 10.2.0.4 para

Linux Red Hat EL AS4 (Narah) teve problemas na aplicação do CPU.



Abraços,

Rodrigo Almeida



2009/1/27 Willian Frasson 



>   Amigo já apliquei em vários cliente o Patchset 10.2.0.4 e não tive

> problemas, com relação a aplicar em RAC, basta aplicar primeiro no CRS,

> depois no RDBMS rodando o @catupgrd.sql e recompilar os objetos inválidos.

> Mas sempre faça isso em ambiente de homologação, de preferência com a mesma

> estrutura de SO/banco.

>

> Abçs.

>

> Willian Frasson

> Administrador de Banco de Dados Oracle.

>

> --- Em seg, 26/1/09, Eduardo  40gmail.com> >

> escreveu:

> De: Eduardo  >

> Assunto: Re: [oracle_br] Re: Migração 10.2.0.4

> Para: oracle...@yahoogrup os.com.br 

> Data: Segunda-feira, 26 de Janeiro de 2009, 16:14

>

>

> Exato.

>

> Eu tenho ambos ambientes aqui. Tanto RAC quanto 10.2.0.3.

>

> A única coisa que eu pisei na bola foi tentar aplicar um patch 64 em

>

> uma máquina 32.

>

> Mas consegui desfazer e refazer da maneira correta e agora ta show de bola.

>

> Dá uma lida na documentação da oracle, ela explica como fazer em RAC.

>

> Creio que o tempo que você irá levar será de aproximadamente umas 2

>

> horas por nó, no máximo 4 horas.

>

> Isso vai depender da sua experiência e da velocidade da máquina.

>

> Inté

>

> 2009/1/26 antonio_luiz3 :

>

> > Valeu Eduardo! Seu ambiente estava em RAC ou single instance?

>

> > Tenho que planejar a atualização de nosso ambiente de 10.2.0.3 em RAC.

>

> > Essa atualização é necessária para correção de bugs.

>

> >

>

> > --- Em oracle...@yahoogrup os.com.br, Eduardo 

> escreveu

>

> >

>

> >>

>

> >> Migrar de onde para onde?

>

> >>

>

> >> Eu migrei da 10.2.0.2 para 10.2.0.4 e foi tranquilo.

>

> >> Nenhum erro, tudo explicado pelo manual da oracle.

>

> >>

>

> >> Té

>

> >>

>

> >> 2009/1/26 antonio_luiz3 :

>

> >> > Olá amigos,

>

> >> >

>

> >> > Alguém já fez a migração para a versão 10.2.0.4? Podem contar suas

>

> >> > experiências?

>

> >> >

>

> >> > Anteciosamente,

>

> >> >

>

> >> > Antonio Luiz.

>

> >> >

>

> >> >

>

> >>

>

> >

>

> >

>

>

>

>

>

>

>

>

>

>

>

> Veja quais são os assuntos do momento no Yahoo! +Buscados

> http://br.maisbusca dos.yahoo. com

>

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

>

>  

>



-- 

Rodrigo Almeida

DBA Oracle



LinkedIn | http://www.linkedin .com/in/rodrigoa lmeida



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




  




 

















  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

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

Re: [oracle_br] Re: Migração 10.2.0.4

[Rodrigo Almeida]

Olá,

Tive problemas em aplicar o Patchset 10.2.0.4 para Linux em RedHat ES AS 4
32Bits saindo do Patchset 10.2.0.3, os problemas foram desde a invalidação
das Packages JAVA até problemas em executáveis. E foi seguida todos os
processos da Documentação para atualização.

Segundo TAR aberto no Metalink, precisamente do 10.2.0.3 para 10.2.0.4 para
Linux Red Hat EL AS4 (Narah) teve problemas na aplicação do CPU.

Abraços,
Rodrigo Almeida

2009/1/27 Willian Frasson 

>   Amigo já apliquei em vários cliente o Patchset 10.2.0.4 e não tive
> problemas, com relação a aplicar em RAC, basta aplicar primeiro no CRS,
> depois no RDBMS rodando o @catupgrd.sql e recompilar os objetos inválidos.
> Mas sempre faça isso em ambiente de homologação, de preferência com a mesma
> estrutura de SO/banco.
>
> Abçs.
>
> Willian Frasson
> Administrador de Banco de Dados Oracle.
>
> --- Em seg, 26/1/09, Eduardo 
> >
> escreveu:
> De: Eduardo >
> Assunto: Re: [oracle_br] Re: Migração 10.2.0.4
> Para: oracle_br@yahoogrupos.com.br 
> Data: Segunda-feira, 26 de Janeiro de 2009, 16:14
>
>
> Exato.
>
> Eu tenho ambos ambientes aqui. Tanto RAC quanto 10.2.0.3.
>
> A única coisa que eu pisei na bola foi tentar aplicar um patch 64 em
>
> uma máquina 32.
>
> Mas consegui desfazer e refazer da maneira correta e agora ta show de bola.
>
> Dá uma lida na documentação da oracle, ela explica como fazer em RAC.
>
> Creio que o tempo que você irá levar será de aproximadamente umas 2
>
> horas por nó, no máximo 4 horas.
>
> Isso vai depender da sua experiência e da velocidade da máquina.
>
> Inté
>
> 2009/1/26 antonio_luiz3 :
>
> > Valeu Eduardo! Seu ambiente estava em RAC ou single instance?
>
> > Tenho que planejar a atualização de nosso ambiente de 10.2.0.3 em RAC.
>
> > Essa atualização é necessária para correção de bugs.
>
> >
>
> > --- Em oracle...@yahoogrup os.com.br, Eduardo 
> escreveu
>
> >
>
> >>
>
> >> Migrar de onde para onde?
>
> >>
>
> >> Eu migrei da 10.2.0.2 para 10.2.0.4 e foi tranquilo.
>
> >> Nenhum erro, tudo explicado pelo manual da oracle.
>
> >>
>
> >> Té
>
> >>
>
> >> 2009/1/26 antonio_luiz3 :
>
> >> > Olá amigos,
>
> >> >
>
> >> > Alguém já fez a migração para a versão 10.2.0.4? Podem contar suas
>
> >> > experiências?
>
> >> >
>
> >> > Anteciosamente,
>
> >> >
>
> >> > Antonio Luiz.
>
> >> >
>
> >> >
>
> >>
>
> >
>
> >
>
>
>
>
>
>
>
>
>
>
>
> Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  
>



-- 
Rodrigo Almeida
DBA Oracle

LinkedIn | http://www.linkedin.com/in/rodrigoalmeida


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

Re: [oracle_br] Re: Migração 10.2.0.4

[Willian Frasson]

Amigo já apliquei em vários cliente o Patchset 10.2.0.4 e não tive problemas, 
com relação a aplicar em RAC, basta aplicar primeiro no CRS, depois no RDBMS 
rodando o @catupgrd.sql e recompilar os objetos inválidos.
Mas sempre faça isso em ambiente de homologação, de preferência com a mesma 
estrutura de SO/banco.

Abçs.

Willian Frasson
Administrador de Banco de Dados Oracle.



--- Em seg, 26/1/09, Eduardo  escreveu:
De: Eduardo 
Assunto: Re: [oracle_br] Re: Migração 10.2.0.4
Para: oracle_br@yahoogrupos.com.br
Data: Segunda-feira, 26 de Janeiro de 2009, 16:14











Exato.

Eu tenho ambos ambientes aqui. Tanto RAC quanto 10.2.0.3.



A única coisa que eu pisei na bola foi tentar aplicar um patch 64 em

uma máquina 32.

Mas consegui desfazer e refazer da maneira correta e agora ta show de bola.

Dá uma lida na documentação da oracle, ela explica como fazer em RAC.

Creio que o tempo que você irá levar será de aproximadamente umas 2

horas por nó, no máximo 4 horas.

Isso vai depender da sua experiência e da velocidade da máquina.



Inté



2009/1/26 antonio_luiz3 :

> Valeu Eduardo! Seu ambiente estava em RAC ou single instance?

> Tenho que planejar a atualização de nosso ambiente de 10.2.0.3 em RAC.

> Essa atualização é necessária para correção de bugs.

>

> --- Em oracle...@yahoogrup os.com.br, Eduardo  escreveu

>

>>

>> Migrar de onde para onde?

>>

>> Eu migrei da 10.2.0.2 para 10.2.0.4 e foi tranquilo.

>> Nenhum erro, tudo explicado pelo manual da oracle.

>>

>> Té

>>

>> 2009/1/26 antonio_luiz3 :

>> > Olá amigos,

>> >

>> > Alguém já fez a migração para a versão 10.2.0.4? Podem contar suas

>> > experiências?

>> >

>> > Anteciosamente,

>> >

>> > Antonio Luiz.

>> >

>> >

>>

>

> 


  




 

















  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

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

Re: [oracle_br] Re: Migração 10.2.0.4

[Hugo Abe]

2009/1/26 Eduardo 

>   Exato.
> Eu tenho ambos ambientes aqui. Tanto RAC quanto 10.2.0.3.
>
> A única coisa que eu pisei na bola foi tentar aplicar um patch 64 em
> uma máquina 32.
> Mas consegui desfazer e refazer da maneira correta e agora ta show de bola.
> Dá uma lida na documentação da oracle, ela explica como fazer em RAC.
> Creio que o tempo que você irá levar será de aproximadamente umas 2
> horas por nó, no máximo 4 horas.
> Isso vai depender da sua experiência e da velocidade da máquina.
>
> Inté
>
> 2009/1/26 antonio_luiz3 
> >:
>
> > Valeu Eduardo! Seu ambiente estava em RAC ou single instance?
> > Tenho que planejar a atualização de nosso ambiente de 10.2.0.3 em RAC.
> > Essa atualização é necessária para correção de bugs.
> >
> > --- Em oracle_br@yahoogrupos.com.br ,
> Eduardo  escreveu
> >
> >>
> >> Migrar de onde para onde?
> >>
> >> Eu migrei da 10.2.0.2 para 10.2.0.4 e foi tranquilo.
> >> Nenhum erro, tudo explicado pelo manual da oracle.
> >>
> >> Té
> >>
> >> 2009/1/26 antonio_luiz3 :
> >> > Olá amigos,
> >> >
> >> > Alguém já fez a migração para a versão 10.2.0.4? Podem contar suas
> >> > experiências?
> >> >
> >> > Anteciosamente,
> >> >
> >> > Antonio Luiz.
> >> >
> >> >
> >>
> >
> >
>  
>



-- 
Hugo Abe
(91) 81184107


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

Re: [oracle_br] Re: Migração 10.2.0.4

[Eduardo]

Exato.
Eu tenho ambos ambientes aqui. Tanto RAC quanto 10.2.0.3.

A única coisa que eu pisei na bola foi tentar aplicar um patch 64 em
uma máquina 32.
Mas consegui desfazer e refazer da maneira correta e agora ta show de bola.
Dá uma lida na documentação da oracle, ela explica como fazer em RAC.
Creio que o tempo que você irá levar será de aproximadamente umas 2
horas por nó, no máximo 4 horas.
Isso vai depender da sua experiência e da velocidade da máquina.

Inté

2009/1/26 antonio_luiz3 :
> Valeu Eduardo! Seu ambiente estava em RAC ou single instance?
> Tenho que planejar a atualização de nosso ambiente de 10.2.0.3 em RAC.
> Essa atualização é necessária para correção de bugs.
>
> --- Em oracle_br@yahoogrupos.com.br, Eduardo  escreveu
>
>>
>> Migrar de onde para onde?
>>
>> Eu migrei da 10.2.0.2 para 10.2.0.4 e foi tranquilo.
>> Nenhum erro, tudo explicado pelo manual da oracle.
>>
>> Té
>>
>> 2009/1/26 antonio_luiz3 :
>> > Olá amigos,
>> >
>> > Alguém já fez a migração para a versão 10.2.0.4? Podem contar suas
>> > experiências?
>> >
>> > Anteciosamente,
>> >
>> > Antonio Luiz.
>> >
>> >
>>
>
> 

Re: [oracle_br] Re: migração oracle9i

[Mauricio Françoso]

Chiappa,
 
A parte tecnica para a migração eu já tenho pronto, preciso de uma apresentação 
para os leigos, 
 
obrigado.


Mauricio do C. Françoso 
Liberty Seguros 
Administrador Banco de Dados(DBA ORACLE)

--- Em sex, 28/11/08, jlchiappa <[EMAIL PROTECTED]> escreveu:

De: jlchiappa <[EMAIL PROTECTED]>
Assunto: [oracle_br] Re: migração oracle9i
Para: oracle_br@yahoogrupos.com.br
Data: Sexta-feira, 28 de Novembro de 2008, 22:16






Coincidentemente, eu estou alocado num cliente externo já há algumas
semanas, justamente fazendo um trabalho de upgrade 9i => 10g (no caso
beeem complexo porque o pessoal lá tem EBS, ERP, dúzias de softwares
add-ons ao EBS e/ou terceiros), e sem a menor dúvida a ** melhor **
documentação foi/está sendo a nota metalink número 466181.1
Subject:10g Upgrade Companion, ela centraliza basicamente TODA a info
necessária, dá sugestão de procedimento, mostra links para docs
derivados (tais como docs de bugs, novas features, alterações), é um
documento vital pra quem está fazendo upgrade para 10g... ** ÓBVIO **
que :

a) também li com cuidado o manual de Upgrade

b) ao escolher o tipo de migração (manual no meu caso, não confiei na
gui já que eu queria realmente ter controle absoluto sobre cada passo,
receber diretamente na tela as eventuais msgs, etc), segui a nota
metalink referente ao tipo escolhido, citada no Companion

c) insisti mUITO com o cliente para que REALMENTE fosse cronogramado
um período de tempo para ANÁLISE e LEVANTAMENTO dos softwares
instalados, o que era produtos Oracle eu revi no metalink os
documentos, os não-Oracle os DBAs do cliente entraram em contato com o
Suporte deles, reviram documentação, etc : isso foi ** CRUCIAL ** para
que eu pudesse montar um roteiro, baixar os patches, saber se
derivados do banco (como Client Oracle, utilitários, tools de
programaão, etc) teriam que ser alterados ou não

[]s

Chiappa

 = = = = = = 
Palestrante ENPO.BR - acesse http://www.enpo- br.org/
Instrutor Workshops ENPO/TWS - acesse http://www.twstecno logia.com. br/
Agora Blogando em www.ora600.com. br
 = = = = = = 

"Admira-se o talento, a coragem, a bondade, as grandes dedicações e as
provas difíceis, mas só temos consideração pelo dinheiro." (Nicolas
Chamfort)
--- Em [EMAIL PROTECTED] os.com.br, Mauricio Françoso <[EMAIL PROTECTED] ..>
escreveu
>
>  
> 
> 
> 
> 
> 
> 
> Boa tarde pessoal,
>  
> Alguem teria uma documentação completa sobre planejamento para
migração do oracle9i para oracle10g?
> Passos a serem seguidos, cuidados, melhorias, problemas encontrados
etc...
>  
> SO= Solaris 9
>  
> obrigado.
> 
> 
> Mauricio do C. Françoso 
> Liberty Seguros 
> Administrador Banco de Dados(DBA ORACLE)
> 
> 
> Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10 -
Celebridades - Música - Esportes
> 
> 
> Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbusca dos.yahoo. com
> 
> [As partes desta mensagem que não continham texto foram removidas]
>

 














  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

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

Re: [oracle_br] Re: MIGRAÇÃO ORACLE X S YBASE

[Reginaldo Ribeiro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eu concordo com os demais, no sentido de que você pode obter algum
progresso analisando sua ferramenta de migração. Por falar nisso, qual
é ela? Para ilustrar, tive um problema semelhante recentemente,
migrando dados do mysql para oracle utilizando sql developer. Todos os
dados que continham acentuação foram marcados com caracteres ansi. A
solução estava no prório sql developer. Como eram poucos dados de
poucas tabelas, tive a oportunidade de verificá-los antes de efetuar a
transferência. Nas preferências do raptor, setei o encoding para iso e
tudo funcionou perfeitamente. Detalhe: o sql developer também faz este
tipo de migração. Poderia dar uma olhada nele também.


Ribeiro, Reginaldo
Administrador de Bancos de Dados
Oracle Certified Associate 10g
- 
DBCom Brazil Consultoria em Tecnologia da Informação
skype: rflribeiro
mobile: 551192344290
fone: 551135225172
e-mail: [EMAIL PROTECTED]
site: http://www.dbcom.com.br
Chave Pública:
http://keyserver.noreply.org/pks/lookup?search=rflribeiro%40dbcom.com.br&fingerprint=on&op=index



amorrimm wrote:
>
> Grande Jlchiappa,
>
> Então...o character set é mesmo CP850. Dei uma olhadinha la no
> Sybase e verifiquei nesta mesma página que você informou:
>
> Language Group Group 1 Albanian, Catalan, Danish, Dutch, English,
> Faeroese, Finnish, French, Galician, German, Icelandic, Irish,
> Italian, Norwegian, Portuguese, Spanish, Swedish
>
> Character Set ASCII 8, CP 437, CP 850, CP 860, CP 1252, ISO 8859-1,
> ISO 8859-15, Macintosh Roman, ROMAN8
>
> Já alterei os character set do Oracle e nada...ainda tentando...
>
> abração
>
>
> --- Em oracle_br@yahoogrupos.com.br
> , "jlchiappa"
> <[EMAIL PROTECTED]> escreveu
>>
>> Pode muito bem ser, mas além disso (apesar de eu não conhecer
>> PATAVINA CHOCA nenhuma de Sybase), alguma coisa lá na resposta do
>> colega me soa mal : codepage (cfrme a minha experiência e também
>> registrado em http://en.wikipedia.org/wiki/Code_page
>  e em
>> http://en.wikipedia.org/wiki/Code_page_850
> ) , é DIFERENTE de
> encondig
>> schema e CHARACTERSET, além do que basicamente codepages foram
>> introduzidos no MS-DOS, e afaik Sybase *** não é *** uma
>> aplicação DOS... Então acho que a informação passada lá pelo
>> colega está ABSOLUTAMENTE incompleta, tem que existir uma
>> "propriedade" do banco indicando o encoding schema, o
>> CHARACTERSET, a LINGUAGEM, o alfabeto, o Calendário, etc, desse
>> banco... Uma googlada ultra-rápida me fez cair no tal do "Sybase
>> Character Sets User's Guide" em
>> http://manuals.sybase.com/onlinebooks/group-
> 
> charc/chg0300e/charsets/@Generic__BookTextView/7152
>> , que parece indicar que o Sybase usa um arquivo de init e na
>> entrada LOCALE é que tem o resto todo das infos.
>>
>> Recomendo que o colega q perguntou *** CHEQUE ** direitinho a
>> infomação completa, para aí sim poder contrastar com o bd Oracle,
>> além da questão de ter CERTINHO o ambiente setado, se for usada
>> tool de texto pra carregar os dados (como o sql*loader, o
>> sqlplus, o import, etc) se certificar do codepage DOS (em sendo
>> Windows o SO), das varíáveis de ambiente adequadas
>>
>> []s
>>
>> Chiappa
>>
>> --- Em oracle_br@yahoogrupos.com.br
> , "francisco porfirio"
>>  escreveu
>>>
>>> Cara, sem maiores análises eu diria para você da uma verificada
>>> no
>> front end
>>> que você está utilizando. Pode ser que no momento desta
>>> migração ele
>> tente
>>> fazer alguma conversão.
>>>
>>> 2008/11/13 amorrimm 
>>>
 Bom dia pessoal,

 Estou com uma dúvida...

 Fiz a migração de dados utilizando uma aplicação de front end

>> própria e
 pelo que verifiquei, chegou a importar todos os dados mas no
> lugar das
 letras acentuadas, sairam alguns caracteres ASCII.

 Acredito que o problema seja com relação ao Character SET
 mas, ja alterei no Oracle e ainda não consegui resolver o
 problema.

 O Character set que esta sendo utilizado no Sybase é o CP850
 e no Oracle é o WE8ISO8859P1 e pelo que verifiquei na página
 do Sybase,
>> eles
 estão na mesmo grupo..

 Alquem teria alguma ideia ?
>
>   
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iJwEAQECAAYFAkkcU3YACgkQ9hsrz6ieG2iAPgP/UFbJp56N456o8t2mj5f4yDS1
nMYz5Ovl3ZZyCgO+UyMZuYfnEikRXOUOq8vskIaaYHpLv2d3d5MPAwx+IA/zcExi
DwiIOsjHxiTn2LtTWtQXZN3CQw8AsvAi0z9G/RjIE6u0lOQpzM+HH2SUo6ZazOPO
Cg8fCun61KHk/lCCA58=
=VFFd
-END PGP SIGNATURE-

Re: [oracle_br] Re: migração 9i para 10g

[Willian Frasson]

sim sim já fiz com o catupgrd...

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Thursday, July 31, 2008 9:48 PM
  Subject: [oracle_br] Re: migração 9i para 10g


  Na verdade eu entendi que ele estava se referindo ao processo de
  migration, que tanto pode ser feito pelo assistente gráfico (o DBUA,
  sim), quanto em linha de comando : em versões anteriores o utilitário
  manual command-line para isso era o mig.exe, no 10g isso foi
  "embutido" no banco, vc via sqlplus abre o banco com startup migrate,
  e depois roda os sripts de atualização...

  []s

  Chiappa

  --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > migration tu falas é o DBUA né?
  > então faça em homologação primeiro certinho com sua base, rodou
  certinho dae faz na produção.
  > 
  > - Original Message - 
  > From: Mauricio Françoso 
  > To: oracle_br@yahoogrupos.com.br 
  > Sent: Thursday, July 31, 2008 2:21 PM
  > Subject: Re: [oracle_br] migração 9i para 10g
  > 
  > 
  > Willian,
  > 
  > O tamanho da base é 500GB, não vou usar export e import, tenho que
  usar o migration.
  > 
  > obrigado.
  > 
  > Mauricio do C. Françoso 
  > Liberty Seguros 
  > Administrador Banco de Dados(DBA ORACLE)
  > 
  > --- Em qui, 31/7/08, Willian Frasson <[EMAIL PROTECTED]> escreveu:
  > 
  > De: Willian Frasson <[EMAIL PROTECTED]>
  > Assunto: Re: [oracle_br] migração 9i para 10g
  > Para: oracle_br@yahoogrupos.com.br
  > Data: Quinta-feira, 31 de Julho de 2008, 14:18
  > 
  > Mauricio boa tarde... olha dias atraz fiz um teste de migração
  direta usando o DBUA da Oracle sem precisar usar o export e import,
  mas sugiro que faça em base testes, uma pergunta qual tamanho da base?
  > abçs.
  > 
  > - Original Message - 
  > From: Mauricio Françoso 
  > To: [EMAIL PROTECTED] os.com.br ; Lista de Usuários_Oracle 
  > Sent: Thursday, July 31, 2008 11:50 AM
  > Subject: [oracle_br] migração 9i para 10g
  > 
  > Bom dia,
  > 
  > Alguem teria o procedimento para migração do oracle 9.2.0.8 para
  oracle 10.2.0.3
  > 
  > S.O. = Solaris 9
  > 
  > obrigado.
  > 
  > Mauricio do C. Françoso 
  > Liberty Seguros 
  > Administrador Banco de Dados(DBA ORACLE)
  > 
  > Novos endereços, o Yahoo! que você conhece. Crie um email novo com
  a sua cara @ymail.com ou @rocketmail. com.
  > http://br.new. mail.yahoo. com/addresses
  > 
  > [As partes desta mensagem que não continham texto foram removidas]
  > 
  > __ Informação do NOD32 IMON 3301 (20080727) __
  > 
  > Esta mensagem foi verificada pelo NOD32 sistema antivírus
  > http://www.eset. com.br
  > 
  > [As partes desta mensagem que não continham texto foram removidas]
  > 
  > Novos endereços, o Yahoo! que você conhece. Crie um email novo com
  a sua cara @ymail.com ou @rocketmail.com.
  > http://br.new.mail.yahoo.com/addresses
  > 
  > [As partes desta mensagem que não continham texto foram removidas]
  > 
  > 
  > 
  > 
  > 
  > __ Informação do NOD32 IMON 3301 (20080727) __
  > 
  > Esta mensagem foi verificada pelo NOD32 sistema antivírus
  > http://www.eset.com.br
  > 
  > 
  > [As partes desta mensagem que não continham texto foram removidas]
  >



   

  __ Informação do NOD32 IMON 3301 (20080727) __

  Esta mensagem foi verificada pelo NOD32 sistema antivírus
  http://www.eset.com.br


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

Re: [oracle_br] Re: migração 9i para 10g

[Willian Frasson]

isso que pensei também para menor janela..
abçs.

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Thursday, July 31, 2008 8:44 PM
  Subject: [oracle_br] Re: migração 9i para 10g


  Posso me intrometer aí ? Primeiro de tudo , POR QUE vc "tem que" fazer
  a migração direta, é por causa de janela que vc acha que exp/imp não
  atenderá, ou o que  Isso é importante porque, se a janela não fot
  a menor das menores possíveis, é MUITO recomendado, se minimamente
  viável, vc REFAZER os objetos, pois aí se necessário vc aproveita e já
  os refaz usando as features 10g (ou 9i não usadas originalmente)
  cabíveis, como ASSM, compactação online, FGAC/FGA, novos esquemas de
  particionamento Migrando vc obtém um banco no "formato" 10g , mas
  SEM uso das novas features, se é isso mesmo que vc precisa, se
  realmente não dá pra aproveitar essa manutenção e fazer a
  implementação das new ffeats, o procedimento é SIMPLES, está
  documentado no manual de Migração (online em
  http://tahiti.oracle.com), mas de modo geral seria :

  1. backup full completo, inclusive da instância e de itens auxiliares
  (como registry, .profiles, etc) além do banco
  2. instalação do software de banco 10g, com banco 9i fechado
  3. abrir banco 9i em modo de upgrade com binários 10g
  4. executar o utilitário de migrate, que basicaente vai fazer um
  update no cabeçalho dos arquivos, compatiniliando-os com 10g
  5. abrir banco 10g 

  Há vários passos e pré-requisitos a mais, no manual estão todos
  citados, vc os seguirá, E além disso vc tem a opção de um wizard
  gráfico para isso OU rodar o utilitário manualmente, mas em resumo é isso.

  []s

  Chiappa

  OBS. IMPORTANTE : lógico, óbvio ululante, antes de sair migrando o
  banco Produção vc TEM QUE fazer num banco desenv/teste, E depois disso
  testar PROFUNDAMENTE a aplicação, as tools de desenvolvimento, etc,
  etc, tranquilamente PODE SER que um upgrade das tools, e/ou do cliente
  Oracle, seja requerido Também noto que há ENORMES diferenças no
  CBO do 9i pro 10g, LEIA os docs correspondentes à isso no metalink
  para saber onde e se vc terá que mudar, ou ao menos checar, o código
  da aplicação e/ou os parâmetros CBO.

  --- Em oracle_br@yahoogrupos.com.br, Mauricio Françoso <[EMAIL PROTECTED]>
  escreveu
  >
  > Willian,
  > 
  > O tamanho da base é 500GB, não vou usar export e import, tenho que
  usar o migration.
  > 
  > obrigado.
  > 
  > 
  > Mauricio do C. Françoso 
  > Liberty Seguros 
  > Administrador Banco de Dados(DBA ORACLE)
  > 
  > --- Em qui, 31/7/08, Willian Frasson <[EMAIL PROTECTED]> escreveu:
  > 
  > De: Willian Frasson <[EMAIL PROTECTED]>
  > Assunto: Re: [oracle_br] migração 9i para 10g
  > Para: oracle_br@yahoogrupos.com.br
  > Data: Quinta-feira, 31 de Julho de 2008, 14:18
  > 
  > 
  > 
  > 
  > 
  > 
  > Mauricio boa tarde... olha dias atraz fiz um teste de migração
  direta usando o DBUA da Oracle sem precisar usar o export e import,
  mas sugiro que faça em base testes, uma pergunta qual tamanho da base?
  > abçs.
  > 
  > - Original Message - 
  > From: Mauricio Françoso 
  > To: [EMAIL PROTECTED] os.com.br ; Lista de Usuários_Oracle 
  > Sent: Thursday, July 31, 2008 11:50 AM
  > Subject: [oracle_br] migração 9i para 10g
  > 
  > Bom dia,
  > 
  > Alguem teria o procedimento para migração do oracle 9.2.0.8 para
  oracle 10.2.0.3
  > 
  > S.O. = Solaris 9
  > 
  > obrigado.
  > 
  > 
  > Mauricio do C. Françoso 
  > Liberty Seguros 
  > Administrador Banco de Dados(DBA ORACLE)
  > 
  > Novos endereços, o Yahoo! que você conhece. Crie um email novo com a
  sua cara @ymail.com ou @rocketmail. com.
  > http://br.new. mail.yahoo. com/addresses
  > 
  > [As partes desta mensagem que não continham texto foram removidas]
  > 
  > __ Informação do NOD32 IMON 3301 (20080727) __
  > 
  > Esta mensagem foi verificada pelo NOD32 sistema antivírus
  > http://www.eset. com.br
  > 
  > [As partes desta mensagem que não continham texto foram removidas]
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > 
  > Novos endereços, o Yahoo! que você conhece. Crie um email novo
  com a sua cara @ymail.com ou @rocketmail.com.
  > http://br.new.mail.yahoo.com/addresses
  > 
  > [As partes desta mensagem que não continham texto foram removidas]
  >



   

  __ Informação do NOD32 IMON 3301 (20080727) __

  Esta mensagem foi verificada pelo NOD32 sistema antivírus
  http://www.eset.com.br


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

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

sim claro Anderson, isso é sempre feito hehe
abçs..

  - Original Message - 
  From: Anderson Santiago 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Thursday, June 05, 2008 12:21 AM
  Subject: Res: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 
10G RAC Linux (ASM)


  Demorou pra fazer isso, sendo o mesmo SO, sua vida fica mais fácil
  e você pode relaxar com isso tudo, tá vendo...
  em 30 minutos se consegue fazer a migração...
  um conselho...
  testa a teoria antes, porque na pratica, sempre aparecem surpresas.

  - Mensagem original 
  De: Willian Frasson <[EMAIL PROTECTED]>
  Para: oracle_br@yahoogrupos.com.br
  Enviadas: Terça-feira, 3 de Junho de 2008 22:59:18
  Assunto: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G 
RAC Linux (ASM)

  Então mas encontrei uma saíde melhor.. eu não sabia mas o SO é igual do RAC 
10G...
  dae pode se instalado o 9 na base B, feito um data guard e parar o banco e 
atualizar o mesmo para Rac 10G.
  abçs..

  - Original Message - 
  From: Anderson Santiago 
  To: [EMAIL PROTECTED] os.com.br 
  Sent: Tuesday, June 03, 2008 10:30 PM
  Subject: Res: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 
10G RAC Linux (ASM)

  Mano,
  se vai ficar louco com essa merda...relaxa, vai viajar um final de semana.
  Se quer uma ideia boa...
  usa essas placas giga, com um expdp com pipe no lado do servidor origem 
importanto antes de terminar
  garanto que daria menos de 2 horas se fosse bem configurado, principalmente 
se forem varios em paralelo.
  Não esqueçendo de desabilitar o archive dos dois lados e configurando as 
bases, uma pra leitura e outra
  pra escrita antes de começar.
  Att.
  Anderson Santiago
  DBA Sênior.
  www.ruevers. webs.com
  PS: tenho umas ideias loucas que poderia tentar usar, mas com certeza ia 
ficar doido amigo...

  - Mensagem original 
  De: Willian Frasson <[EMAIL PROTECTED] com.br>
  Para: [EMAIL PROTECTED] os.com.br
  Enviadas: Segunda-feira, 2 de Junho de 2008 9:07:32
  Assunto: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G 
RAC Linux (ASM)

  Chiappa bom dia...
  Neses dias andei pensando em algumas poissibilidades a mais para aquela 
migração com 2 horas de downtime, acho que poderia ser feito também e é uma
  idéia até boa..é mudar a versão da 9 para a 10, depois disso colocar umas 3 a 
4 placas de rede(Gigabit) nessas máquinas, criar um database link para cada uma 
delas
  depois disso fazer o expdp via network link por owners..
  o que acha..
  ?
  abçs..

  - Original Message - 
  From: jlchiappa 
  To: [EMAIL PROTECTED] os.com.br 
  Sent: Thursday, May 29, 2008 10:01 PM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)

  Seja via transport de tablespace seja via datapump ou o que for, o
  ponto só que acrescento para sua avaliação é aquele mesmo que já tinha
  sido citado : via de regra, vc obter no banco-destino só os dados e
  depois ter um script com os DDLs dos índices, constraints (e triggers
  no caso de export, o que não é aqui), scrpt esse alterado para fazer a
  criação em paralel, nologging, enable novalidate, etc : via e regra é
  MUITO mais performático rodar tal script no bd destino do que vc
  exportar os índices e/ou transportar as tablespaces dos índices, ok ?
  Então teste a chance de vc na máquina-origem já updateada, antes de
  exportar os metadados vc gera os scripts de DDls todos, DROPA AS
  constraints e índices e (aí sim) exporta os metadados e transporta as
  tablespaces só de dados . Com isso não seria mais necessário o
  passo do check de violações do transport, ** MAS ** por outro lado
  abre a chace de eventual erro humano, teste e avalie se o tempopoupado
  não tendo que transportar índices realmente compensa...

  []s

  Chiappa
  --- Em [EMAIL PROTECTED] os.com.br, "Willian Frasson" <[EMAIL PROTECTED] .>
  escreveu
  >
  > Acho que consegui chegar no resultado final chiappa, consegui fazer
  da forma que disse utilizando o transport e o convert do rman..
  > 1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)
  > 
  > 
  > 
  > 2º Criar diretório padrão do DATA PUMP na máquina A:
  > 
  > create or replace directory data_pump_dir as '/tmp';
  > 
  > 
  > 
  > 3º Cria Banco Todo na máquina A
  > 
  > 
  > 
  > 4º Instalar Oracle 10 máquina A
  > 
  > 
  > 
  > 5º Fazer upgrade Oracle 9 para Oracle 10
  > 
  > 
  > 
  > 6º Atualizar Patchset máquina A
  > 
  > 
  > 
  > 7º Criar diretório padrão do DATA PUMP na máquina B:
  > 
  > create or replace directory data_pump_dir as 'C:\RMAN';
  > 
  > 
  > 8º Tirar Listener Máquina A do ar
  > 
  > 
  > 
  > 9º Habilitar o transport tablespace nas tablespaces: 
  > 
  > exec dbms_tts.transport_ set_check( 'exemp

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

Então mas encontrei uma saíde melhor.. eu não sabia mas o SO é igual do RAC 
10G...
dae pode se instalado o 9 na base B, feito um data guard e parar o banco e 
atualizar o mesmo para Rac 10G.
abçs..

  - Original Message - 
  From: Anderson Santiago 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Tuesday, June 03, 2008 10:30 PM
  Subject: Res: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 
10G RAC Linux (ASM)


  Mano,
  se vai ficar louco com essa merda...relaxa, vai viajar um final de semana.
  Se quer uma ideia boa...
  usa essas placas giga, com um expdp com pipe no lado do servidor origem 
importanto antes de terminar
  garanto que daria menos de 2 horas se fosse bem configurado, principalmente 
se forem varios em paralelo.
  Não esqueçendo de desabilitar o archive dos dois lados e configurando as 
bases, uma pra leitura e outra
  pra escrita antes de começar.
  Att.
  Anderson Santiago
  DBA Sênior.
  www.ruevers.webs.com
  PS: tenho umas ideias loucas que poderia tentar usar, mas com certeza ia 
ficar doido amigo...

  - Mensagem original 
  De: Willian Frasson <[EMAIL PROTECTED]>
  Para: oracle_br@yahoogrupos.com.br
  Enviadas: Segunda-feira, 2 de Junho de 2008 9:07:32
  Assunto: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G 
RAC Linux (ASM)

  Chiappa bom dia...
  Neses dias andei pensando em algumas poissibilidades a mais para aquela 
migração com 2 horas de downtime, acho que poderia ser feito também e é uma
  idéia até boa..é mudar a versão da 9 para a 10, depois disso colocar umas 3 a 
4 placas de rede(Gigabit) nessas máquinas, criar um database link para cada uma 
delas
  depois disso fazer o expdp via network link por owners..
  o que acha..
  ?
  abçs..

  - Original Message - 
  From: jlchiappa 
  To: [EMAIL PROTECTED] os.com.br 
  Sent: Thursday, May 29, 2008 10:01 PM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)

  Seja via transport de tablespace seja via datapump ou o que for, o
  ponto só que acrescento para sua avaliação é aquele mesmo que já tinha
  sido citado : via de regra, vc obter no banco-destino só os dados e
  depois ter um script com os DDLs dos índices, constraints (e triggers
  no caso de export, o que não é aqui), scrpt esse alterado para fazer a
  criação em paralel, nologging, enable novalidate, etc : via e regra é
  MUITO mais performático rodar tal script no bd destino do que vc
  exportar os índices e/ou transportar as tablespaces dos índices, ok ?
  Então teste a chance de vc na máquina-origem já updateada, antes de
  exportar os metadados vc gera os scripts de DDls todos, DROPA AS
  constraints e índices e (aí sim) exporta os metadados e transporta as
  tablespaces só de dados . Com isso não seria mais necessário o
  passo do check de violações do transport, ** MAS ** por outro lado
  abre a chace de eventual erro humano, teste e avalie se o tempopoupado
  não tendo que transportar índices realmente compensa...

  []s

  Chiappa
  --- Em [EMAIL PROTECTED] os.com.br, "Willian Frasson" <[EMAIL PROTECTED] .>
  escreveu
  >
  > Acho que consegui chegar no resultado final chiappa, consegui fazer
  da forma que disse utilizando o transport e o convert do rman..
  > 1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)
  > 
  > 
  > 
  > 2º Criar diretório padrão do DATA PUMP na máquina A:
  > 
  > create or replace directory data_pump_dir as '/tmp';
  > 
  > 
  > 
  > 3º Cria Banco Todo na máquina A
  > 
  > 
  > 
  > 4º Instalar Oracle 10 máquina A
  > 
  > 
  > 
  > 5º Fazer upgrade Oracle 9 para Oracle 10
  > 
  > 
  > 
  > 6º Atualizar Patchset máquina A
  > 
  > 
  > 
  > 7º Criar diretório padrão do DATA PUMP na máquina B:
  > 
  > create or replace directory data_pump_dir as 'C:\RMAN';
  > 
  > 
  > 8º Tirar Listener Máquina A do ar
  > 
  > 
  > 
  > 9º Habilitar o transport tablespace nas tablespaces: 
  > 
  > exec dbms_tts.transport_ set_check( 'exemplo' , true);
  > 
  > 
  > 
  > 10º Verificar erros de violação:
  > 
  > select * from transport_set_ violations;
  > 
  > 
  > 
  > 11º Colocar as tablespaces em Read Only: 
  > 
  > alter tablespace exemplo read only;
  > 
  > 
  > 
  > 12º Export do transport tablespaces: 
  > 
  > expdp system/oracle dumpfile=exemplo. dmp
  transport_tablespac es=exemplo transport_full_ check=y
  > 
  > 
  > 
  > 13º Convert dos datafiles com RMAN: convert tablespace exemplo to
  platform 'Linux IA (32-bit)' format 'c:\rman\%u' parallelism = 5; 
  > 
  > 14º Baixa o Banco
  > 
  > 
  > 
  > 15º Copiar DATA FILES da máquina A para máquina B (via storage)
  > 
  > 
  > 
  > 16º Import da Estrutura na máquina B: 
 

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

é mas temos outra saide ótima

  - Original Message - 
  From: Anderson Santiago 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Tuesday, June 03, 2008 10:30 PM
  Subject: Res: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 
10G RAC Linux (ASM)


  Mano,
  se vai ficar louco com essa merda...relaxa, vai viajar um final de semana.
  Se quer uma ideia boa...
  usa essas placas giga, com um expdp com pipe no lado do servidor origem 
importanto antes de terminar
  garanto que daria menos de 2 horas se fosse bem configurado, principalmente 
se forem varios em paralelo.
  Não esqueçendo de desabilitar o archive dos dois lados e configurando as 
bases, uma pra leitura e outra
  pra escrita antes de começar.
  Att.
  Anderson Santiago
  DBA Sênior.
  www.ruevers.webs.com
  PS: tenho umas ideias loucas que poderia tentar usar, mas com certeza ia 
ficar doido amigo...

  - Mensagem original 
  De: Willian Frasson <[EMAIL PROTECTED]>
  Para: oracle_br@yahoogrupos.com.br
  Enviadas: Segunda-feira, 2 de Junho de 2008 9:07:32
  Assunto: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G 
RAC Linux (ASM)

  Chiappa bom dia...
  Neses dias andei pensando em algumas poissibilidades a mais para aquela 
migração com 2 horas de downtime, acho que poderia ser feito também e é uma
  idéia até boa..é mudar a versão da 9 para a 10, depois disso colocar umas 3 a 
4 placas de rede(Gigabit) nessas máquinas, criar um database link para cada uma 
delas
  depois disso fazer o expdp via network link por owners..
  o que acha..
  ?
  abçs..

  - Original Message - 
  From: jlchiappa 
  To: [EMAIL PROTECTED] os.com.br 
  Sent: Thursday, May 29, 2008 10:01 PM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)

  Seja via transport de tablespace seja via datapump ou o que for, o
  ponto só que acrescento para sua avaliação é aquele mesmo que já tinha
  sido citado : via de regra, vc obter no banco-destino só os dados e
  depois ter um script com os DDLs dos índices, constraints (e triggers
  no caso de export, o que não é aqui), scrpt esse alterado para fazer a
  criação em paralel, nologging, enable novalidate, etc : via e regra é
  MUITO mais performático rodar tal script no bd destino do que vc
  exportar os índices e/ou transportar as tablespaces dos índices, ok ?
  Então teste a chance de vc na máquina-origem já updateada, antes de
  exportar os metadados vc gera os scripts de DDls todos, DROPA AS
  constraints e índices e (aí sim) exporta os metadados e transporta as
  tablespaces só de dados . Com isso não seria mais necessário o
  passo do check de violações do transport, ** MAS ** por outro lado
  abre a chace de eventual erro humano, teste e avalie se o tempopoupado
  não tendo que transportar índices realmente compensa...

  []s

  Chiappa
  --- Em [EMAIL PROTECTED] os.com.br, "Willian Frasson" <[EMAIL PROTECTED] .>
  escreveu
  >
  > Acho que consegui chegar no resultado final chiappa, consegui fazer
  da forma que disse utilizando o transport e o convert do rman..
  > 1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)
  > 
  > 
  > 
  > 2º Criar diretório padrão do DATA PUMP na máquina A:
  > 
  > create or replace directory data_pump_dir as '/tmp';
  > 
  > 
  > 
  > 3º Cria Banco Todo na máquina A
  > 
  > 
  > 
  > 4º Instalar Oracle 10 máquina A
  > 
  > 
  > 
  > 5º Fazer upgrade Oracle 9 para Oracle 10
  > 
  > 
  > 
  > 6º Atualizar Patchset máquina A
  > 
  > 
  > 
  > 7º Criar diretório padrão do DATA PUMP na máquina B:
  > 
  > create or replace directory data_pump_dir as 'C:\RMAN';
  > 
  > 
  > 8º Tirar Listener Máquina A do ar
  > 
  > 
  > 
  > 9º Habilitar o transport tablespace nas tablespaces: 
  > 
  > exec dbms_tts.transport_ set_check( 'exemplo' , true);
  > 
  > 
  > 
  > 10º Verificar erros de violação:
  > 
  > select * from transport_set_ violations;
  > 
  > 
  > 
  > 11º Colocar as tablespaces em Read Only: 
  > 
  > alter tablespace exemplo read only;
  > 
  > 
  > 
  > 12º Export do transport tablespaces: 
  > 
  > expdp system/oracle dumpfile=exemplo. dmp
  transport_tablespac es=exemplo transport_full_ check=y
  > 
  > 
  > 
  > 13º Convert dos datafiles com RMAN: convert tablespace exemplo to
  platform 'Linux IA (32-bit)' format 'c:\rman\%u' parallelism = 5; 
  > 
  > 14º Baixa o Banco
  > 
  > 
  > 
  > 15º Copiar DATA FILES da máquina A para máquina B (via storage)
  > 
  > 
  > 
  > 16º Import da Estrutura na máquina B: 
  > 
  > impdp system/oracle dumpfile=exemplo. dmp directory=data_ pump_dir
  transport_datafiles =/tmp/exemplo01. dbf, /tmp/exemplo02. dbf
  > 
  > 
  > 
  > 

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

Chiappa bom dia...
Neses dias andei pensando em algumas poissibilidades a mais para aquela 
migração com 2 horas de downtime, acho que poderia ser feito também e é uma
idéia até boa..é mudar a versão da 9 para a 10, depois disso colocar umas 3 a 4 
placas de rede(Gigabit) nessas máquinas, criar um database link para cada uma 
delas
depois disso fazer o expdp via network link por owners..
o que acha..
?
abçs..

- Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Thursday, May 29, 2008 10:01 PM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)


  Seja via transport de tablespace seja via datapump ou o que for, o
  ponto só que acrescento para sua avaliação é aquele mesmo que já tinha
  sido citado : via de regra, vc obter no banco-destino só os dados e
  depois ter um script com os DDLs dos índices, constraints (e triggers
  no caso de export, o que não é aqui), scrpt esse alterado para fazer a
  criação em paralel, nologging, enable novalidate, etc : via e regra é
  MUITO mais performático rodar tal script no bd destino do que vc
  exportar os índices e/ou transportar as tablespaces dos índices, ok ?
  Então teste a chance de vc na máquina-origem já updateada, antes de
  exportar os metadados vc gera os scripts de DDls todos, DROPA AS
  constraints e índices e (aí sim) exporta os metadados e transporta as
  tablespaces só de dados . Com isso não seria mais necessário o
  passo do check de violações do transport, ** MAS ** por outro lado
  abre a chace de eventual erro humano, teste e avalie se o tempopoupado
  não tendo que transportar índices realmente compensa...

  []s

  Chiappa
  --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > Acho que consegui chegar no resultado final chiappa, consegui fazer
  da forma que disse utilizando o transport e o convert do rman..
  > 1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)
  > 
  > 
  > 
  > 2º Criar diretório padrão do DATA PUMP na máquina A:
  > 
  > create or replace directory data_pump_dir as '/tmp';
  > 
  > 
  > 
  > 3º Cria Banco Todo na máquina A
  > 
  > 
  > 
  > 4º Instalar Oracle 10 máquina A
  > 
  > 
  > 
  > 5º Fazer upgrade Oracle 9 para Oracle 10
  > 
  > 
  > 
  > 6º Atualizar Patchset máquina A
  > 
  > 
  > 
  > 7º Criar diretório padrão do DATA PUMP na máquina B:
  > 
  > create or replace directory data_pump_dir as 'C:\RMAN';
  > 
  > 
  > 8º Tirar Listener Máquina A do ar
  > 
  > 
  > 
  > 9º Habilitar o transport tablespace nas tablespaces: 
  > 
  > exec dbms_tts.transport_set_check('exemplo', true);
  > 
  > 
  > 
  > 10º Verificar erros de violação:
  > 
  > select * from transport_set_violations;
  > 
  > 
  > 
  > 11º Colocar as tablespaces em Read Only: 
  > 
  > alter tablespace exemplo read only;
  > 
  > 
  > 
  > 12º Export do transport tablespaces: 
  > 
  > expdp system/oracle dumpfile=exemplo.dmp
  transport_tablespaces=exemplo transport_full_check=y
  > 
  > 
  > 
  > 13º Convert dos datafiles com RMAN: convert tablespace exemplo to
  platform 'Linux IA (32-bit)' format 'c:\rman\%u' parallelism = 5; 
  > 
  > 14º Baixa o Banco
  > 
  > 
  > 
  > 15º Copiar DATA FILES da máquina A para máquina B (via storage)
  > 
  > 
  > 
  > 16º Import da Estrutura na máquina B: 
  > 
  > impdp system/oracle dumpfile=exemplo.dmp directory=data_pump_dir
  transport_datafiles=/tmp/exemplo01.dbf, /tmp/exemplo02.dbf
  > 
  > 
  > 
  > - Original Message - 
  > From: jlchiappa 
  > To: oracle_br@yahoogrupos.com.br 
  > Sent: Wednesday, May 28, 2008 12:52 PM
  > Subject: [oracle_br] Re: Migração Oracle 9i Windows Single
  Instance / 10G RAC Linux (ASM)
  > 
  > 
  > É : como o volume desaconelha o export puro, a tua chance é, como eu
  > falei, vc ter uma rede privada muito rápida entre as duas máquinas e
  > OU transferir os dados diretamente via rede de a para B (isto é o
  > datapump), OU copiar via rede os arquivos (isto é o procedimento
  > "transportar as tablespaces"), este último é o que vc montou, vou
  > comenar sobre ele, só mais uma vez lembro vc para MONTAR e TESTAR o
  > datapump enviando dados sem gerar arquivo de dump e a para b, e veja
  > lá o que se sai melhor. Logicamente também, relembro que nos dois
  > procedimentos idealmente vc vai transferir APENAS OS DADOS (via pump)
  > ou APENAS OS DATAFILES COM TABLESPACES DE DADOS (via transport), pois
  > índices e constrants vc RECRIA DEPOIS, com NOLOGGING , PARALLEL,
  > NOVALIDATE, etc.
  > 
  > Para o procedimento de transport que vc montou neste e-mail, comento
  > que :
  > 
  > a. vamos esclarecer aí o conceito : no RDBMS Oracle, "database" é o
  > conjunto de arquivos em disco (ie, datafiles, initfile, redo log
  > files, tempfiles, etc), ese conjunto pode ser aberto por uma
  > "instância" (ie, conjunto de 'programas executáveis Oracle'), que aí
  > sim forma um BANCO ATIVO, ok ? O RAC nada mais é do que um único

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

mas estranho Chiappa
fui testar na minha máquina com paralelism=5, ou =8 e demorou muito tempo para 
o convert do RMAN, converter 10 GB...

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Thursday, May 29, 2008 10:01 PM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)


  Seja via transport de tablespace seja via datapump ou o que for, o
  ponto só que acrescento para sua avaliação é aquele mesmo que já tinha
  sido citado : via de regra, vc obter no banco-destino só os dados e
  depois ter um script com os DDLs dos índices, constraints (e triggers
  no caso de export, o que não é aqui), scrpt esse alterado para fazer a
  criação em paralel, nologging, enable novalidate, etc : via e regra é
  MUITO mais performático rodar tal script no bd destino do que vc
  exportar os índices e/ou transportar as tablespaces dos índices, ok ?
  Então teste a chance de vc na máquina-origem já updateada, antes de
  exportar os metadados vc gera os scripts de DDls todos, DROPA AS
  constraints e índices e (aí sim) exporta os metadados e transporta as
  tablespaces só de dados . Com isso não seria mais necessário o
  passo do check de violações do transport, ** MAS ** por outro lado
  abre a chace de eventual erro humano, teste e avalie se o tempopoupado
  não tendo que transportar índices realmente compensa...

  []s

  Chiappa
  --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > Acho que consegui chegar no resultado final chiappa, consegui fazer
  da forma que disse utilizando o transport e o convert do rman..
  > 1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)
  > 
  > 
  > 
  > 2º Criar diretório padrão do DATA PUMP na máquina A:
  > 
  > create or replace directory data_pump_dir as '/tmp';
  > 
  > 
  > 
  > 3º Cria Banco Todo na máquina A
  > 
  > 
  > 
  > 4º Instalar Oracle 10 máquina A
  > 
  > 
  > 
  > 5º Fazer upgrade Oracle 9 para Oracle 10
  > 
  > 
  > 
  > 6º Atualizar Patchset máquina A
  > 
  > 
  > 
  > 7º Criar diretório padrão do DATA PUMP na máquina B:
  > 
  > create or replace directory data_pump_dir as 'C:\RMAN';
  > 
  > 
  > 8º Tirar Listener Máquina A do ar
  > 
  > 
  > 
  > 9º Habilitar o transport tablespace nas tablespaces: 
  > 
  > exec dbms_tts.transport_set_check('exemplo', true);
  > 
  > 
  > 
  > 10º Verificar erros de violação:
  > 
  > select * from transport_set_violations;
  > 
  > 
  > 
  > 11º Colocar as tablespaces em Read Only: 
  > 
  > alter tablespace exemplo read only;
  > 
  > 
  > 
  > 12º Export do transport tablespaces: 
  > 
  > expdp system/oracle dumpfile=exemplo.dmp
  transport_tablespaces=exemplo transport_full_check=y
  > 
  > 
  > 
  > 13º Convert dos datafiles com RMAN: convert tablespace exemplo to
  platform 'Linux IA (32-bit)' format 'c:\rman\%u' parallelism = 5; 
  > 
  > 14º Baixa o Banco
  > 
  > 
  > 
  > 15º Copiar DATA FILES da máquina A para máquina B (via storage)
  > 
  > 
  > 
  > 16º Import da Estrutura na máquina B: 
  > 
  > impdp system/oracle dumpfile=exemplo.dmp directory=data_pump_dir
  transport_datafiles=/tmp/exemplo01.dbf, /tmp/exemplo02.dbf
  > 
  > 
  > 
  > - Original Message - 
  > From: jlchiappa 
  > To: oracle_br@yahoogrupos.com.br 
  > Sent: Wednesday, May 28, 2008 12:52 PM
  > Subject: [oracle_br] Re: Migração Oracle 9i Windows Single
  Instance / 10G RAC Linux (ASM)
  > 
  > 
  > É : como o volume desaconelha o export puro, a tua chance é, como eu
  > falei, vc ter uma rede privada muito rápida entre as duas máquinas e
  > OU transferir os dados diretamente via rede de a para B (isto é o
  > datapump), OU copiar via rede os arquivos (isto é o procedimento
  > "transportar as tablespaces"), este último é o que vc montou, vou
  > comenar sobre ele, só mais uma vez lembro vc para MONTAR e TESTAR o
  > datapump enviando dados sem gerar arquivo de dump e a para b, e veja
  > lá o que se sai melhor. Logicamente também, relembro que nos dois
  > procedimentos idealmente vc vai transferir APENAS OS DADOS (via pump)
  > ou APENAS OS DATAFILES COM TABLESPACES DE DADOS (via transport), pois
  > índices e constrants vc RECRIA DEPOIS, com NOLOGGING , PARALLEL,
  > NOVALIDATE, etc.
  > 
  > Para o procedimento de transport que vc montou neste e-mail, comento
  > que :
  > 
  > a. vamos esclarecer aí o conceito : no RDBMS Oracle, "database" é o
  > conjunto de arquivos em disco (ie, datafiles, initfile, redo log
  > files, tempfiles, etc), ese conjunto pode ser aberto por uma
  > "instância" (ie, conjunto de 'programas executáveis Oracle'), que aí
  > sim forma um BANCO ATIVO, ok ? O RAC nada mais é do que um único
  > database , que reside num storage "shared", que todas as máquinas do
  > cluster enxergam, e esse database é aberto simultaneamente por N
  > instâncias, normalmente cada uma dessas instâncias residindo numa
  > máquina diferente, ok ? Isto posto, imho eu acho que NÃO

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

Olha Chiappa uma coisa.. que poderia ser feita também que possivelmente numa 
janela de 2 a 3 horas.. eu conseguiria essa migração é fazer o seguinte:
migrar da 9 para 10 e utilizar o data pump ao invéz do imp e exp, mesmo com 
buffer, direct e talz.. pelo que andei fazendo uns testes... o mesmo é 4x 
mais rápido do que o expdp, imp.
Acabei de fazer um teste e na minha máquina 2 GB de memoria, Dual core, etc:
10 GB
expdp: 15 minutos
exp: 30 minutos


  - Original Message - 
  From: Willian Frasson 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 7:35 PM
  Subject: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G 
RAC Linux (ASM)


  Acho que consegui chegar no resultado final chiappa, consegui fazer da forma 
que disse utilizando o transport e o convert do rman..
  1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)

  2º Criar diretório padrão do DATA PUMP na máquina A:

  create or replace directory data_pump_dir as '/tmp';

  3º Cria Banco Todo na máquina A

  4º Instalar Oracle 10 máquina A

  5º Fazer upgrade Oracle 9 para Oracle 10

  6º Atualizar Patchset máquina A

  7º Criar diretório padrão do DATA PUMP na máquina B:

  create or replace directory data_pump_dir as 'C:\RMAN';

  8º Tirar Listener Máquina A do ar

  9º Habilitar o transport tablespace nas tablespaces: 

  exec dbms_tts.transport_set_check('exemplo', true);

  10º Verificar erros de violação:

  select * from transport_set_violations;

  11º Colocar as tablespaces em Read Only: 

  alter tablespace exemplo read only;

  12º Export do transport tablespaces: 

  expdp system/oracle dumpfile=exemplo.dmp transport_tablespaces=exemplo 
transport_full_check=y

  13º Convert dos datafiles com RMAN: convert tablespace exemplo to platform 
'Linux IA (32-bit)' format 'c:\rman\%u' parallelism = 5; 

  14º Baixa o Banco

  15º Copiar DATA FILES da máquina A para máquina B (via storage)

  16º Import da Estrutura na máquina B: 

  impdp system/oracle dumpfile=exemplo.dmp directory=data_pump_dir 
transport_datafiles=/tmp/exemplo01.dbf, /tmp/exemplo02.dbf

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 12:52 PM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)

  É : como o volume desaconelha o export puro, a tua chance é, como eu
  falei, vc ter uma rede privada muito rápida entre as duas máquinas e
  OU transferir os dados diretamente via rede de a para B (isto é o
  datapump), OU copiar via rede os arquivos (isto é o procedimento
  "transportar as tablespaces"), este último é o que vc montou, vou
  comenar sobre ele, só mais uma vez lembro vc para MONTAR e TESTAR o
  datapump enviando dados sem gerar arquivo de dump e a para b, e veja
  lá o que se sai melhor. Logicamente também, relembro que nos dois
  procedimentos idealmente vc vai transferir APENAS OS DADOS (via pump)
  ou APENAS OS DATAFILES COM TABLESPACES DE DADOS (via transport), pois
  índices e constrants vc RECRIA DEPOIS, com NOLOGGING , PARALLEL,
  NOVALIDATE, etc.

  Para o procedimento de transport que vc montou neste e-mail, comento
  que :

  a. vamos esclarecer aí o conceito : no RDBMS Oracle, "database" é o
  conjunto de arquivos em disco (ie, datafiles, initfile, redo log
  files, tempfiles, etc), ese conjunto pode ser aberto por uma
  "instância" (ie, conjunto de 'programas executáveis Oracle'), que aí
  sim forma um BANCO ATIVO, ok ? O RAC nada mais é do que um único
  database , que reside num storage "shared", que todas as máquinas do
  cluster enxergam, e esse database é aberto simultaneamente por N
  instâncias, normalmente cada uma dessas instâncias residindo numa
  máquina diferente, ok ? Isto posto, imho eu acho que NÃO É PRECISO já
  neste primeiro passo vc criar as N instâncias, só criar um único
  database com uma única instância na máquina-destino, depois vc inclui
  as outras N instãncias cfrme mostrado em
  http://www.oracle.com/technology/pub/articles/chan_sing2rac_install.html
  , ok ? Acho que deve ser mais rápido, acho

  b. a baixa do banco deve ser feita APÓS o export dos metadados
  apenas, vc NÃO CONSEGUE fazer export com banco baixado

  c. o export e depois o import dos metadados tanto pode ser feito com
  exp/imp quando com datapump, são coisas pequenas qquer um vai ter + ou
  - a mesma performance

  d. o passo CRÍTICO em termos de performance/adequação à sua janela é
  a cópia física dos datafiles : experimente ftp, experimente rsh, teste
  utilitários de download tipo Orbit/wsFTP/fileZilla! que permitem abrir
  N sessões de cópia/baixa de arquivos (aonde N não pode ser muito alto
  sob pena de degradar, mais uma vez é o teste que vai te demonstrar
  isto), veja lá o que dá um tempo m elhor, E não esqueça que os
  datafiles são BINÁRIOS, a cópia deve ser feita e

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

foi o que fiz amigo rsrs...
não sei se leu o documento.. segue documento que fiz completo em anexo, enviei 
o roteiro hoje a noite, valeu novamente, e veja na OBS. que irei fazer os 
dados, depois indices libero a producao
e depois levo as TBS das tabelas particionadas.
abçs..

  - Original Message - 
  From: wilson teixeira 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 10:02 PM
  Subject: RES: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 
10G RAC Linux (ASM)


  Willian, vou dar pitaco novamante

  Com EXP/IMP nesta janela de tempo acho quase improvável conseguir. Sugiro:

  1 - Crie 1 base 10g (WIN)

  2 - Migrar a Base Origem para 10g

  3 - Exp TTS

  4 - Converter os datafiles

  5 - FTP para o servidor

  6 - IMP TTS.

  Verifique a possibilidade de realizar BCV ou SNAP via storage para copia dos
  dados. É muito mais rápido.

  Mesmo com os passos acima está janela não deve ser o suficiente. 

  Aconselho-lhe a revisar esta janela ou realizar alguns passos antes do dia
  D. 

  _ 

  De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em
  nome de Marco Souza
  Enviada em: quarta-feira, 28 de maio de 2008 11:10
  Para: oracle_br@yahoogrupos.com.br
  Assunto: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance /
  10G RAC Linux (ASM)

  Batendo na mesma tecla do uso do export/import. Eu nunca usei, mas alguém já
  fez o teste com export incremental ?
  Não poderia ser aplicado nesta situação ?
  Um export full e uma importação na nova base e finalmente um export
  incremental e um import final. Eu particularmente nunca fiz esse teste, mas
  isso não resolveria o problema ?

  jlchiappa <[EMAIL PROTECTED] <mailto:jlchiappa%40yahoo.com.br> com.br>
  escreveu: O complicador aí em relação ao tamanho total, que pode
  inviabilizar o
  exp numa base de 1 Tb, é que :

  a) vc tem que arranjar o espaço no disco local pra gerar o dump,
  coisa de 100 Gb é difícil mas vc até arranja, já 1 Tb conheço POUCAS
  máquinas prod com 1 Tb sobrando...

  b) vc vai querer abrir várias sessões de export, MAS (óbvio)
  certamente os discos são os mesmos pra todos os schemas, a
  controladora é a mesma, há concorência, quantas mais sessões
  simultâneas vc abrir, mais degrada a performance : vamos supor que é
  um RAID, hardware de produção mesmo, que assim vc consiga ter 3
  sessões simultâneas

  c) tipicamente a performance dum export local com as opções todas
  citadas, num hardware de produção, SEM concorrência, exportando só as
  linhas da tabela, etc etc, é coisa de 1 GB por minuto, ou pouco mais,
  um exemplo na minha máquina de testes (disco SATA, 2 Gb de RAM) :

  [EMAIL PROTECTED]:SQL>select count(*) from TAB_2G;

  COUNT(*)
  --
  257340

  [EMAIL PROTECTED]:SQL>select bytes from user_segments where 
segment_name='TAB_2G';

  BYTES
  --
  2147483648

  C:\>exp system/[EMAIL PROTECTED] file=teste_2g log=teste_2g.exp direct=y
  buffer=1048
  5760 recordlength=65535 triggers=n constraints=n indexes=n
  statistics=none recor
  d=n tables=sys.TAB_2G feedback=10

  Export: Release 10.2.0.4.0 - Production on Qua Mai 28 10:20:48 2008

  Copyright (c) 1982, 2007, Oracle. All rights reserved.

  Conectado a: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0
  - Product
  ion
  With the Partitioning, Oracle Label Security, OLAP, Data Mining
  Scoring Engine
  and Real Application Testing options
  ExportaþÒo executada no conjunto de caracteres de WE8MSWIN1252 e no
  conjunto de
  caracteres de AL16UTF16 NCHAR
  Obs.: Ýndices em tabelas nÒo serÒo exportados
  Obs.: restriþ§es em tabelas nÒo serÒo exportadas

  Sobre exportar tabelas especificadas ... via Caminho Direto ...
  O usußrio atual foi alterado para SYS
  . . exportando tabela TAB_2G
  ..
  257340 linhas
  exportadas
  ExportaþÒo encerrada com sucesso, sem advertÛncias.

  C:\>dir teste_2g.dmp
  Pasta de C:\

  28/05/2008 10:22 1.031.455.365 teste_2g.DMP

  ==> ou seja, coisa de 2 minutos pra exportar coisa de 2 Gb, yes ?
  LÓGICO, vc vai testar no seu hardware, mas acho que 1 Gb/minuto é um
  mínimo em aceitável, muito provável de se obter, legal ?
  Muito bem, fazendo uma conta de padeiro, se formos exportar 100 Gb no
  total e termos 3 sessões cada uma exportando 33 Gb, levaríamos coisa
  de pouco mais de meia hora (33 minutos) só pro export, tá tranquila a
  tua janela, creio... . Já 1 Tb, se cada uma das 3 sessões exportar uns
  333 Gb, já batemos 333 minutos, ou seja mais de CINCO HORAS, a tua
  janela FOI PRO BREJO, yes ?? Ainda que vc tivesse um hardware
  realmente bom que permitisse, digamos, 5 sessões simultâneas lendo a
  mesma fonte sem degradação grande, cada uma exportando 200 Gb do 1 Tb
  total, já foram 200 minutos, mais de duas horas, quase acabou a tua
  janela só aí...
  Então a regra de dedão é clara, exp vai bem até um certo volume

  []s

  Chiappa

  --- Em [EMAIL PROTECTED] &

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

Acho que consegui chegar no resultado final chiappa, consegui fazer da forma 
que disse utilizando o transport e o convert do rman..
1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)

 

2º Criar diretório padrão do DATA PUMP na máquina A:

create or replace directory data_pump_dir as '/tmp';

 

3º Cria Banco Todo na máquina A

 

4º Instalar Oracle 10 máquina A

 

5º Fazer upgrade Oracle 9 para Oracle 10

 

6º Atualizar Patchset máquina A

 

7º Criar diretório padrão do DATA PUMP na máquina B:

create or replace directory data_pump_dir as 'C:\RMAN';


8º Tirar Listener Máquina A do ar

 

9º Habilitar o transport tablespace nas tablespaces: 

exec dbms_tts.transport_set_check('exemplo', true);

 

10º Verificar erros de violação:

select * from transport_set_violations;

 

11º Colocar as tablespaces em Read Only:  

alter tablespace exemplo read only;

 

12º Export do transport tablespaces: 

expdp system/oracle dumpfile=exemplo.dmp transport_tablespaces=exemplo 
transport_full_check=y

 

13º Convert dos datafiles com RMAN: convert tablespace exemplo to platform 
'Linux IA (32-bit)' format 'c:\rman\%u' parallelism = 5; 

14º Baixa o Banco

 

15º Copiar DATA FILES da máquina A para máquina B (via storage)

 

16º Import da Estrutura na máquina B:  

impdp system/oracle dumpfile=exemplo.dmp directory=data_pump_dir 
transport_datafiles=/tmp/exemplo01.dbf, /tmp/exemplo02.dbf



  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 12:52 PM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)


  É : como o volume desaconelha o export puro, a tua chance é, como eu
  falei, vc ter uma rede privada muito rápida entre as duas máquinas e
  OU transferir os dados diretamente via rede de a para B (isto é o
  datapump), OU copiar via rede os arquivos (isto é o procedimento
  "transportar as tablespaces"), este último é o que vc montou, vou
  comenar sobre ele, só mais uma vez lembro vc para MONTAR e TESTAR o
  datapump enviando dados sem gerar arquivo de dump e a para b, e veja
  lá o que se sai melhor. Logicamente também, relembro que nos dois
  procedimentos idealmente vc vai transferir APENAS OS DADOS (via pump)
  ou APENAS OS DATAFILES COM TABLESPACES DE DADOS (via transport), pois
  índices e constrants vc RECRIA DEPOIS, com NOLOGGING , PARALLEL,
  NOVALIDATE, etc.

  Para o procedimento de transport que vc montou neste e-mail, comento
  que :

  a. vamos esclarecer aí o conceito : no RDBMS Oracle, "database" é o
  conjunto de arquivos em disco (ie, datafiles, initfile, redo log
  files, tempfiles, etc), ese conjunto pode ser aberto por uma
  "instância" (ie, conjunto de 'programas executáveis Oracle'), que aí
  sim forma um BANCO ATIVO, ok ? O RAC nada mais é do que um único
  database , que reside num storage "shared", que todas as máquinas do
  cluster enxergam, e esse database é aberto simultaneamente por N
  instâncias, normalmente cada uma dessas instâncias residindo numa
  máquina diferente, ok ? Isto posto, imho eu acho que NÃO É PRECISO já
  neste primeiro passo vc criar as N instâncias, só criar um único
  database com uma única instância na máquina-destino, depois vc inclui
  as outras N instãncias cfrme mostrado em
  http://www.oracle.com/technology/pub/articles/chan_sing2rac_install.html
  , ok ? Acho que deve ser mais rápido, acho

  b. a baixa do banco deve ser feita APÓS o export dos metadados
  apenas, vc NÃO CONSEGUE fazer export com banco baixado

  c. o export e depois o import dos metadados tanto pode ser feito com
  exp/imp quando com datapump, são coisas pequenas qquer um vai ter + ou
  - a mesma performance

  d. o passo CRÍTICO em termos de performance/adequação à sua janela é
  a cópia física dos datafiles : experimente ftp, experimente rsh, teste
  utilitários de download tipo Orbit/wsFTP/fileZilla! que permitem abrir
  N sessões de cópia/baixa de arquivos (aonde N não pode ser muito alto
  sob pena de degradar, mais uma vez é o teste que vai te demonstrar
  isto), veja lá o que dá um tempo m elhor, E não esqueça que os
  datafiles são BINÁRIOS, a cópia deve ser feita em modo BINÁRIO!!

  []s

  Chiappa

  --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > Chiappa acho que encontrei algo que deve funcionar, vou testar na VM
  minha aqui.. seria isso:
  > 1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)
  > 
  > 2º Cria Banco Todo 
  > 
  > 3º Instalar Oracle 10 máquina A
  > 
  > 4º Fazer upgrade Oracle 9 para Oracle 10
  > 
  > 5º Atualizar Patchset máquina A
  > 
  > 6º Baixa o Banco
  > 
  > 7º Colocar as tablespaces em Read Only: alter tablespace example
  read only;
  > 
  > 8º Export do transport tablespaces: expdp system/oracle
  DUMPFILE=example.dmp TRANSPORT_TABLESPACES=example TRANSPORT_FULL_CHECK=Y
  > 
  > 9º Convert dos datafiles com RMAN: convert tablespace example TO

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

hm entao isso msmo man..
eu até estou criando um banco novo aqui para términar o teste...
logo envio o documento todo pra vcs..
abçs..

  - Original Message - 
  From: Fernando Martins 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 3:16 PM
  Subject: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G 
RAC Linux (ASM)


  A tabela informada é do owner sys, por issu o erro, tenta recriar ela em
  outro schema <> de sys ou system
  e roda a procedure de novo.

  2008/5/28 Willian Frasson <[EMAIL PROTECTED]>:

  > SQL> EXEC DBMS_TTS.TRANSPORT_SET_CHECK('EXAMPLE', TRUE);
  >
  > Procedimento PL/SQL concluÝdo com sucesso.
  >
  > SQL> select * FROM transport_set_violations;
  >
  > VIOLATIONS
  > --
  >
  > Sys owned object CLIENTE in tablespace EXAMPLE not allowed in pluggable set
  >
  > SQL>
  >
  > essa tabela cliente foi criada para teste somente...
  >
  >
  > - Original Message -
  > From: Willian Frasson
  > To: oracle_br@yahoogrupos.com.br 
  > Sent: Wednesday, May 28, 2008 1:29 PM
  > Subject: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance /
  > 10G RAC Linux (ASM)
  >
  > então mas como os DF estarão em STORAGE, possivelmente podemos fazer a
  > cópia de uma Storage para outra em pouco tempo.
  > Em realação ao documento, ótimo esse documento.. já está salvo o bixo
  > hehehe
  > Irei testar isso... e passo um Feedback para o pessoal.. irei fazer de
  > apenas 500MB aqui na VM para teste... para ver se vai rodar direitinho.
  >
  > - Original Message -
  > From: jlchiappa
  > To: oracle_br@yahoogrupos.com.br 
  > Sent: Wednesday, May 28, 2008 12:52 PM
  > Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G
  > RAC Linux (ASM)
  >
  > É : como o volume desaconelha o export puro, a tua chance é, como eu
  > falei, vc ter uma rede privada muito rápida entre as duas máquinas e
  > OU transferir os dados diretamente via rede de a para B (isto é o
  > datapump), OU copiar via rede os arquivos (isto é o procedimento
  > "transportar as tablespaces"), este último é o que vc montou, vou
  > comenar sobre ele, só mais uma vez lembro vc para MONTAR e TESTAR o
  > datapump enviando dados sem gerar arquivo de dump e a para b, e veja
  > lá o que se sai melhor. Logicamente também, relembro que nos dois
  > procedimentos idealmente vc vai transferir APENAS OS DADOS (via pump)
  > ou APENAS OS DATAFILES COM TABLESPACES DE DADOS (via transport), pois
  > índices e constrants vc RECRIA DEPOIS, com NOLOGGING , PARALLEL,
  > NOVALIDATE, etc.
  >
  > Para o procedimento de transport que vc montou neste e-mail, comento
  > que :
  >
  > a. vamos esclarecer aí o conceito : no RDBMS Oracle, "database" é o
  > conjunto de arquivos em disco (ie, datafiles, initfile, redo log
  > files, tempfiles, etc), ese conjunto pode ser aberto por uma
  > "instância" (ie, conjunto de 'programas executáveis Oracle'), que aí
  > sim forma um BANCO ATIVO, ok ? O RAC nada mais é do que um único
  > database , que reside num storage "shared", que todas as máquinas do
  > cluster enxergam, e esse database é aberto simultaneamente por N
  > instâncias, normalmente cada uma dessas instâncias residindo numa
  > máquina diferente, ok ? Isto posto, imho eu acho que NÃO É PRECISO já
  > neste primeiro passo vc criar as N instâncias, só criar um único
  > database com uma única instância na máquina-destino, depois vc inclui
  > as outras N instãncias cfrme mostrado em
  > http://www.oracle.com/technology/pub/articles/chan_sing2rac_install.html
  > , ok ? Acho que deve ser mais rápido, acho
  >
  > b. a baixa do banco deve ser feita APÓS o export dos metadados
  > apenas, vc NÃO CONSEGUE fazer export com banco baixado
  >
  > c. o export e depois o import dos metadados tanto pode ser feito com
  > exp/imp quando com datapump, são coisas pequenas qquer um vai ter + ou
  > - a mesma performance
  >
  > d. o passo CRÍTICO em termos de performance/adequação à sua janela é
  > a cópia física dos datafiles : experimente ftp, experimente rsh, teste
  > utilitários de download tipo Orbit/wsFTP/fileZilla! que permitem abrir
  > N sessões de cópia/baixa de arquivos (aonde N não pode ser muito alto
  > sob pena de degradar, mais uma vez é o teste que vai te demonstrar
  > isto), veja lá o que dá um tempo m elhor, E não esqueça que os
  > datafiles são BINÁRIOS, a cópia deve ser feita em modo BINÁRIO!!
  >
  > []s
  >
  > Chiappa
  >
  > --- Em oracle_br@yahoogrupos.com.br ,
  > "Willian Frasson" <[EMAIL PROTECTED]>
  > escreveu
  > >

Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC Linux (ASM)

[Fernando Martins]

A tabela informada é do owner sys, por issu o erro, tenta recriar ela em
outro schema <> de sys ou system
e roda a procedure de novo.

2008/5/28 Willian Frasson <[EMAIL PROTECTED]>:

>   SQL> EXEC DBMS_TTS.TRANSPORT_SET_CHECK('EXAMPLE', TRUE);
>
> Procedimento PL/SQL concluÝdo com sucesso.
>
> SQL> select * FROM transport_set_violations;
>
> VIOLATIONS
> --
>
> Sys owned object CLIENTE in tablespace EXAMPLE not allowed in pluggable set
>
> SQL>
>
> essa tabela cliente foi criada para teste somente...
>
>
> - Original Message -
> From: Willian Frasson
> To: oracle_br@yahoogrupos.com.br 
> Sent: Wednesday, May 28, 2008 1:29 PM
> Subject: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance /
> 10G RAC Linux (ASM)
>
> então mas como os DF estarão em STORAGE, possivelmente podemos fazer a
> cópia de uma Storage para outra em pouco tempo.
> Em realação ao documento, ótimo esse documento.. já está salvo o bixo
> hehehe
> Irei testar isso... e passo um Feedback para o pessoal.. irei fazer de
> apenas 500MB aqui na VM para teste... para ver se vai rodar direitinho.
>
> - Original Message -
> From: jlchiappa
> To: oracle_br@yahoogrupos.com.br 
> Sent: Wednesday, May 28, 2008 12:52 PM
> Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G
> RAC Linux (ASM)
>
> É : como o volume desaconelha o export puro, a tua chance é, como eu
> falei, vc ter uma rede privada muito rápida entre as duas máquinas e
> OU transferir os dados diretamente via rede de a para B (isto é o
> datapump), OU copiar via rede os arquivos (isto é o procedimento
> "transportar as tablespaces"), este último é o que vc montou, vou
> comenar sobre ele, só mais uma vez lembro vc para MONTAR e TESTAR o
> datapump enviando dados sem gerar arquivo de dump e a para b, e veja
> lá o que se sai melhor. Logicamente também, relembro que nos dois
> procedimentos idealmente vc vai transferir APENAS OS DADOS (via pump)
> ou APENAS OS DATAFILES COM TABLESPACES DE DADOS (via transport), pois
> índices e constrants vc RECRIA DEPOIS, com NOLOGGING , PARALLEL,
> NOVALIDATE, etc.
>
> Para o procedimento de transport que vc montou neste e-mail, comento
> que :
>
> a. vamos esclarecer aí o conceito : no RDBMS Oracle, "database" é o
> conjunto de arquivos em disco (ie, datafiles, initfile, redo log
> files, tempfiles, etc), ese conjunto pode ser aberto por uma
> "instância" (ie, conjunto de 'programas executáveis Oracle'), que aí
> sim forma um BANCO ATIVO, ok ? O RAC nada mais é do que um único
> database , que reside num storage "shared", que todas as máquinas do
> cluster enxergam, e esse database é aberto simultaneamente por N
> instâncias, normalmente cada uma dessas instâncias residindo numa
> máquina diferente, ok ? Isto posto, imho eu acho que NÃO É PRECISO já
> neste primeiro passo vc criar as N instâncias, só criar um único
> database com uma única instância na máquina-destino, depois vc inclui
> as outras N instãncias cfrme mostrado em
> http://www.oracle.com/technology/pub/articles/chan_sing2rac_install.html
> , ok ? Acho que deve ser mais rápido, acho
>
> b. a baixa do banco deve ser feita APÓS o export dos metadados
> apenas, vc NÃO CONSEGUE fazer export com banco baixado
>
> c. o export e depois o import dos metadados tanto pode ser feito com
> exp/imp quando com datapump, são coisas pequenas qquer um vai ter + ou
> - a mesma performance
>
> d. o passo CRÍTICO em termos de performance/adequação à sua janela é
> a cópia física dos datafiles : experimente ftp, experimente rsh, teste
> utilitários de download tipo Orbit/wsFTP/fileZilla! que permitem abrir
> N sessões de cópia/baixa de arquivos (aonde N não pode ser muito alto
> sob pena de degradar, mais uma vez é o teste que vai te demonstrar
> isto), veja lá o que dá um tempo m elhor, E não esqueça que os
> datafiles são BINÁRIOS, a cópia deve ser feita em modo BINÁRIO!!
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br ,
> "Willian Frasson" <[EMAIL PROTECTED]>
> escreveu
> >
> > Chiappa acho que encontrei algo que deve funcionar, vou testar na VM
> minha aqui.. seria isso:
> > 1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)
> >
> > 2º Cria Banco Todo
> >
> > 3º Instalar Oracle 10 máquina A
> >
> > 4º Fazer upgrade Oracle 9 para Oracle 10
> >
> > 5º Atualizar Patchset máquina A
> >
> > 6º Baixa o Banco
> >
> > 7º Colocar as tablespaces em Read Only: alter tablespace example
> read only;
> >
> > 8º Export 

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

SQL> EXEC DBMS_TTS.TRANSPORT_SET_CHECK('EXAMPLE', TRUE);

Procedimento PL/SQL concluÝdo com sucesso.

SQL> select * FROM transport_set_violations;

VIOLATIONS
--

Sys owned object  CLIENTE in tablespace EXAMPLE not allowed in pluggable set

SQL>

essa tabela cliente foi criada para teste somente...


  - Original Message - 
  From: Willian Frasson 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 1:29 PM
  Subject: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G 
RAC Linux (ASM)


  então mas como os DF estarão em STORAGE, possivelmente podemos fazer a cópia 
de uma Storage para outra em pouco tempo.
  Em realação ao documento, ótimo esse documento.. já está salvo o bixo hehehe
  Irei testar isso... e passo um Feedback para o pessoal.. irei fazer de apenas 
500MB aqui na VM para teste... para ver se vai rodar direitinho.

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 12:52 PM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)

  É : como o volume desaconelha o export puro, a tua chance é, como eu
  falei, vc ter uma rede privada muito rápida entre as duas máquinas e
  OU transferir os dados diretamente via rede de a para B (isto é o
  datapump), OU copiar via rede os arquivos (isto é o procedimento
  "transportar as tablespaces"), este último é o que vc montou, vou
  comenar sobre ele, só mais uma vez lembro vc para MONTAR e TESTAR o
  datapump enviando dados sem gerar arquivo de dump e a para b, e veja
  lá o que se sai melhor. Logicamente também, relembro que nos dois
  procedimentos idealmente vc vai transferir APENAS OS DADOS (via pump)
  ou APENAS OS DATAFILES COM TABLESPACES DE DADOS (via transport), pois
  índices e constrants vc RECRIA DEPOIS, com NOLOGGING , PARALLEL,
  NOVALIDATE, etc.

  Para o procedimento de transport que vc montou neste e-mail, comento
  que :

  a. vamos esclarecer aí o conceito : no RDBMS Oracle, "database" é o
  conjunto de arquivos em disco (ie, datafiles, initfile, redo log
  files, tempfiles, etc), ese conjunto pode ser aberto por uma
  "instância" (ie, conjunto de 'programas executáveis Oracle'), que aí
  sim forma um BANCO ATIVO, ok ? O RAC nada mais é do que um único
  database , que reside num storage "shared", que todas as máquinas do
  cluster enxergam, e esse database é aberto simultaneamente por N
  instâncias, normalmente cada uma dessas instâncias residindo numa
  máquina diferente, ok ? Isto posto, imho eu acho que NÃO É PRECISO já
  neste primeiro passo vc criar as N instâncias, só criar um único
  database com uma única instância na máquina-destino, depois vc inclui
  as outras N instãncias cfrme mostrado em
  http://www.oracle.com/technology/pub/articles/chan_sing2rac_install.html
  , ok ? Acho que deve ser mais rápido, acho

  b. a baixa do banco deve ser feita APÓS o export dos metadados
  apenas, vc NÃO CONSEGUE fazer export com banco baixado

  c. o export e depois o import dos metadados tanto pode ser feito com
  exp/imp quando com datapump, são coisas pequenas qquer um vai ter + ou
  - a mesma performance

  d. o passo CRÍTICO em termos de performance/adequação à sua janela é
  a cópia física dos datafiles : experimente ftp, experimente rsh, teste
  utilitários de download tipo Orbit/wsFTP/fileZilla! que permitem abrir
  N sessões de cópia/baixa de arquivos (aonde N não pode ser muito alto
  sob pena de degradar, mais uma vez é o teste que vai te demonstrar
  isto), veja lá o que dá um tempo m elhor, E não esqueça que os
  datafiles são BINÁRIOS, a cópia deve ser feita em modo BINÁRIO!!

  []s

  Chiappa

  --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > Chiappa acho que encontrei algo que deve funcionar, vou testar na VM
  minha aqui.. seria isso:
  > 1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)
  > 
  > 2º Cria Banco Todo 
  > 
  > 3º Instalar Oracle 10 máquina A
  > 
  > 4º Fazer upgrade Oracle 9 para Oracle 10
  > 
  > 5º Atualizar Patchset máquina A
  > 
  > 6º Baixa o Banco
  > 
  > 7º Colocar as tablespaces em Read Only: alter tablespace example
  read only;
  > 
  > 8º Export do transport tablespaces: expdp system/oracle
  DUMPFILE=example.dmp TRANSPORT_TABLESPACES=example TRANSPORT_FULL_CHECK=Y
  > 
  > 9º Convert dos datafiles com RMAN: convert tablespace example TO
  PLATFORM 'Linux IA (32-bit)' FORMAT 'C:\RMAN\%U';
  > 
  > 10º Copiar DATA FILES da máquina A para máquina B
  > 
  > 11º Import da Estrutura na máquina B: impdp system/oracle
  dumpfile=/tmp/example.dmp directory=data_pump
  transport_data_files=/tmp/example01.dbf, example02.dbf
  > 
  >

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

Já viram esse erro?

Conectado a: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Produc
ion
With the Partitioning, OLAP and Data Mining options
Iniciando "SYS"."SYS_EXPORT_TRANSPORTABLE_01":  sys/ AS SYSDBA DUMPFILE
example.dmp TRANSPORT_TABLESPACES=example TRANSPORT_FULL_CHECK=Y
ORA-39123: Job de tablespace transportßvel do Data Pump abortado
ORA-29341: O conjunto transportßvel nÒo Ú autocontido

O job "SYS"."SYS_EXPORT_TRANSPORTABLE_01" foi interrompido em decorrÛncia de um
erro fatal em 14:47:18


  - Original Message - 
  From: Willian Frasson 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 1:29 PM
  Subject: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G 
RAC Linux (ASM)


  então mas como os DF estarão em STORAGE, possivelmente podemos fazer a cópia 
de uma Storage para outra em pouco tempo.
  Em realação ao documento, ótimo esse documento.. já está salvo o bixo hehehe
  Irei testar isso... e passo um Feedback para o pessoal.. irei fazer de apenas 
500MB aqui na VM para teste... para ver se vai rodar direitinho.

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 12:52 PM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)

  É : como o volume desaconelha o export puro, a tua chance é, como eu
  falei, vc ter uma rede privada muito rápida entre as duas máquinas e
  OU transferir os dados diretamente via rede de a para B (isto é o
  datapump), OU copiar via rede os arquivos (isto é o procedimento
  "transportar as tablespaces"), este último é o que vc montou, vou
  comenar sobre ele, só mais uma vez lembro vc para MONTAR e TESTAR o
  datapump enviando dados sem gerar arquivo de dump e a para b, e veja
  lá o que se sai melhor. Logicamente também, relembro que nos dois
  procedimentos idealmente vc vai transferir APENAS OS DADOS (via pump)
  ou APENAS OS DATAFILES COM TABLESPACES DE DADOS (via transport), pois
  índices e constrants vc RECRIA DEPOIS, com NOLOGGING , PARALLEL,
  NOVALIDATE, etc.

  Para o procedimento de transport que vc montou neste e-mail, comento
  que :

  a. vamos esclarecer aí o conceito : no RDBMS Oracle, "database" é o
  conjunto de arquivos em disco (ie, datafiles, initfile, redo log
  files, tempfiles, etc), ese conjunto pode ser aberto por uma
  "instância" (ie, conjunto de 'programas executáveis Oracle'), que aí
  sim forma um BANCO ATIVO, ok ? O RAC nada mais é do que um único
  database , que reside num storage "shared", que todas as máquinas do
  cluster enxergam, e esse database é aberto simultaneamente por N
  instâncias, normalmente cada uma dessas instâncias residindo numa
  máquina diferente, ok ? Isto posto, imho eu acho que NÃO É PRECISO já
  neste primeiro passo vc criar as N instâncias, só criar um único
  database com uma única instância na máquina-destino, depois vc inclui
  as outras N instãncias cfrme mostrado em
  http://www.oracle.com/technology/pub/articles/chan_sing2rac_install.html
  , ok ? Acho que deve ser mais rápido, acho

  b. a baixa do banco deve ser feita APÓS o export dos metadados
  apenas, vc NÃO CONSEGUE fazer export com banco baixado

  c. o export e depois o import dos metadados tanto pode ser feito com
  exp/imp quando com datapump, são coisas pequenas qquer um vai ter + ou
  - a mesma performance

  d. o passo CRÍTICO em termos de performance/adequação à sua janela é
  a cópia física dos datafiles : experimente ftp, experimente rsh, teste
  utilitários de download tipo Orbit/wsFTP/fileZilla! que permitem abrir
  N sessões de cópia/baixa de arquivos (aonde N não pode ser muito alto
  sob pena de degradar, mais uma vez é o teste que vai te demonstrar
  isto), veja lá o que dá um tempo m elhor, E não esqueça que os
  datafiles são BINÁRIOS, a cópia deve ser feita em modo BINÁRIO!!

  []s

  Chiappa

  --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > Chiappa acho que encontrei algo que deve funcionar, vou testar na VM
  minha aqui.. seria isso:
  > 1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)
  > 
  > 2º Cria Banco Todo 
  > 
  > 3º Instalar Oracle 10 máquina A
  > 
  > 4º Fazer upgrade Oracle 9 para Oracle 10
  > 
  > 5º Atualizar Patchset máquina A
  > 
  > 6º Baixa o Banco
  > 
  > 7º Colocar as tablespaces em Read Only: alter tablespace example
  read only;
  > 
  > 8º Export do transport tablespaces: expdp system/oracle
  DUMPFILE=example.dmp TRANSPORT_TABLESPACES=example TRANSPORT_FULL_CHECK=Y
  > 
  > 9º Convert dos datafiles com RMAN: convert tablespace example TO
  PLATFORM 'Linux IA (32-bit)' FORMAT 'C:\RMAN\%U';
  > 
  > 10º Copiar DATA FILES da máquina A para máquina B
  > 
  > 11º Impor

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

então mas como os DF estarão em STORAGE, possivelmente podemos fazer  a cópia 
de uma Storage para outra em pouco tempo.
Em realação ao documento, ótimo esse documento.. já está salvo o bixo hehehe
Irei testar isso... e passo um Feedback para o pessoal.. irei fazer de apenas 
500MB aqui na VM para teste... para ver se vai rodar direitinho.

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 12:52 PM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)


  É : como o volume desaconelha o export puro, a tua chance é, como eu
  falei, vc ter uma rede privada muito rápida entre as duas máquinas e
  OU transferir os dados diretamente via rede de a para B (isto é o
  datapump), OU copiar via rede os arquivos (isto é o procedimento
  "transportar as tablespaces"), este último é o que vc montou, vou
  comenar sobre ele, só mais uma vez lembro vc para MONTAR e TESTAR o
  datapump enviando dados sem gerar arquivo de dump e a para b, e veja
  lá o que se sai melhor. Logicamente também, relembro que nos dois
  procedimentos idealmente vc vai transferir APENAS OS DADOS (via pump)
  ou APENAS OS DATAFILES COM TABLESPACES DE DADOS (via transport), pois
  índices e constrants vc RECRIA DEPOIS, com NOLOGGING , PARALLEL,
  NOVALIDATE, etc.

  Para o procedimento de transport que vc montou neste e-mail, comento
  que :

  a. vamos esclarecer aí o conceito : no RDBMS Oracle, "database" é o
  conjunto de arquivos em disco (ie, datafiles, initfile, redo log
  files, tempfiles, etc), ese conjunto pode ser aberto por uma
  "instância" (ie, conjunto de 'programas executáveis Oracle'), que aí
  sim forma um BANCO ATIVO, ok ? O RAC nada mais é do que um único
  database , que reside num storage "shared", que todas as máquinas do
  cluster enxergam, e esse database é aberto simultaneamente por N
  instâncias, normalmente cada uma dessas instâncias residindo numa
  máquina diferente, ok ? Isto posto, imho eu acho que NÃO É PRECISO já
  neste primeiro passo vc criar as N instâncias, só criar um único
  database com uma única instância na máquina-destino, depois vc inclui
  as outras N instãncias cfrme mostrado em
  http://www.oracle.com/technology/pub/articles/chan_sing2rac_install.html
  , ok ? Acho que deve ser mais rápido, acho

  b. a baixa do banco deve ser feita APÓS o export dos metadados
  apenas, vc NÃO CONSEGUE fazer export com banco baixado

  c. o export e depois o import dos metadados tanto pode ser feito com
  exp/imp quando com datapump, são coisas pequenas qquer um vai ter + ou
  - a mesma performance

  d. o passo CRÍTICO em termos de performance/adequação à sua janela é
  a cópia física dos datafiles : experimente ftp, experimente rsh, teste
  utilitários de download tipo Orbit/wsFTP/fileZilla! que permitem abrir
  N sessões de cópia/baixa de arquivos (aonde N não pode ser muito alto
  sob pena de degradar, mais uma vez é o teste que vai te demonstrar
  isto), veja lá o que dá um tempo m elhor, E não esqueça que os
  datafiles são BINÁRIOS, a cópia deve ser feita em modo BINÁRIO!!

  []s

  Chiappa

  --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > Chiappa acho que encontrei algo que deve funcionar, vou testar na VM
  minha aqui.. seria isso:
  > 1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)
  > 
  > 2º Cria Banco Todo 
  > 
  > 3º Instalar Oracle 10 máquina A
  > 
  > 4º Fazer upgrade Oracle 9 para Oracle 10
  > 
  > 5º Atualizar Patchset máquina A
  > 
  > 6º Baixa o Banco
  > 
  > 7º Colocar as tablespaces em Read Only: alter tablespace example
  read only;
  > 
  > 8º Export do transport tablespaces: expdp system/oracle
  DUMPFILE=example.dmp TRANSPORT_TABLESPACES=example TRANSPORT_FULL_CHECK=Y
  > 
  > 9º Convert dos datafiles com RMAN: convert tablespace example TO
  PLATFORM 'Linux IA (32-bit)' FORMAT 'C:\RMAN\%U';
  > 
  > 10º Copiar DATA FILES da máquina A para máquina B
  > 
  > 11º Import da Estrutura na máquina B: impdp system/oracle
  dumpfile=/tmp/example.dmp directory=data_pump
  transport_data_files=/tmp/example01.dbf, example02.dbf
  > 
  > 
  > 
  > - Original Message - 
  > From: jlchiappa 
  > To: oracle_br@yahoogrupos.com.br 
  > Sent: Wednesday, May 28, 2008 10:43 AM
  > Subject: [oracle_br] Re: Migração Oracle 9i Windows Single
  Instance / 10G RAC Linux (ASM)
  > 
  > 
  > O complicador aí em relação ao tamanho total, que pode inviabilizar o
  > exp numa base de 1 Tb, é que :
  > 
  > a) vc tem que arranjar o espaço no disco local pra gerar o dump,
  > coisa de 100 Gb é difícil mas vc até arranja, já 1 Tb conheço POUCAS
  > máquinas prod com 1 Tb sobrando...
  > 
  > b) vc vai querer abrir várias sessões de export, MAS (óbvio)
  > certamente os discos são os mesmos pra todos os schemas, a
  > controladora é a mesma, há concorência, quantas mais sessões
  > simultâneas vc abrir, mais degrada a performance : va

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

Chiappa acho que encontrei algo que deve funcionar, vou testar na VM minha 
aqui.. seria isso:
1º Instalar Banco B - Clusterware, ASM, Database, Pathset (Nó1, Nó2)

2º Cria Banco Todo 

3º Instalar Oracle 10 máquina A

4º Fazer upgrade Oracle 9 para Oracle 10

5º Atualizar Patchset máquina A

6º Baixa o Banco

7º Colocar as tablespaces em Read Only:  alter tablespace example read only;

8º Export do transport tablespaces: expdp system/oracle DUMPFILE=example.dmp 
TRANSPORT_TABLESPACES=example TRANSPORT_FULL_CHECK=Y

9º Convert dos datafiles com RMAN: convert tablespace example TO PLATFORM 
'Linux IA (32-bit)' FORMAT 'C:\RMAN\%U';

10º Copiar DATA FILES  da máquina A para máquina B

11º Import da Estrutura na máquina B: impdp system/oracle 
dumpfile=/tmp/example.dmp directory=data_pump 
transport_data_files=/tmp/example01.dbf, example02.dbf



  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 10:43 AM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)


  O complicador aí em relação ao tamanho total, que pode inviabilizar o
  exp numa base de 1 Tb, é que :

  a) vc tem que arranjar o espaço no disco local pra gerar o dump,
  coisa de 100 Gb é difícil mas vc até arranja, já 1 Tb conheço POUCAS
  máquinas prod com 1 Tb sobrando...

  b) vc vai querer abrir várias sessões de export, MAS (óbvio)
  certamente os discos são os mesmos pra todos os schemas, a
  controladora é a mesma, há concorência, quantas mais sessões
  simultâneas vc abrir, mais degrada a performance : vamos supor que é
  um RAID, hardware de produção mesmo, que assim vc consiga ter 3
  sessões simultâneas

  c) tipicamente a performance dum export local com as opções todas
  citadas, num hardware de produção, SEM concorrência, exportando só as
  linhas da tabela, etc etc, é coisa de 1 GB por minuto, ou pouco mais,
  um exemplo na minha máquina de testes (disco SATA, 2 Gb de RAM) :

  [EMAIL PROTECTED]:SQL>select count(*) from TAB_2G;

  COUNT(*)
  --
  257340

  [EMAIL PROTECTED]:SQL>select bytes from user_segments where 
segment_name='TAB_2G';

  BYTES
  --
  2147483648

  C:\>exp system/[EMAIL PROTECTED] file=teste_2g log=teste_2g.exp direct=y
  buffer=1048
  5760 recordlength=65535 triggers=n constraints=n indexes=n
  statistics=none recor
  d=n tables=sys.TAB_2G feedback=10

  Export: Release 10.2.0.4.0 - Production on Qua Mai 28 10:20:48 2008

  Copyright (c) 1982, 2007, Oracle. All rights reserved.

  Conectado a: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0
  - Product
  ion
  With the Partitioning, Oracle Label Security, OLAP, Data Mining
  Scoring Engine
  and Real Application Testing options
  ExportaþÒo executada no conjunto de caracteres de WE8MSWIN1252 e no
  conjunto de
  caracteres de AL16UTF16 NCHAR
  Obs.: Ýndices em tabelas nÒo serÒo exportados
  Obs.: restriþ§es em tabelas nÒo serÒo exportadas

  Sobre exportar tabelas especificadas ... via Caminho Direto ...
  O usußrio atual foi alterado para SYS
  . . exportando tabela TAB_2G
  ..
  257340 linhas
  exportadas
  ExportaþÒo encerrada com sucesso, sem advertÛncias.

  C:\>dir teste_2g.dmp
  Pasta de C:\

  28/05/2008 10:22 1.031.455.365 teste_2g.DMP

  ==> ou seja, coisa de 2 minutos pra exportar coisa de 2 Gb, yes ?
  LÓGICO, vc vai testar no seu hardware, mas acho que 1 Gb/minuto é um
  mínimo em aceitável, muito provável de se obter, legal ?
  Muito bem, fazendo uma conta de padeiro, se formos exportar 100 Gb no
  total e termos 3 sessões cada uma exportando 33 Gb, levaríamos coisa
  de pouco mais de meia hora (33 minutos) só pro export, tá tranquila a
  tua janela, creio... . Já 1 Tb, se cada uma das 3 sessões exportar uns
  333 Gb, já batemos 333 minutos, ou seja mais de CINCO HORAS, a tua
  janela FOI PRO BREJO, yes ?? Ainda que vc tivesse um hardware
  realmente bom que permitisse, digamos, 5 sessões simultâneas lendo a
  mesma fonte sem degradação grande, cada uma exportando 200 Gb do 1 Tb
  total, já foram 200 minutos, mais de duas horas, quase acabou a tua
  janela só aí...
  Então a regra de dedão é clara, exp vai bem até um certo volume

  []s

  Chiappa

  --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > hm então inicialmente tinha colocado para o Pessoal 100GB mas na
  verdade a base do cliente é 1 TeraByte msmo...
  > Mas então é complicado mas que se por ex... fizer da forma que
  fizemos com export realmente... mas imaginamos...
  > são 5 OWNERS no sistema principal:
  > 200 GB cada um:
  > 
  > Export OWNER 1 (da forma que montamos, sem indices)
  > como estará o mesmo na Storage, terminando esse OWNER já deixamos o
  mesmo importando na máquina B
  > enquanto isso...Export OWNER 2 (da forma que montamos, sem
  indices)
  > como estará o mesmo na Storage, terminando esse OWNER2 já deixamos o
  mesmo importando na máquina B
  > e assim sucessivament

Re: [oracle_br] Re: Migração Oracle 9i W indows Single Instance / 10G RAC Linux (ASM)

[Marco Souza]

Batendo na mesma tecla do uso do export/import. Eu nunca usei, mas alguém já 
fez o teste com export incremental ?
Não poderia ser aplicado nesta situação ?
Um export full e uma importação na nova base e finalmente um export incremental 
e um import final.  Eu particularmente nunca fiz esse teste, mas isso não 
resolveria o problema ?




jlchiappa <[EMAIL PROTECTED]> escreveu: O 
complicador aí em relação ao tamanho total, que pode inviabilizar o
 exp numa base de 1 Tb, é que :
 
 a) vc tem que arranjar o espaço no disco local pra gerar o dump,
 coisa de 100 Gb é difícil mas vc até arranja, já 1 Tb conheço POUCAS
 máquinas prod com 1 Tb sobrando...
 
 b) vc vai querer abrir várias sessões de export, MAS (óbvio)
 certamente os discos são os mesmos pra todos os schemas, a
 controladora é a mesma, há concorência, quantas mais sessões
 simultâneas vc abrir, mais degrada a performance : vamos supor que é
 um RAID, hardware de produção mesmo, que assim vc consiga ter 3
 sessões simultâneas
  
  c) tipicamente a performance dum export local com as opções todas
 citadas, num hardware de produção, SEM concorrência, exportando só as
 linhas da tabela, etc etc, é coisa de 1 GB por minuto, ou pouco mais,
 um exemplo na minha máquina de testes (disco SATA, 2 Gb de RAM) :
 
 [EMAIL PROTECTED]:SQL>select count(*) from TAB_2G;
 
 COUNT(*)
 --
 257340
 
 [EMAIL PROTECTED]:SQL>select bytes from user_segments where 
segment_name='TAB_2G';
 
 BYTES
 --
 2147483648
 
 C:\>exp system/[EMAIL PROTECTED] file=teste_2g log=teste_2g.exp direct=y
 buffer=1048
 5760 recordlength=65535 triggers=n constraints=n indexes=n
 statistics=none recor
 d=n tables=sys.TAB_2G feedback=10
 
 Export: Release 10.2.0.4.0 - Production on Qua Mai 28 10:20:48 2008
 
 Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
 Conectado a: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0
 - Product
 ion
 With the Partitioning, Oracle Label Security, OLAP, Data Mining
 Scoring Engine
 and Real Application Testing options
 ExportaþÒo executada no conjunto de caracteres de WE8MSWIN1252  e no
 conjunto de
  caracteres de AL16UTF16 NCHAR
 Obs.: Ýndices em tabelas nÒo serÒo exportados
 Obs.: restriþ§es em tabelas nÒo serÒo exportadas
 
 Sobre exportar tabelas especificadas ... via Caminho Direto ...
 O usußrio atual foi alterado para SYS
 . . exportando tabela TAB_2G
 ..
257340 linhas
 exportadas
 ExportaþÒo encerrada com sucesso, sem advertÛncias.
 
 C:\>dir teste_2g.dmp
  Pasta de C:\
 
 28/05/2008  10:22 1.031.455.365 teste_2g.DMP
 
 ==> ou seja, coisa de 2 minutos pra exportar coisa de 2 Gb, yes ?
 LÓGICO, vc vai testar no seu hardware, mas acho que 1 Gb/minuto é um
 mínimo em aceitável, muito provável de se obter, legal ?
  Muito bem, fazendo uma conta de padeiro, se formos exportar 100 Gb no
 total e termos 3 sessões cada uma exportando 33 Gb, levaríamos coisa
 de pouco mais de meia hora (33 minutos) só pro export, tá tranquila a
 tua janela, creio... . Já 1 Tb, se cada uma das 3 sessões exportar uns
 333 Gb, já batemos 333 minutos, ou seja mais de CINCO HORAS, a tua
 janela FOI PRO BREJO, yes ?? Ainda que vc tivesse um hardware
 realmente bom que permitisse, digamos, 5 sessões simultâneas lendo a
 mesma fonte sem degradação grande, cada uma exportando 200 Gb do 1 Tb
 total, já foram 200 minutos, mais de duas horas, quase acabou a tua
 janela só aí...
   Então a regra de dedão é clara, exp vai bem até um certo volume
 
 []s
 
 Chiappa
  
 --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
 escreveu
 >
 > hm então inicialmente tinha colocado para o Pessoal 100GB mas na
 verdade a base do cliente é 1 TeraByte msmo...
 > Mas então é complicado mas que se por ex... fizer da forma que
 fizemos com export realmente... mas imaginamos...
 > são 5 OWNERS no sistema principal:
 > 200 GB cada um:
 > 
 > Export OWNER 1 (da forma que montamos, sem indices)
 > como estará o mesmo na Storage, terminando esse OWNER já deixamos o
 mesmo importando na máquina B
 > enquanto isso...Export OWNER 2 (da forma que montamos, sem
 indices)
 > como estará o mesmo na Storage, terminando esse OWNER2 já deixamos o
 mesmo importando na máquina B
 > e assim sucessivamente...
 > 
 > 
 >   - Original Message - 
 >   From: jlchiappa 
 >   To: oracle_br@yahoogrupos.com.br 
 >   Sent: Wednesday, May 28, 2008 4:03 AM
 >   Subject: [oracle_br] Re: Migração Oracle 9i Windows Single
 Instance / 10G RAC Linux (ASM)
 > 
 > 
 >   --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" 
 >   escreveu
 >   >
 >   > Chiappa então mas a Janela é de 2 a 3 horas no máximo para migrar 1
 >   Tera 
 > 
 >   OPA OPA, pára tudo aí : na msg original vc tinha dito :
 > 
 >   > > Tenho uma Base de ** 100 GB ** por ex que está no Oracle 9i em
 >   Windows,"
 > 
 >   ==> 100 Gb ou coisa próxi

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

Galera tenho um documento aqui que eu já até tinha o mesmo que não tinha 
pensado nessa idéia... vou usar o mesmo e testar a única coisa que não tem no 
documento
é a instalação do Oracle10 na máquina A, e fazer atualização do 9 para o 10 
ainda no Windows... + instalação e atualização do patchset.

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 4:03 AM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)


  --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > Chiappa então mas a Janela é de 2 a 3 horas no máximo para migrar 1
  Tera 

  OPA OPA, pára tudo aí : na msg original vc tinha dito :

  > > Tenho uma Base de ** 100 GB ** por ex que está no Oracle 9i em
  Windows,"

  ==> 100 Gb ou coisa próxima é plenamente factível, talvez até mesmo
  com export ou datapump como falei, MAS 1 Terabyte é OUTRO BICHINHO, é
  um animalzinho ABSOLUTAMENTE DIFERENTE, nada a ver, num nível de
  volume desses a coisa muda TOTALMENTE de figura, começa a ficar muito
  MUITO difícil vc completar essa tarefa nessa janela. Veja vc, num
  volume assim pra começo de conversa o export necessariamente tem que
  gerar o dump em disco, num volume desses o dump mesmo que só de dados)
  certamente ia ficar na casa das várias centenas de Gb, esqueça, o puro
  overhead de vc gerar algo assim já te quebra. Assim, as suas opções
  seriam mesmo (uma vez criado o banco 10g destino vazio, banco origem
  migrado pra 10g, etc) OU o datapump (numa rede gigabit dedicada, sem
  ninguém mais nela, pode dar uma performance boa), OU transportar as
  tablespaces com dados dos usuários pra lá. Lógico, só mesmo ao vc
  FAZER UM TESTE parcial das opções (preferencialmente em máquinas de
  homologação, idênticas às produão) é que vc vai ver no seu ambiente
  qual é a melhor, ok ? E é esse teste que vai te demonstrar se é
  factível esse volume de 1 Tb nessa janela de duas ou três horas, ok ?
  É difícil, como eu disse, mas até pode acontecer

  []s

  Chiappa

  OBS : num volume desses certamente o banco original está num storage
  também : SE for o mesmo modelo (ou ao menos do mesmo fabricante)do
  storage destino, VEJA COM O TEU SUPORTE DE STORAGE se há utilitário
  nativo para exportar os arquivos Oracle do storage original para o
  destino, sei que alguns fabricantes tem coisas do tipo. SE tiver, aí a
  opção seria fazer o transporte das tablespaces, mas gerando os
  metadados com export transportable=y e na hora de passar os arquivos
  pro destino ao invés de usar o comando de cópia ou de ftp do SO vc
  usaria o tal utilitário, ele é nativo, muitas vezes ele é mais
  eficiente do que o SO, que é genérico, é um layer a mais em cima do
  hardware.



   

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

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

Galera tenho um documento aqui que eu já até tinha o mesmo que não tinha 
pensado nessa idéia... vou usar o mesmo e testar a única coisa que não tem no 
documento
é a instalação do Oracle10 na máquina A, e fazer atualização do 9 para o 10 
ainda no Windows... + instalação e atualização do patchset.

  - Original Message - 
  From: Willian Frasson 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 9:23 AM
  Subject: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G 
RAC Linux (ASM)


  usando EXP mesmo ou EXPDP ?

  - Original Message - 
  From: Rafael Almeida Milanez 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 9:16 AM
  Subject: RES: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 
10G RAC Linux (ASM)

  Para versões de SO diferentes somente da 10g em diante permite

  

  De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Willian 
Frasson
  Enviada em: quarta-feira, 28 de maio de 2008 09:03
  Para: oracle_br@yahoogrupos.com.br
  Assunto: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G 
RAC Linux (ASM)

  Uma coisa.. que nunca usei foi o transport tablespaces... alguem sabe dizer 
se... podem ser feitos em versões diferentes do banco (9i par 10g ASM) e 
versões... de SO
  diferentes?
  abçs..

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> 
  Sent: Wednesday, May 28, 2008 4:03 AM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)

  --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , 
"Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > Chiappa então mas a Janela é de 2 a 3 horas no máximo para migrar 1
  Tera 

  OPA OPA, pára tudo aí : na msg original vc tinha dito :

  > > Tenho uma Base de ** 100 GB ** por ex que está no Oracle 9i em
  Windows,"

  ==> 100 Gb ou coisa próxima é plenamente factível, talvez até mesmo
  com export ou datapump como falei, MAS 1 Terabyte é OUTRO BICHINHO, é
  um animalzinho ABSOLUTAMENTE DIFERENTE, nada a ver, num nível de
  volume desses a coisa muda TOTALMENTE de figura, começa a ficar muito
  MUITO difícil vc completar essa tarefa nessa janela. Veja vc, num
  volume assim pra começo de conversa o export necessariamente tem que
  gerar o dump em disco, num volume desses o dump mesmo que só de dados)
  certamente ia ficar na casa das várias centenas de Gb, esqueça, o puro
  overhead de vc gerar algo assim já te quebra. Assim, as suas opções
  seriam mesmo (uma vez criado o banco 10g destino vazio, banco origem
  migrado pra 10g, etc) OU o datapump (numa rede gigabit dedicada, sem
  ninguém mais nela, pode dar uma performance boa), OU transportar as
  tablespaces com dados dos usuários pra lá. Lógico, só mesmo ao vc
  FAZER UM TESTE parcial das opções (preferencialmente em máquinas de
  homologação, idênticas às produão) é que vc vai ver no seu ambiente
  qual é a melhor, ok ? E é esse teste que vai te demonstrar se é
  factível esse volume de 1 Tb nessa janela de duas ou três horas, ok ?
  É difícil, como eu disse, mas até pode acontecer

  []s

  Chiappa

  OBS : num volume desses certamente o banco original está num storage
  também : SE for o mesmo modelo (ou ao menos do mesmo fabricante)do
  storage destino, VEJA COM O TEU SUPORTE DE STORAGE se há utilitário
  nativo para exportar os arquivos Oracle do storage original para o
  destino, sei que alguns fabricantes tem coisas do tipo. SE tiver, aí a
  opção seria fazer o transporte das tablespaces, mas gerando os
  metadados com export transportable=y e na hora de passar os arquivos
  pro destino ao invés de usar o comando de cópia ou de ftp do SO vc
  usaria o tal utilitário, ele é nativo, muitas vezes ele é mais
  eficiente do que o SO, que é genérico, é um layer a mais em cima do
  hardware.

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

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

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



   

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

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

usando EXP mesmo ou EXPDP ?

  - Original Message - 
  From: Rafael Almeida Milanez 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 9:16 AM
  Subject: RES: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 
10G RAC Linux (ASM)


  Para versões de SO diferentes somente da 10g em diante permite

  

  De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Willian 
Frasson
  Enviada em: quarta-feira, 28 de maio de 2008 09:03
  Para: oracle_br@yahoogrupos.com.br
  Assunto: Re: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G 
RAC Linux (ASM)

  Uma coisa.. que nunca usei foi o transport tablespaces... alguem sabe dizer 
se... podem ser feitos em versões diferentes do banco (9i par 10g ASM) e 
versões... de SO
  diferentes?
  abçs..

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> 
  Sent: Wednesday, May 28, 2008 4:03 AM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)

  --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , 
"Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > Chiappa então mas a Janela é de 2 a 3 horas no máximo para migrar 1
  Tera 

  OPA OPA, pára tudo aí : na msg original vc tinha dito :

  > > Tenho uma Base de ** 100 GB ** por ex que está no Oracle 9i em
  Windows,"

  ==> 100 Gb ou coisa próxima é plenamente factível, talvez até mesmo
  com export ou datapump como falei, MAS 1 Terabyte é OUTRO BICHINHO, é
  um animalzinho ABSOLUTAMENTE DIFERENTE, nada a ver, num nível de
  volume desses a coisa muda TOTALMENTE de figura, começa a ficar muito
  MUITO difícil vc completar essa tarefa nessa janela. Veja vc, num
  volume assim pra começo de conversa o export necessariamente tem que
  gerar o dump em disco, num volume desses o dump mesmo que só de dados)
  certamente ia ficar na casa das várias centenas de Gb, esqueça, o puro
  overhead de vc gerar algo assim já te quebra. Assim, as suas opções
  seriam mesmo (uma vez criado o banco 10g destino vazio, banco origem
  migrado pra 10g, etc) OU o datapump (numa rede gigabit dedicada, sem
  ninguém mais nela, pode dar uma performance boa), OU transportar as
  tablespaces com dados dos usuários pra lá. Lógico, só mesmo ao vc
  FAZER UM TESTE parcial das opções (preferencialmente em máquinas de
  homologação, idênticas às produão) é que vc vai ver no seu ambiente
  qual é a melhor, ok ? E é esse teste que vai te demonstrar se é
  factível esse volume de 1 Tb nessa janela de duas ou três horas, ok ?
  É difícil, como eu disse, mas até pode acontecer

  []s

  Chiappa

  OBS : num volume desses certamente o banco original está num storage
  também : SE for o mesmo modelo (ou ao menos do mesmo fabricante)do
  storage destino, VEJA COM O TEU SUPORTE DE STORAGE se há utilitário
  nativo para exportar os arquivos Oracle do storage original para o
  destino, sei que alguns fabricantes tem coisas do tipo. SE tiver, aí a
  opção seria fazer o transporte das tablespaces, mas gerando os
  metadados com export transportable=y e na hora de passar os arquivos
  pro destino ao invés de usar o comando de cópia ou de ftp do SO vc
  usaria o tal utilitário, ele é nativo, muitas vezes ele é mais
  eficiente do que o SO, que é genérico, é um layer a mais em cima do
  hardware.

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

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



   

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

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

Uma coisa.. que nunca usei foi o transport tablespaces... alguem sabe dizer 
se... podem ser feitos em versões diferentes do banco (9i par 10g ASM) e 
versões... de SO
diferentes?
abçs..

  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 4:03 AM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)


  --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > Chiappa então mas a Janela é de 2 a 3 horas no máximo para migrar 1
  Tera 

  OPA OPA, pára tudo aí : na msg original vc tinha dito :

  > > Tenho uma Base de ** 100 GB ** por ex que está no Oracle 9i em
  Windows,"

  ==> 100 Gb ou coisa próxima é plenamente factível, talvez até mesmo
  com export ou datapump como falei, MAS 1 Terabyte é OUTRO BICHINHO, é
  um animalzinho ABSOLUTAMENTE DIFERENTE, nada a ver, num nível de
  volume desses a coisa muda TOTALMENTE de figura, começa a ficar muito
  MUITO difícil vc completar essa tarefa nessa janela. Veja vc, num
  volume assim pra começo de conversa o export necessariamente tem que
  gerar o dump em disco, num volume desses o dump mesmo que só de dados)
  certamente ia ficar na casa das várias centenas de Gb, esqueça, o puro
  overhead de vc gerar algo assim já te quebra. Assim, as suas opções
  seriam mesmo (uma vez criado o banco 10g destino vazio, banco origem
  migrado pra 10g, etc) OU o datapump (numa rede gigabit dedicada, sem
  ninguém mais nela, pode dar uma performance boa), OU transportar as
  tablespaces com dados dos usuários pra lá. Lógico, só mesmo ao vc
  FAZER UM TESTE parcial das opções (preferencialmente em máquinas de
  homologação, idênticas às produão) é que vc vai ver no seu ambiente
  qual é a melhor, ok ? E é esse teste que vai te demonstrar se é
  factível esse volume de 1 Tb nessa janela de duas ou três horas, ok ?
  É difícil, como eu disse, mas até pode acontecer

  []s

  Chiappa

  OBS : num volume desses certamente o banco original está num storage
  também : SE for o mesmo modelo (ou ao menos do mesmo fabricante)do
  storage destino, VEJA COM O TEU SUPORTE DE STORAGE se há utilitário
  nativo para exportar os arquivos Oracle do storage original para o
  destino, sei que alguns fabricantes tem coisas do tipo. SE tiver, aí a
  opção seria fazer o transporte das tablespaces, mas gerando os
  metadados com export transportable=y e na hora de passar os arquivos
  pro destino ao invés de usar o comando de cópia ou de ftp do SO vc
  usaria o tal utilitário, ele é nativo, muitas vezes ele é mais
  eficiente do que o SO, que é genérico, é um layer a mais em cima do
  hardware.



   

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

Re: [oracle_br] Re: Migração Oracle 9i Windo ws Single Instance / 10G RAC Linux (ASM)

[Willian Frasson]

hm então inicialmente tinha colocado para o Pessoal 100GB mas na verdade a base 
do cliente é 1 TeraByte msmo...
Mas então é complicado mas que se por ex... fizer da forma que fizemos com 
export realmente... mas imaginamos...
são 5 OWNERS no sistema principal:
200 GB cada um:

Export OWNER 1 (da forma que montamos, sem indices)
como estará o mesmo na Storage, terminando esse OWNER já deixamos o mesmo 
importando na máquina B
enquanto isso...Export OWNER 2 (da forma que montamos, sem indices)
como estará o mesmo na Storage, terminando esse OWNER2 já deixamos o mesmo 
importando na máquina B
e assim sucessivamente...


  - Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Wednesday, May 28, 2008 4:03 AM
  Subject: [oracle_br] Re: Migração Oracle 9i Windows Single Instance / 10G RAC 
Linux (ASM)


  --- Em oracle_br@yahoogrupos.com.br, "Willian Frasson" <[EMAIL PROTECTED]>
  escreveu
  >
  > Chiappa então mas a Janela é de 2 a 3 horas no máximo para migrar 1
  Tera 

  OPA OPA, pára tudo aí : na msg original vc tinha dito :

  > > Tenho uma Base de ** 100 GB ** por ex que está no Oracle 9i em
  Windows,"

  ==> 100 Gb ou coisa próxima é plenamente factível, talvez até mesmo
  com export ou datapump como falei, MAS 1 Terabyte é OUTRO BICHINHO, é
  um animalzinho ABSOLUTAMENTE DIFERENTE, nada a ver, num nível de
  volume desses a coisa muda TOTALMENTE de figura, começa a ficar muito
  MUITO difícil vc completar essa tarefa nessa janela. Veja vc, num
  volume assim pra começo de conversa o export necessariamente tem que
  gerar o dump em disco, num volume desses o dump mesmo que só de dados)
  certamente ia ficar na casa das várias centenas de Gb, esqueça, o puro
  overhead de vc gerar algo assim já te quebra. Assim, as suas opções
  seriam mesmo (uma vez criado o banco 10g destino vazio, banco origem
  migrado pra 10g, etc) OU o datapump (numa rede gigabit dedicada, sem
  ninguém mais nela, pode dar uma performance boa), OU transportar as
  tablespaces com dados dos usuários pra lá. Lógico, só mesmo ao vc
  FAZER UM TESTE parcial das opções (preferencialmente em máquinas de
  homologação, idênticas às produão) é que vc vai ver no seu ambiente
  qual é a melhor, ok ? E é esse teste que vai te demonstrar se é
  factível esse volume de 1 Tb nessa janela de duas ou três horas, ok ?
  É difícil, como eu disse, mas até pode acontecer

  []s

  Chiappa

  OBS : num volume desses certamente o banco original está num storage
  também : SE for o mesmo modelo (ou ao menos do mesmo fabricante)do
  storage destino, VEJA COM O TEU SUPORTE DE STORAGE se há utilitário
  nativo para exportar os arquivos Oracle do storage original para o
  destino, sei que alguns fabricantes tem coisas do tipo. SE tiver, aí a
  opção seria fazer o transporte das tablespaces, mas gerando os
  metadados com export transportable=y e na hora de passar os arquivos
  pro destino ao invés de usar o comando de cópia ou de ftp do SO vc
  usaria o tal utilitário, ele é nativo, muitas vezes ele é mais
  eficiente do que o SO, que é genérico, é um layer a mais em cima do
  hardware.



   

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

Re:[oracle_br] Re: Migração 8i pa ra 10g

[terra_banco]

Valeu novamente as dicas.

Abraço,

De:oracle_br@yahoogrupos.com.br

Para:oracle_br@yahoogrupos.com.br

Cópia:

Data:Mon, 14 Apr 2008 23:43:04 -

Assunto:[oracle_br] Re: Migração 8i para 10g

Depende, se o banco é relativamente "pequeno" - tipo no total tem
coisa de uns poucos Gbs apenas, nitidamente menos de 1 dúzia deels,
algo assim - , exp/imp é bem viável, já se estamos falando de algo
muito maior que isso, passa a não ser viável esse caminho, aí então o
caminho seria instalar em outra oracle_home os binários 10g, baixar o
banco 8i e migrar os arquivos que estão na versão 8i pra versão 10g, e
depois disso abrir esse banco (conjunto de arquivos em disco) com os
binários 10g. lembro que DEPENDENDO da versão exata de 8i na origem e
de 10g no destino, PODE SER preciso patches, cheque o manual de
Migração/Upgrade da versão 10g que vc deseja para mais info.

[]s

Chiappa
--- Em oracle_br@yahoogrupos.com.br, "Robson \(Terra\)"
<[EMAIL PROTECTED]> escreveu
>
> Boa noite.
> 
> 
> 
> Pessoal, poderiam me passar a maneira mais simples para migração de um
> banco Oracle 8i para Oracle 10g?
> 
> 
> 
> Seria instalar o banco na mesma configuração e fazer um export no 8i e
> import no 10g?
> 
> 
> 
> Agradeço toda ajuda.
> 
> 
> 
> At,
> 
> 
> 
> Robson.
> 
> 
> No virus found in this outgoing message.
> Checked by AVG. 
> Version: 7.5.519 / Virus Database: 269.22.13/1376 - Release Date:
13/4/2008
> 13:45
> 
> 
> 
> [As partes desta mensagem que não continham texto foram removidas]
>


 


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

Re: [oracle_br] Re: Migração Win/Linux

[Daniel Matthiensen]

Valeu Chiappa !!

Ajudou pacas !!

Complementando a info: as duas máquinas terão a mesma versão de DB 9.2.0.1.0 a 
migração será apenas de SO (windows 2000 server para RH 3.0 AS)


__
Daniel 


- Original Message - 
  From: jlchiappa 
  To: oracle_br@yahoogrupos.com.br 
  Sent: Monday, January 29, 2007 12:56 PM
  Subject: [oracle_br] Re: Migração Win/Linux


  Daniel, isso depende FUNDAMENTALMENTE da informação mais crucial, que 
  só pra variar vc não dá : a VERSÃO DO BD ORACLE envolvida, e SE o 
  banco origem e o destino deverão ter EXATAMENTE a mesma versão de 
  banco (ie, se é só migração de SO ou se é de banco também)
  Supondo que não for migração de banco, a recomendação seria vc criar 
  um banco compatível na máquina destino e depois : SE for banco 10g, 
  uma opção MUITO BOA seria vc TRANSPORTAR as tablespaces do Windows 
  para o Linux, o banco 10g já consegue fazer essa conversão ... Isso é 
  extremamente interessante quando se vê que vc diz que tem 130 Gb, 
  isso possibilita vc EVITAR ter que transmitir arquivos pela rede - 
  hoje em dia NEM DE LONGE isso é uma quntidade exorbitante, 
  tranquilamente há HDs hoje em dia de 120 Gb ou pouco mais, vc poderia 
  ter um HD externo desse tamanho e copiar os datafiles pra ele e 
  atachá-lo na máquina destino, operação que é medida em muito poucas 
  horas, mesmo
  Já se NÃO for 10g, em havendo uma rede DECENTE entre as duas 
  máquinas, com banda razoável, o melhor seria uma combinação de exp + 
  imp + dblinks : a idéia é as poucas tabelas muito grandes vc as pré-
  criar na máquina destino e depois fazer INSERT /*+ APPEND */ into 
  tabelagrande (select * from [EMAIL PROTECTED]); , 
  e o resto vc exporta e depois importa. Notar que vc VAI usar o exp da 
  maneira INTELIGENTE, ie : 
  -> NÃO usará o exp full (que trabalha serialmente), e sim terá 
  DIVERSAS sessões de exp em paralelo, cada uma exportando uma parte
  -> NÃO exportará NEM índices NEM constraints NEM estatísticas, 
  pois tudo isso pode ser rebuilded no bd destino, em modo nologging e 
  paralelo , e no caso das constraints vc as aplicará SEM revalidar
  -> usará as claúsulas adequadas pra performance, como DIRECT, 
  BUFFER, RECORDLENGTH

  []s

  Chiappa

  --- Em oracle_br@yahoogrupos.com.br, "Daniel Matthiensen" 
  <[EMAIL PROTECTED]> escreveu
  >
  > Qual a melhor forma/mais rápida para migrar um BD com 130 Gb de 
  Windows para Linux ?? 
  > Exp / Imp ??
  > 
  > 
  > Obrigado
  > 
  > __
  > Daniel
  > 
  > 
  > [As partes desta mensagem que não continham texto foram removidas]
  >



   

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

RE: [oracle_br] Re: Migração Win/Linux

[Alexandre Rocha Placido]

  

  

Estarei ausente da Agrovale entre os dias 

22 de Janeiro e 9 de Fevereiro 

por motivo de férias. 

  

  

Na minha ausência respondem pelo setor os srs. Adriano
Câmara([EMAIL PROTECTED]) e o sr. Ubirajara
Nogueira([EMAIL PROTECTED]).

  

Alexandre Rocha Placido 

Divisão de Tecnologia da Informação - Agrovale 

Fone:   +55 74 3612-2900 

+55 87 8802-0474 

MSN[EMAIL PROTECTED] 

  

“Eis a voz do que clama: Preparai no deserto o caminho do Senhor; endireitai
no ermo uma estrada para o nosso Deus. Todo vale será levantado, e será
abatido todo monte e todo outeiro; e o terreno acidentado será nivelado, e o
que é escabroso, aplanado. A glória do Senhor se revelará; e toda a carne
juntamente a verá; pois a boca do Senhor o disse.” Isaías 40:3-5



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

Re: [oracle_br] Re: migração entre difere ntes plataforma

[Allyson - Listas]

Maurício,

Teria que ser de 10g pra 10g. 

O que vc pode avaliar é a migração do 8 pro 10g, contudo vc teria que 
verificar também a compatibilidade das suas ferramentas de visualização, 
etl, etc.. com o 10g.

Vale ressaltar que para converter os datafiles entre plataformas 
possivelmente vc terá que converter o formato dos arquivos, isto é feito 
com o RMAN e exigiria espaço em disco adicional, após a conversão teria 
que transporta-los como transportable tablespaces.

Uma opção que na minha opinião seria melhor para sincronizar estes 
bancos seria vc usar o expdp com o parametro NETWORK_LINK que ele faz a 
carga dos dados de um banco pro outro via db_link, daí vc sobe um 
listener numa interface giga (pode até ser crossover mesmo) exclusiva 
pra essa ação, daí vai ser bala :)  Além de não terem tantos passos manuais.

[]'s

-- 
Allyson A. Brito
MSN: [EMAIL PROTECTED]
SKYPE: allysonbrito
RHCE / LPI-1 / SCSA
OCP DBA 9i / OCA PL/SQL 9i




Mauricio Françoso wrote:

>Se eu usar o 10g eu teria como transferir datafiles do 8 para 8 10g ou tem que 
>ser de 10g para 10g?
>
>jlchiappa <[EMAIL PROTECTED]> escreveu:  De 8 pra 8i, absolutamente não tem - 
>na 10g vc até poderia transferir 
>datafiles de SOs diferentes, mas nas versões anteriores não. Assim 
>sendo, vc necessariamente TERIA que fazer algum tipo de transferência 
>de dados : o export é ruim nesse caso porque vc perde tempo gerando 
>um arquivo .dmp, e depois mais tempo lendo-o, num banco dw grande, se 
>vc quer a máxima eficiência nessa transferência o negócio seria vc 
>ter uma comunicação entre as duas máquina (montando uma redezinha 
>privada só entre as duas, com NICs Gigabit se possível (afaik tanto 
>hardwares IBM quanto SUN tem essa possibilidade) e um switch que só 
>tenha essas duas entradas, aí vc faz um dblink, cria as tabelas 
>vazias (** SEM ** índices, constraints, nada, SÓ tabelas) e pede 
>INSERT /*+ APPEND */ INTO tabeladestino (select * from 
>[EMAIL PROTECTED]) - depois vc cria os índices no PARALLEL e 
>NOLOGGING, cria as constraints com ENABLE NOVALIDATE, cria triggers, 
>etc, é isso.   EM não sendo possível, a segunda opção seria vc ainda 
>ter as tabelas criadas vazias e sem nada no bd destino, gerar um 
>arquivo-texto com os dados e carregar via sqlloader esse arq nas 
>tabelas do bd destino.
>
>Ambas as opções são bem eficientes, com técnicas do tipo já cheguei 
>a transferir dados da ordem de centenas de milhões de linhas, MAS 
>ambas não não instantâneas, vão levar algumas tantas horas, E 
>normalmente requerem que o banco origem esteja indisponível aos 
>usuários.
>
>
>[]s
>
>  Chiappa
>  
>--- Em oracle_br@yahoogrupos.com.br, "mfrancoso" <[EMAIL PROTECTED]> 
>escreveu
>  
>
>>Bom dia,
>>
>>Gostaria de saber se tem como e se alguem já executou.
>>Tenho oracle 8 interprise intalado em uma maquina aix versão 4.3.3
>>Tenho que migrar esse banco para 8i em solaris 8.
>>Eu tenho como executar esse processo sem fazer export e import.
>>Trata-se de um datawarehouse e acho que seria impossivel fazer 
>>
>>
>export e 
>  
>
>>import.
>>Se alguem tiver uma dica ou algum manual de como fazer eu agradeço.
>>
>>obrigado.
>>
>>
>>
>
>
>
>
>
>
>
>--
>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/ 
>--__
>Moderador e Fundador: Dorian Anderson Soutto [EMAIL PROTECTED]
>__ 
>
>
>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]
>
>   O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do 
> Yahoo!. 
>
>
>
>
>Mauricio do C. Françoso 
>Liberty Paulista Seguros 
>Administrador Banco de Dados(DBA ORACLE)
>
>   
>-
> Yahoo! doce lar. Faça do Yahoo! sua homepage.
>
>[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/ 
>--__
>Mod

Re: [oracle_br] Re: migração entre diferen tes plataforma

[Mauricio Françoso]

Se eu usar o 10g eu teria como transferir datafiles do 8 para 8 10g ou tem que 
ser de 10g para 10g?

jlchiappa <[EMAIL PROTECTED]> escreveu:  De 8 pra 8i, absolutamente não tem - 
na 10g vc até poderia transferir 
datafiles de SOs diferentes, mas nas versões anteriores não. Assim 
sendo, vc necessariamente TERIA que fazer algum tipo de transferência 
de dados : o export é ruim nesse caso porque vc perde tempo gerando 
um arquivo .dmp, e depois mais tempo lendo-o, num banco dw grande, se 
vc quer a máxima eficiência nessa transferência o negócio seria vc 
ter uma comunicação entre as duas máquina (montando uma redezinha 
privada só entre as duas, com NICs Gigabit se possível (afaik tanto 
hardwares IBM quanto SUN tem essa possibilidade) e um switch que só 
tenha essas duas entradas, aí vc faz um dblink, cria as tabelas 
vazias (** SEM ** índices, constraints, nada, SÓ tabelas) e pede 
INSERT /*+ APPEND */ INTO tabeladestino (select * from 
[EMAIL PROTECTED]) - depois vc cria os índices no PARALLEL e 
NOLOGGING, cria as constraints com ENABLE NOVALIDATE, cria triggers, 
etc, é isso.   EM não sendo possível, a segunda opção seria vc ainda 
ter as tabelas criadas vazias e sem nada no bd destino, gerar um 
arquivo-texto com os dados e carregar via sqlloader esse arq nas 
tabelas do bd destino.

Ambas as opções são bem eficientes, com técnicas do tipo já cheguei 
a transferir dados da ordem de centenas de milhões de linhas, MAS 
ambas não não instantâneas, vão levar algumas tantas horas, E 
normalmente requerem que o banco origem esteja indisponível aos 
usuários.


[]s

  Chiappa
  
--- Em oracle_br@yahoogrupos.com.br, "mfrancoso" <[EMAIL PROTECTED]> 
escreveu
>
> Bom dia,
> 
> Gostaria de saber se tem como e se alguem já executou.
> Tenho oracle 8 interprise intalado em uma maquina aix versão 4.3.3
> Tenho que migrar esse banco para 8i em solaris 8.
> Eu tenho como executar esse processo sem fazer export e import.
> Trata-se de um datawarehouse e acho que seria impossivel fazer 
export e 
> import.
> Se alguem tiver uma dica ou algum manual de como fazer eu agradeço.
> 
> obrigado.
>







--
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/ 
--__
Moderador e Fundador: Dorian Anderson Soutto [EMAIL PROTECTED]
__ 


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]

   O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do 
Yahoo!. 




Mauricio do C. Françoso 
Liberty Paulista Seguros 
Administrador Banco de Dados(DBA ORACLE)


-
 Yahoo! doce lar. Faça do Yahoo! sua homepage.

[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/ 
--__
Moderador e Fundador: Dorian Anderson Soutto [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: [oracle_br] Re: Migração de Informix para Oracle 10g.

[Felipe Renz]

Chiappa,

Muito obrigado pelas dicas vou testar o software e a questão da migrações
que tera que ser ná mão grande, mais um detalhe eu não estava esperando
nenhuma passo-a-passo, mas sim um norte para poder se guiar e executar a
tarefa, agradeço muito sua ajuda era esse norte que eu eperava.

Felipe Renz


Em 23/01/06, jlchiappa <[EMAIL PROTECTED]> escreveu:
>
> Sugestão : em http://www.oracle.com/technology/software/index.html
> baixe o software Oracle Migration Workbench (ele vai pedir pra vc se
> registrar no site, mas esse registro é grátis), e depois que vc
> responda a uma pesquisa. Isto feito, baixe esse software, estude a
> documentação dele, teste-o bem, e depois use-o pra fazer a migração.
> NOTAR que ele absolutamente ** não ** vai fazer todo o trabalho por
> vc (software ** NENHUM ** faz isso), mas é um adianto. Feito esse
> adinto, porém, vai ter uma sobra BEM GRANDE a converter, aí sim vc
> VAI precisar de alguém com bom conhecimento do banco Oracle ** e **
> de alguém com bom conhecimento no banco Informix, pra REPROGRAMAR
> procedures/triggers, re-criar tabelas/índices, etc,  que não puderam
> ser convertidos automaticamente. PODE ser a mesma pessoa, ou podem
> ser pessoas diferentes, mas TEM QUE haver o conhecimento, se não
> houver pode-se aplicar treinamentos e/ou optar por consultores
> externos... E é aquele negócio, se vc quer uma receita passo-a-passo,
> mastigada, que qquer um possa seguir, mesmo sem os conhecimentos
> necessários, também creio que não seja possível.
>
> []s
>
> Chiappa
>
> --- Em oracle_br@yahoogrupos.com.br, "felipejrenz" <[EMAIL PROTECTED]>
> escreveu
> >
> > Pessoal,
> >
> >
> >
> > Alguem sabe o caminho das pedras não tenho nem ideia por onde
> > começar a migração.
> >
> > Help
> >
> >
> >
> > --- Em oracle_br@yahoogrupos.com.br, Consulting 2001 Br
> > <[EMAIL PROTECTED]> escreveu
> > >
> > > O maior problema será a migração das triggers e
> > > procedures
> > >
> > > --- felipejrenz <[EMAIL PROTECTED]> wrote:
> > >
> > > > Bom dia.
> > > >
> > > > Recebi uma miss�o complicada, preciso migrar um
> > > > banco Informix para
> > > > Oracle, e agora como devo proceder, tenho criar as
> > > > mesmas estruturas do
> > > > informix no oracle ou existe alguma ferramente para
> > > > importa��o destas
> > > > estruturas, indexes, ...etc...
> > > >
> > > > Fico no agurado, e desde j� agrade�o a ajuda de
> > > > todos
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > __
> > > Do You Yahoo!?
> > > Tired of spam?  Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > >
> >
>
>
>
>
>
>
>
> --
> Atenção! As mensagens deste grupo são de acesso público e de inteira
> responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
>
> --__
> Moderador e Fundador: Dorian Anderson Soutto [EMAIL PROTECTED]
> __
>
>
>   *Yahoo! Grupos, um serviço oferecido por:*   PUBLICIDADE
>   Ad Blocked
> 
> --
> *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! .
>
>


--
Atenciosamente,

Felipe Renz
Cel.: 51 9809 4089


[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/ 
--__
Moderador e Fundador: Dorian Anderson Soutto [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