Pois é, Ederson : como eu citei na minha resposta, Se Fosse migração entre plataformas diferentes mas com o mesmo endian-type/same endianness, aonde a Ordem De gravação dos bytes em memória ou disco é a mesma, aí realmente usaríamos o CONVERT, que em si é bem rápido, já que há muito pouco a fazer nos datafiles em sim, que são os maiores componentes num banco de dados Oracle normalmente - no máximo provavelmente vai haver alguns poucos ajustes no cabeçalho do datafile, coisinhas do tipo.... Os blocos de dados dos usuários já estariam gravados numa sequência legível para a plataforma-destino, não sendo passíveis de alteração alguma... No caso do colega, porém, ele QUER/PRECISA migrar para uma nova plataforma com uma ordem de gravação de bytes DIFERENTE da original, então essa opção de CONVERTER uma cópia de datafiles simplesmente via RMAN tá fora.... Daniel, antes de responder a sua dúvida, só confirmando : vc Entendeu que para vc fazer transport de tablespaces vc ** TEM ** que colocar a tablespace a trasportar em read-only (que Implica em indisponibilidade para gravação/alteração/inclusão de dados enquanto isso), ** E ** que além disso os objetos TEM que ser auto-contidos na tablespace em transporte (ie, eventuais segmentos logicamente necessários para cada objeto, como LOB Segments, por exemplo) Precisam estar gravados nessa mesma tablespace em transporte, okdoc ?? Senão vc NÃo Vai poder fazer o transporte, yep ?? Isso tudo está Explícito na nota metalink recomendada (a "Migration Of An Oracle Database Across OS Platforms (Generic Platform)" [ID 733205.1]) e nos links dela.... ASSIM SENDO, torna-se a frisar : SE vc tiver alguma chance de estabelecer, temporariamente que seja, só para a migração, uma rede de alta-performance e dedicada entre os dois servers, a opção de DATAGUARD ou similares com envio de dados pela rede ** É ** a preferida, por não ter exigências físicas sobre as tablespaces e poder ser feita totalmente online, sem indisponibilidade.... Muito bem, isso posto a sua resposta : primeiro, veja que "criação de instância" é algo meio impreciso, pois INSTÂNCIA não é algo físico, que vc cria e que fica armazenado em disco - conceitualmente, uma INSTÂNCIA é o resultado dos binários Oracle sendo carregados para a memória e lendo os arquivos/pré-requisitos, como os initfiles, variáveis de ambiente, etc, yep ??? Fosse Windows o SO vc ainda precisaria criar algo a mais que seria o SERVIÇO WINDOWS que serve de "muleta", mas sendo (como é) unix-like o seu ambiente, cabou : tenha os BINÁRIOS instalados no servidor-destino com o MESMO EXATO release e os MESMO patches que no server origem E use os mesmos valores de init e variáveis/etc no server destino que vc VAI ser capaz de startar uma instância IDÊNTICA , sim sim ??? Para se provar isso, na tua máquina unix-like que possua binários Oracle crie um initfile, set as variáveis de ORACLE_HOME, ORACLE_SID e PATH e manda um startup nomount que vc vai ver que a instãncia VAI ser inicializada pelos binários SEM que vc tenha que "criar" nada via assistente ou seja o que for , sim ??? É Claro, porém, que a instância sozinha não serve de muito, vc TEM que ter um database para a instância abrir, aqui DATABASE sendo definido como o conjunto de datafiles+controlfiles+demaisarqsnecessários, né ?? Que fique claro, com transport de tablespaces vc vai estar adicionando tablespaces de usuário em um database QUE JÁ EXISTE, vc **** NÃO ***** vai clonar/copiar/trazer o database do server origem.... Assim, para que vc crie no server destino um database o mais idêntico possível ao que eiste no server origem, o procedimento seria :
1. instale no servidor destino os binários do RDBMS Oracle com o mesmo exato release (11.2.0.2, iirc da sua mensagem) existente no servidor origem 2. aplique nesses binários do server destino os MESMOS TODOS patches que estão aplicados na origem 3. use no server destino o assistente de criação de banco de dados (que já cria os pré-reqs para vc poder subir uma instância) para criar um database com o MESMO NOME e com as MESMAS exatas propriedades (tal como characterset, linguagem, ordenação, MESMAS features que foram usadas na origem, etc, etc), e os mesmos parãmetros de inicialização sempre aonde possível (podem haver alterações por hardwares diferentes entre origem e destino, ou devido à requisitos do SO), não esquecendo de quando o Assistente perguntar a identificação de instância vc informa o mesmo ID usado na origem 4. suba essa instância cujos pre-reqs o Assistente já te criou e com ela abra o database 5. transporte uma a uma as tablespaces não-internas/de usuários que vc quer trazer do banco-origem : é basicamente confirmar via DBMS própria que a tablespace é transportável no banco-origem, colocar no banco-origem a tablespace em read-only, copiar os datafiles da tablespace a partir da origem para o destino (via FTP, copy, RMAN, o que quiser/tiver), copiar os metadados (a informação de controle, interna) sobre a tablespace a partir da origem para o destino (normalmente via exportação), trazer os metadados para o banco-destino (via importação, normalmente) , e é isso... legal ?? Dá uma BOA estudada na nota metalink que indiquei, nos links dela E na documentação que vc acha refs completas e passo-a-passo... qquer dúvida manda uma msg que a gente pode tentar te ajudar mais..... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Daniel Mello <djnmello@...> escreveu > > 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 <jlchiappa@...> > 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-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] > > > > > > > ------------------------------------ > > -------------------------------------------------------------------------------------------------------------------------- > >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] >
