Bom, antes de mais nada o cliente tá Sabendo que esses dataguards ** vão ter 
que ser refeitos ** em servidores Linux pra alinhar com esse novo Linux prod, 
né ? de acordo com a nota "Data Guard Support for Heterogeneous Primary and 
Physical Standbys in Same Data Guard Configuration" (Doc ID 413484.1) mesmo 
sendo rigorosamente a mesma versão de software RDBMS (é o mínimo que se pede 
numa Migração) não é suportado DG físico entre AIX e Linux.... Isso também ** 
ELIMINA ** a Possibilidade de ter o Linux como uma réplica a mais, remover o 
AIX e depois promover o Linux para Primary....

 Muito bem : a sua resposta só pode ser DEPENDE, pois :
 
 ==> certamente o database deve residor num STORAGE : é tecnicamente possível 
vc fazer o novo servidor Linux reconhecer/acessar esse storage ? Se sim, talvez 
vc poderia simplesmente baixar a instância e fechar o banco no AIX, e uma vez 
que o Linux tiver uma instãncia e conseguir acessar os datafiles, vc 
simplesmente os CONVERTE para o formato Linux, provavelmente via RMAN com 
comando CONVERT - isso seria Excelente pois vc pouparia o tempo de enviar pela 
rede os dados e/ou os datafiles pro novo servidor Linux, potencialmente 
cortando MUITO tempo do cronograma.... Outra opção nesse sentido caso o novo 
servidor vá usar outras LUNs no mesmo stirage seria vc copiar/transferir os 
datafiles via utilitários do storage, depois fazendo a Conversão necessária... 
 
 ==> vc diz que a base é de 2.4 Tb : tá bem, mas a maior parte desse volume 
está em relativamente poucas tabelas ? Há link de rede RÁPIDO entre os dois 
servidores ? Ambos os servidores possuem múltiplas CPUs e ampla capacidade  de 
I/O ? 
  Se a resposta for SIM para todas as questões, vc poderia ter algumas tantas 
sessões fazendo INSERT /*+ APPEND */ into tabela@databaselink com o maior grau 
de paralelismo possível, o resto vc exporta/importa os dados (apenas dados!!) e 
extrai os DDLs para recriar índices em paralelo e constraints em NOVALIDATE...
  
 ==> se o volume não tiver a distribuição acima mas o link de rede rápido e 
confiável existir, outra opção (para minimizar o tempo de downtime mas 
provavelmente Aumentar o tempo total do procedimento) seria replicar os dados 
da origem pra um banco-destino que vc criaria - se vc tiver a Licença isso pode 
ser feito via Goldengate, se não vc poderia (SE as restrições de datatype e 
quetais não interferirem) usar Streams
 
 ==> as opções anteriores não sendo viáveis, aí caímos nos procedimentos de 
migração mesmo, ie, vc vai transferir (alguns ou todos) datafiles da origem pro 
destino e lá os converter para o formato Linux ....  SE fossem SOs com o mesmo 
endian order vc teria a opção de usar os comandos de CONVERT DATABASE do RMAN, 
ou mesmo simplesmete RESTAURAR um backup da origem e o converter no destino -  
vide nota metalink "RMAN DUPLICATE/RESTORE/RECOVER Mixed Platform Support" (Doc 
ID 1079563.1) e os manuais Oracle (especialmente o manual "Database Backup and 
Recovery User's Guide" no cap. 25 Transporting Data Across Platforms) mas como 
AIX e Linux tem endian order diferentes, nada feito, só sobra o TRANSPORTABLE 
TABLESPACE...
  
  Veja a nota metalink "11G - Reduce Transportable Tablespace Downtime using 
Cross Platform Incremental Backup" (Doc ID 1389592.1) para refs e algumas 
melhorias havidas (como os backups incrementais para transporte), e 
http://www.dside-software.com/tech-news/cross-platform-oracle-migration-with-rman-convert-and-transportable-tablespaces/
 tem um exemplinho...
  
  []s

  Chiappa
  
    OBS : 
    
    1. iirc a restrição de conversão/restore de database cross platform mudou 
no 12c mas no 11G que vc tem e (ao que entendo) vai continuar a usar ainda é 
tal como eu falei acima
    
    2. há outras opções de standby (como por exemplo o Shareplex) que vc pode 
investigar - não sei como está hoje em dia o Suporte delas pra standby 
cross-platform mas veja lá...
  • [or... Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]
    • ... Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]
      • ... jlchia...@yahoo.com.br [oracle_br]
      • ... Sérgio Luiz Rodrigues Chaves sergio.cha...@elumini.com.br [oracle_br]
    • ... Fabricio Pedroso Jorge fpjb...@gmail.com [oracle_br]
    • ... Rafael Mendonca raffaell.t...@yahoo.com [oracle_br]

Responder a