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-10000rpm-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 <rodrigo@...> 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 <djnmello@...> 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] >