Oracle Data Guard 12c – Transporte de Base de dados “Cross Platform” (Parte I)

Por Joel Perez , Mahir M. Quluzade (OCP) & Rodrigo Mufalani
Postado em janeiro 2014

Indice:

1. Oracle Data Guard 12c – Transporte de Base de dados “Cross Platform” (Parte I)
2. Oracle Data Guard 12c – Transporte de Base de dados “Cross Platform” (Parte II)

O Oracle “Database12c” é a nova versão do gerenciador de base de dados da “Oracle Corporation”, e nós DBA’s e Desenvolvedores que usamos a tecnologia Oracle nos perguntamos “O que mais, a Oracle poderia adicionar como novas funcionalidades?” Como sempre a Oracle nos surpreende mais uma vez, as novas características e a nova arquitetura não só surpreendem como também nos levam a uma outra era…., “Cloud Computing”…

Pessoalmente tive a oportunidade de trabalhar com tecnologia Oracle como DBA desde a versão 8. O 8i da era da internet, o “9i” da era da internet com mais elementos, me lembro que um dos maiores componentes de maior importância foi a apresentação do Real Application Clusters 9i, “nascia a era RAC…”, “10g” que nos surpreendeu com o conceito de ASM… e a filosofia “Grid Computing”, 11g & 11gR2 sobretudo com suas melhoras de alto nível relacionadas a RAC & Dataguard…, 12c… Cloud Computing, novas funcionalidades… Mais de 500 as quais iremos cobrindo gradualmente através de artigos e outros elementos de ajuda.

O transporte de dados através de diversas plataformas (“Sistemas Operacionais”) sempre envolveu em conjunto o conhecimento de técnicas e uma arena de desafios para alcançar os objetivos. “Oracle Database 12c” tras consigo uma série de possibilidades altamente escaláveis e flexíveis nesta área. Pessoalmente considero que estas melhoras na área de transporte “Cross-Platform” são uma das grandes conquistas dessa versão em conjunto com outras novas funcionalidades.

Entramos na matéria… Antes da versão “Oracle Database 12c R1” as tarefas de Migração, Upgrade, Replicação e outras atividades entre bases de dados pertencentes a Sistemas Operacionais distintos eram um desafio. As alternativas, procedimentos e estratégias para lidar com “Cross-Platform” são realmente diversas e poderíamos considerar um “subset” de uma área de especialização para todos aqueles que são DBA.

Uma tarefa que mais utilizo em nível internacional para realizar “Upgrades” de bases de dados é o estabelecimento de infraestrutura de alta disponibilidade. O principal desafio em “Upgrades” é obter o menor tempo possível de “Downtime” em conjunto com outras variáveis. O tempo de “Downtime” dependerá de diversos fatores, um dos mais sérios é aquele que contem implicações por estar em plataformas diferentes. No presente artigo nos referimos a plataforma como equivalente a Sistemas Operacionais.

“Endian Format”: O endian format é a peça chave para se entender tudo relacionado com operações “Multi-Plataformas”. O endian format é a ordem em que estão ordenados os “Bytes” internamente nos arquivos binários pertencentes a um determinado Sistema Operacional. No “endian format” temos apenas 2 tipos: “Little” & “Big”, em um os bytes estão ordenados do menor para o maior e vice-versa.

Nota: Neste artigo se utilizarão os temos “Cross-Platform” & “Multi-Plataforma” como sinônimos.

Em versões anteriores a “Oracle Database 12cR1” a maioria das operações “Multi-Plataformas” eram favorecidas se os “endian format” fossem iguais. Ex.:

• Possibilidade de converter uma base de dados completa para um outro sistema operacional que tivesse o mesmo “endian format” através do comando “CONVERT DATABASE” do RMAN.
• Possibilidade de configurar um “Oracle Data Guard” entre bases de dados com sistema operacionais de “endian format” iguais. De uma forma específica para versões anteriores, esta operação só poderia ser realizada entre sistemas operacionais “Linux & Windows”, não sendo capaz de ser realizada entre em outros sistemas operacionais mesmo com os endian format iguais.

Se os “endian format” não eram iguais, as operações se tornavam um tanto complexas. Ex.:

• Ao ter a impossibilidade de aplicar o “CONVERT DATABASE” tínhamos que recorrer a técnicas como “TRANSPORTABLE TABLESPACE” ou “CONVERT DATAFILE”, “Export/Import” e outras
• Para muito cenários a possibilidade se direcionava ao uso de “Oracle Streams” ou “Oracle Golden Gate” tais quais também possuem implicações particulares relacionadas com as arquiteturas dessas soluções.

E assim sucessivamente...

“Cross Platform Transportable Tablespace”: é uma variação originária do “Transportable Tablespace” anterior ao “Oracle Database 12c”, todas as restrições que aplicam para o modelo de transporte de “Tablespaces” anterior se aplicam ao atual. “Transportable Tablespace” pode ser efetuado entre base de dados que tenham “endian format” iguais ou entre versões do gerenciador.

“Cross Platform Transportable Database”: é adequado esclarecer que “Transportable Database” não é a mesma técnica que “Transportable Tablespace”. Neste caso se copia toda a base de dados incluindo “Tablespaces” de sistema como “System”, “Sysaux” e outros. O conceito de “Cross Platform Transportable Database” está baseado principalmente na nova funcionalidade denominada “Full Transportable Export/Import”.

“Full Transportable Export/Import” é uma nova característica do “Oracle Database 12c” que facilita o movimento de uma base de dados completa utilizando a funcionalidade de “Transportable Tablespace”. Este componente automatiza o processo de cópia de “Metadados” e é capaz de mover os dados que residem nos “Tablespaces” não transportáveis como “SYSTEM” e “SYSAUX”. Além de ser capaz de transportar tablespace encriptados.

Realizar “Upgrades” entre plataformas heterogéneas sempre foi um desafio para empresas e DBAs incorrendo em muitas oportunidades de escolha de soluções e estratégias para superar as dificuldades. Em muitos casos o investimento econômico é tão alto em consideração a estes cenários, que pode levar a troca da plataforma de destino de forma radical entre outras decisões. Ex.: Ocorre com bastante frequência que nas empresas os gerentes e/ou diretores de TI tomam decisões de compra de hardware para realização de “Upgrades” de base de dados e também de hardware sem conhecer a fundo as possíveis implicações de uma decisão por uma plataforma ou outra. Em versões anteriores ao “Oracle Database 12c”, escolher uma plataforma nova para “Upgrade” com um “Endian Format“ diferente do da plataforma original implicava em um grande desafio posterior para os “DBAs” e em muitas ocasiões implicações econômicas posteriores para finalizar a tarefa. Em todo este tempo como “DBA” sempre temos enfrentado em inúmeras ocasiões e tem sido muito frequente viajar até outros países somente para explicar implicações econômicas que terão ao optar por um “Upgrade” em uma plataforma heterogénea, mas especificamente quando os “Endian Formats” são diferentes.

Felizmente para as empresa essa nova funcionalidade “Cross-Plattorm” de “Full Transportable Export/Import” poderá solucionar este tipo de casos complexos de “Upgrade” entre plataformas de “Endian Format” diferentes. O único pré-requisito é que a base de dados estejam na versão 11.2.0.3 em diante. Ex.: Se uma empresa possui um BD na versão 10.2.0.5 e queira realizar um upgrade para uma plataforma diferente em 11.2.0.3, porque não somente deseja atualizar a versão, mas também trocar de hardware também possuía a dificuldade que tivemos conversando. Uma solução excelente seria aplicar o upgrade rápido e momentâneo no hardware original de 10.2.0.5 para 11.2.0.3 e desta versão fazer o upgrade direto para o “Oracle Database 12c” no hardware de destino com a plataforma e o “Endian Format”, mesmo diferente, que a empresa desejar. Esta indubitavelmente poderia ser uma de tantas justificadas razões pela qual uma empresa poderia programar seu “Upgrade” para o “Oracle Database 12c”. Nesta série de artigos teremos exemplos altamente interessantes dessa nova funcionalidade.

Continuando com o tema, porém, focado em outras técnicas para converter os BDs citamos o seguinte:  Mesmo o “Oracle Database 12c” é um requisito indispensável para ambas as plataformas que tenham o mesmo “endian format” para concretizar o “CONVERT DATABASE”. No entanto os comandos “BACKUP” & “RESTORE” trouxeram novas funcionalidades para driblar essas restrições do “CONVERT DATABASE”.

Antes de seguir conversando sobre as novas funcionalidades de “BACKUP” & “RESTORE” 12c então nos perguntamos: “Qual a diferença ente uma e outra...? Quando é adequado utilizar cada comando...? Então vejamos o seguinte:

• “BACKUP” & “RESTORE” “12c”: que inclui comandos “BACKUP FOR”, “BACKUP TO”, “RESTORE FROM” é utilizado entre bases de dados “12c” não importando qual o “endian format”, todas as conversões possíveis podem ser realizadas independente do “endian format” da origem e do destino. Quando a origem for 11gR2 o comando “RESTORE FROM” só pode ser utilizado quando o “Backup” foi originado em uma plataforma com o mesmo “endian format” que o da plataforma de destino.
•  “CONVERT DATABASE”: no “12c” possui as mesmas regras de uso que as versões anteriores. Para realizar um “CONVERT DATABASE” ambas plataformas devem possuir o mesmo “endian format”
• “Full Transportable Export/Import” tal como foi explicado anteriormente é uma opção ideal para realizar “Upgrades” Multi-Plataforma sem restrições desde a versão 11gR2 (11.2.0.3) em diante. Se as bases de dados fossem ambas “12c”, a opção perfeita seria: “BACKUP FOR”, “RESTORE TO”, “RESTORE FROM”

Entender a diferença entre estas 3 técnicas é fundamental para entender como o marco “Cross-Platform” do Oracle Database 12c funciona.

Seguimos conversando de “BACKUP” & “RESTORE”. As novas funcionalidades dos comandos “BACKUP” & “RESTORE” permitem converter uma base de dados da plataforma de origem para o destino. Listamos algumas razões vantajosas em realizar a conversão no “host” de destino.

• Evitamos um “Overhead” de recursos na plataforma de origem por causa do processo de conversão. Isto se realiza quando está sendo gerado o “Backup” na plataforma de origem.
• Distribuição de uma base de dados de uma plataforma para múltiplas outras.
• Migração/Transporte de Tablespaces através de plataformas distintas com um mínimo de Downtime das aplicações.

“Métodos de Transporte de Dados através de Plataformas”

• Transporte de Dados utilizando “Image Copies”: RMAN permite o uso de “Image Copies” para transportar “Tablespaces”, “Datafiles” ou uma base de dados completa. “Transport Tablespace” é usualmente realizado transportando os “Datafiles” pertencentes a um determinado “Tablespace”, é importante ressaltar que não é possível o transporte de um “Datafile” de forma individual pertencente a um “Tablespace” que possua mais do que um “Datafile”. Em versões anteriores, para transportar “tablespaces” entre plataformas de diferentes “endian format” tínhamos que realizar conversões dos “datafiles” obtendo-se uma “Image copy”, no “Oracle Database 12c” não é necessário, a operação de conversão estará incluída nas operações “BACKUP.. FOR” ou “BACKUP TO” e as restaurações complementam a conversão com “RESTORE FROM”. Para versões anteriores e atuais se deseja transportar uma base de dados entre sistemas que possuam o mesmo “endian format” que pertençam a sistemas operacionais distintos, a técnica se baseia em copiar todos os “datafiles” de dados e converter aqueles que possuam “Undo Segments” ou que contenham “Segment Space Management ( ASSM ) segment headers” que seriam transportados para ou a partir da plataforma “HP Tru64”. Realmente com as novas funcionalidades de “Restore/Recover” entre bases de dados “12c” não haveria necessidade alguma de utilizar “CONVERT DATABASE”. Existem alguns poucos cenários nos quais poderia utilizar ainda:
  •  “Upgrade” de versões anteriores a “Oracle Database 12c” entre plataformas de “endian formats” iguais
  • E em linhas gerais serão muito poucos cenários onde as novas funcionalidades “Multi-Plataforma” de “BACKUP/RESTORE” possam ser menos eficientes que o uso do tradicional “CONVERT DATABASE”
  • Entre bases de dados “12c” seriam poucos os cenários onde fosse melhor utilizar “CONVERT DATABASE” no lugar de utilizar as novas funcionalidades de “BACKUP/RESTORE” “12c” em conjunto com técnicas de “Manual Rolling Upgrade”
• Transporte de Dados utilizando “Backupsets”: RMAN pode transportar bases de dados, “Datafiles” & “Tablespaces” para diversas plataformas utilizando “Backup sets”. Quando se transporta “Dados” através de “Backupsets” se pode ter acesso as seguintes vantagens:
  • Podemos habilitar o “Block Compression” para diminuir o tamanho dos backups. Facilitando assim sua transferência através da rede.
  • Maior controle do uso de paralelismo para executar as tarefas de “BACKUP/RESTORE” em um menor tempo
  • E em geral se aproveitam todas as vantagens inerentes a geração de um “Backup sets”

Notas de uso para transporte “Cross-Platform”

“Cross-Platform Backup” (Conceito): é um “Backup” criado de uma base de dados origem e que pode ser restaurado em uma base de dados destino que pertença a uma plataforma diferente do BD original. Estes são usados para transporte de dados entre plataformas diferentes.

• Para realizar transportes de dados “Cross-Platform” utilizando “Backup sets” a versão da base de dados de origem e destino deverá ser “Oracle Database 12c Release 1 (12.1)” ou superior
• No comando “BACKUP” podem-se utilizar as opções:
  • “FOR TRANSPORT”: consiste em um backup com uma estrutura interna “Multi-Plataforma” a qual poderá ser convertida no destino posteriormente ao realizar o “RESTORE”.
  • “TO PLATFORM”: consiste em um backup criado e direcionado para ser restaurado em uma plataforma que se especifica no comando. Este tipo de backup resultará em um backup otimizado no seu processo de “RESTORE” já que o mesmo não terá de realizar conversão alguma.
• Quando se realiza um “BACKUP” de um “Tablespace” pode-se estabelecer de forma opcional a geração do “Export Dump File” para que este “Tablespace” possa ser transportado, o “Export Dump File” conterá os “Metadados” para transportar o “Tablespace”, se fosse este o objetivo pelo qual foi realizado “Backup” do mesmo.
• Transporte de “Tablespaces”: O “Export Dump File” é utilizado no momento de realizar o “RESTORE” que possuirá como objetivo realizar o “plug” do “Tablespace” na base de dados destino.
• É possível transportar “Dados” da versão 10gR1&R2/11gR2 para a versão “12c”. A diferença é que a origem não conta com os comandos “FOR TRANSPORT” ou “TO TRANSPORT”. O “Backup” estaria confirmado por um “Backup” regular e os “Metadados” seriam obtidos com um utilitário “expdp” de forma regular assim como é realizada para as versões 10gR1&R2/11gR2
• RMAN não cataloga “Backup sets” que se realizam para operações “Cross-Platform”. Este assegura que este tipo de “Backup” não sejam utilizados para operações regulares de “Backup e Restore” na base de dados de origem.

Termos básicos utilizados em operações “Cross-Platform”

Antes de utilizar operações “Cross-Platform” é de alta importância familiarizar-se com os seguintes termos:

• FOREIGN DATA FILE: os “Datafiles” que não pertencem a base de dados destino são denominados “FOREIGN DATA FILES”. Estes “Datafiles” serão incorporados a base de dados destino como parte de uma operação de “RESTORE”.
• FOREIGN DATABASE: para restaurar um BD completo se utiliza a cláusula “FOREIGN DATABASE” no comando “RESTORE”. Esta cláusula só pode ser utilizada quando se está restaurando de um “Whole Database Backup”.
• FOREIGN TABLESPACE: “FOREIGN TABLESPACE” representa um conjunto de “foreign datafiles” pertencentes ao mesmo “Tablespace” da base de dados de origem. Os “foreign datafiles” não pertencentes a base de dados destino, porém estarão sendo transportados para a base de dados destino.
• FOREIGN DATA FILE COPY: é um “Datafile” que foi restaurado de um “Cross-Platform Backup”. Não pode ser diretamente conectado a base de dados destino por possuir uma condição de inconsistência, deve-se aplicar um “Cross-Platform Incremental Backup” para este “Datafile” e efetuar o “Recover” antes que o mesmo possa pertencer a base de dados de destino.
• Data Pump Destination: é uma localização de disco de destino no servidor da base de dados destino ao qual servirá para armazenamento dos “Export Dump File(s)” a serem utilizados para transportar “Tablespaces”

Notas de uso para conversões de “Tablespaces” & “Datafiles”

• Pode-se aplicar “CONVERT TABLESPACE” no “Host” de origem mas não no de destino.
• “CONVERT TABLESPACE” gera novos “Datafiles”, não afeta os já existentes na base de dados a qual se está aplicando o procedimento.
• “CONVERT DATAFILES” possui a capacidade de converter “Datafiles” na origem ou no destino, de forma usual o comando “CONVERT DATAFILE” é aplicado no destino.
• A concepção e utilização do ciclo de vida do “CONVERT TABLESPACE” & “CONVERT DATAFILE” no “Oracle Database 12c” é exatamente a mesma comparando com versões anteriores.

“Database Conversion”

Para converter uma base de dados (BDs) completa a uma plataforma diferente, os “endian formats” de ambas BDs devem ser iguais. O BD de origem deve estar em modo “Read-Only” para finalizar o “CONVERT DATABASE”. O procedimento “CONVERT DATABASE” geram os seguintes elementos a serem transferidos transferidos ao servidor de destino:

• Todos os “Datafiles” da base de dados.
• “Initialization Parameter File” (init<SID>.ora ) ou “Server Parameter File” ( spfile<SID>.ora )
• “Script” para recriar os “Controlfiles”

Plataformas  disponíveis para operações “Cross-Platform” no “Oracle Database 12c”

SQL> set linesize 2000
SQL> set pagesize 2000
SQL> select PLATFORM_ID, PLATFORM_NAME, ENDIAN_FORMAT from v$transportable_platform;

PLATFORM_ID PLATFORM_NAME                                   ENDIAN_FORMAT      
----------- ------------------------------------------------------------------
          1 Solaris[tm] OE (32-bit)                             Big                     
          2 Solaris[tm] OE (64-bit)                             Big                     
          7 Microsoft Windows IA (32-bit)                       Little                  
         10 Linux IA (32-bit)                                   Little                  
          6 AIX-Based Systems (64-bit)                          Big                     
          3 HP-UX (64-bit)                                      Big                     
          5 HP Tru64 UNIX                                       Little                  
          4 HP-UX IA (64-bit)                                   Big                     
         11 Linux IA (64-bit)                                   Little                  
         15 HP Open VMS                                         Little                  
          8 Microsoft Windows IA (64-bit)                       Little                  
          9 IBM zSeries Based Linux                             Big                     
         13 Linux x86 64-bit                                    Little                  
         16 Apple Mac OS                                        Big                     
         12 Microsoft Windows x86 64-bit                        Little                  
         17 Solaris Operating System (x86)                      Little                  
         18 IBM Power Based Linux                               Big                     
         19 HP IA Open VMS                                      Little                  
         20 Solaris Operating System (x86-64)                   Little                  
         21 Apple Mac OS (x86-64)                               Little                  

20 rows selected.

SQL>

    

Dando continuação ao exemplo deste artigo:

Identificação do BD de origem e estabelecimento dos dados de aplicação

C:\Users\oracle>set ORACLE_SID=wdb12c
C:\Users\oracle>sqlplus sys as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Jul 22 03:44:13 2013
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
Enter password:
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing opions

SQL> select banner from v$version;

BANNER
-------------------------------------------------------------------------------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
PL/SQL Release 12.1.0.1.0 - Production
CORE    12.1.0.1.0      Production
TNS for 64-bit Windows: Version 12.1.0.1.0 - Production
NLSRTL Version 12.1.0.1.0 – Production

SQL> select cdb, name, log_mode from v$database;

CDB NAME      LOG_MODE
--- --------- ------------
NO  WDB12C    ARCHIVELOG

SQL> select platform_name from v$transportable_platform
  2   where platform_id = (select platform_id from v$database);

PLATFORM_NAME
--------------------------------------------------------------------------------

Microsoft Windows x86 64-bit

SQL> create user mahir identified by mahir;

User created.

SQL> grant create session, resource, dba to mahir;

Grant succeeded.

SQL> connect mahir/mahir
Connected.

SQL> create table t (n number);
Table created.

SQL> insert into t values(1);

1 row created.

SQL> commit;
Commit complete.

SQL> select *  from t;

         N
----------
         1

Backup do BD de origem com o uso de comando “BACKUP FOR TRANSPORT”. No “Oracle Database 12cR1” é que a base de dados origem esteja em modo “Read-Only” para se aplicar o procedimento de Transporte, objeto do presente artigo.

C:\Users\oracle>set ORACLE_IS=wdb12c
C:\Users\oracle>rman target /

Recovery Manager: Release 12.1.0.1.0 - Production on Mon Jul 22 04:02:27 2013
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

connected to target database: WDB12C (DBID=1042362086)

RMAN> shutdown immediate;

using target database control file instead of recovery catalog
database closed
database dismounted
Oracle instance shut down

RMAN> startup mount;

connected to target database (not started)
Oracle instance started
database mounted

Total System Global Area     801701888 bytes

Fixed Size                     2407784 bytes
Variable Size                541065880 bytes
Database Buffers             255852544 bytes
Redo Buffers                   2375680 bytes

RMAN> alter database open read only;

Statement processed

RMAN> BACKUP FOR TRANSPORT
     2> FORMAT 'C:\Backup1\wdb12c_transport1.bck'
     3> DATABASE;

Starting backup at 22-JUL-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=C:\APP\ORACLE\ORADATA\WDB12C\SYSTEM01.DBF
input datafile file number=00003 name=C:\APP\ORACLE\ORADATA\WDB12C\SYSAUX01.DBF
input datafile file number=00005 name=C:\APP\ORACLE\ORADATA\WDB12C\UNDOTBS01.DBF
input datafile file number=00002 name=C:\APP\ORACLE\ORADATA\WDB12C\EXAMPLE01.DBF
input datafile file number=00006 name=C:\APP\ORACLE\ORADATA\WDB12C\USERS01.DBF
channel ORA_DISK_1: starting piece 1 at 22-JUL-13
channel ORA_DISK_1: finished piece 1 at 22-JUL-13
piece handle=C:\BACKUP1\WDB12C_TRANSPORT1.BCK tag=TAG20130722T040445 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:55
Finished backup at 22-JUL-13

    

Para o presente caso construiremos manualmente os “Controlfiles” no BD de destino baseado na informação do BD de origem, para tanto, faremos um “Backup Controlfile to trace” para tal objetivo. Também será gerado um “Parameter File” igual ao de origem como podemos verificar abaixo:

C:\Users\oracle>set ORACLE_IS=wdb12c
C:\Users\oracle>sqlplus/ as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Jul 22 04:07:28 2013
Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> alter database backup controlfile to trace as 'C:\Backup1\controlfile2trace1.sql';

Database altered.

SQL> create pfile='C:\Backup1\pfile4linux1.ora' from spfile;

File created.

    

Transferência dos arquivos necessários, gerados nos passos anteriores:

• “Script” de criação dos “Controlfiles”
• “Parameter File”
• “RMAN Backup”

C:\Users\oracle>cd C:\Backup1
C:\Backup>dir
 Volume in drive C has no label.
 Volume Serial Number is 5CD8-D7F7

 Directory of C:\Backup1

07/22/2013  04:07 AM    <DIR>          .
07/22/2013  04:07 AM    <DIR>          ..
07/22/2013  04:07 AM             6,105 CONTROLFILE2TRACE1.SQL
07/22/2013  04:07 AM             1,042 pfile4linux1.ora
07/22/2013  04:06 AM     1,427,324,928 WDB12C_TRANSPORT1.BCK
               3 File(s)  1,427,332,075 bytes
               2 Dir(s)  80,754,802,688 bytes free


[oracle@oel62-ora12c tmp]$ cd Backup1
[oracle@oel62-ora12c Backup1]$ ls -l
total 1393896
-rw-r--r-- 1 oracle oinstall       6007 Jul 22 14:52 CONTROLFILE2TRACE1.SQL
-rw-r--r-- 1 oracle oinstall       1028 Jul 22 16:30 pfile4linux1.ora
-rw-r--r-- 1 oracle oinstall 1427324928 Jul 22 16:18 WDB12C_TRANSPORT1.BCK

    

Parâmetros ajustados para o “Parameter File” do BD de destino

ldb12c1.__data_transfer_cache_size=0
ldb12c1.__db_cache_size=369098752
ldb12c1.__java_pool_size=4194304
ldb12c1.__large_pool_size=8388608
ldb12c1.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
ldb12c1.__pga_aggregate_target=281018368
ldb12c1.__sga_target=524288000
ldb12c1.__shared_io_pool_size=0
ldb12c1.__shared_pool_size=134217728
ldb12c1.__streams_pool_size=0
*.audit_file_dest='/u01/app/oracle/admin/ldb12c1/adump'
*.audit_trail='db'
*.compatible='12.1.0.0.0'
*.control_files='/u01/app/oracle/oradata/LDB12C1/control01.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_name='wdb12c'
*.db_unique_name='ldb12c1'
*.db_create_file_dest='/u01/app/oracle/oradata'
*.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area'
*.db_recovery_file_dest_size=6930m
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=ldb12c1XDB)'
*.local_listener=''
*.log_archive_format='ARC%S_%R.%T'
*.memory_target=768m
*.open_cursors=300
*.processes=300
*.remote_login_passwordfile='EXCLUSIVE'
*.undo_tablespace='UNDOTBS1'

    

No destino precisamos realizar a criação do diretório “audit dump”

mkdir -p /u01/app/oracle/admin/ldb12c1/adump

    

No destino inicializaremos a nova instância “ldb12c1” em modo “NOMOUNT” fazendo uso do “Parameter File” construído e faremos a execução do comando “RESTORE FROM PLATFORM”. No comando “RESTORE FROM PLATFORM” especificamos:

• FROM PLATFORM 'Microsoft Windows x86 64-bit' ------à Sistema Operacional de origem do “Backup”. Este Parâmetro é requerido para realizar a conversão do BD
• FOREIGN DATABASE TO NEW --à A opção “TO NEW” especifica que os “FOREIGN DATA FILES” restaurados devem ser restaurados com base no conceito de OMF, o qual estará configurado no parâmetro “DB_CREATE_FILE_DEST”
• FROM BACKUPSET '/tmp/Backup1/WDB12C_TRANSPORT1.BCK'; -à localização o “Whole Database Backup” feito na base de dados de origem

[oracle@oel62-ora12c /]$ export ORACLE_SID=ldb12c1
[oracle@oel62-ora12c /]$ rman target / 

Recovery Manager: Release 12.1.0.1.0 - Production on Mon Jul 22 16:32:05 2013
Copyright (c) 1982, 2013, Oracle and/or its affiliates.  All rights reserved.

connected to target database (not started)

RMAN> startup nomount pfile='/tmp/Backup1/pfile4linux1.ora';

Oracle instance started

Total System Global Area     801701888 bytes

Fixed Size                     2293496 bytes
Variable Size                545259784 bytes
Database Buffers             251658240 bytes
Redo Buffers                   2490368 bytes

RMAN> RESTORE
          2> FROM PLATFORM 'Microsoft Windows x86 64-bit'
          3> FOREIGN DATABASE TO NEW
          4> FROM BACKUPSET '/tmp/Backup1/WDB12C_TRANSPORT1.BCK'; 

Starting restore at 22-JUL-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring all foreign files in backup piece
channel ORA_DISK_1: reading from backup piece /tmp/Backup1/WDB12C_TRANSPORT1.BCK
channel ORA_DISK_1: restoring foreign file 1 to /u01/app/oracle/oradata/LDB12C1/
datafile/o1_mf_system_8yt644bz_.dbf
channel ORA_DISK_1: restoring foreign file 3 to /u01/app/oracle/oradata/LDB12C1/
datafile/o1_mf_sysaux_8yt644f8_.dbf
channel ORA_DISK_1: restoring foreign file 5 to /u01/app/oracle/oradata/LDB12C1/
datafile/o1_mf_undotbs1_8yt644ht_.dbf
channel ORA_DISK_1: restoring foreign file 2 to /u01/app/oracle/oradata/LDB12C1/
datafile/o1_mf_example_8yt644lg_.dbf
channel ORA_DISK_1: restoring foreign file 6 to /u01/app/oracle/oradata/LDB12C1/
datafile/o1_mf_users_8yt644nk_.dbf
channel ORA_DISK_1: foreign piece handle=/tmp/Backup1/WDB12C_TRANSPORT1.BCK
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:16
Finished restore at 22-JUL-13
    

Visualizando os “Datafiles” restaurados

[oracle@oel62-ora12c datafile]$ pwd
/u01/app/oracle/oradata/LDB12C1/datafile
[oracle@oel62-ora12c datafile]$ 
[oracle@oel62-ora12c datafile]$ ls -l
total 2741816
-rw-r----- 1 oracle oinstall 374874112 Jul 22 16:34 o1_mf_example_8yt644lg_.dbf
-rw-r----- 1 oracle oinstall 828383232 Jul 22 16:34 o1_mf_sysaux_8yt644f8_.dbf
-rw-r----- 1 oracle oinstall 838868992 Jul 22 16:34 o1_mf_system_8yt644bz_.dbf
-rw-r----- 1 oracle oinstall 760225792 Jul 22 16:33 o1_mf_undotbs1_8yt644ht_.dbf
-rw-r----- 1 oracle oinstall   5251072 Jul 22 16:33 o1_mf_users_8yt644nk_.dbf
[oracle@oel62-ora12c datafile]$

    

Ajustes realizados no “Script” recriação dos “Controlfiles”

STARTUP NOMOUNT PFILE='/tmp/Backup1/pfile4linux1.ora'; 

CREATE CONTROLFILE REUSE DATABASE "WDB12C" RESETLOGS  ARCHIVELOG     
MAXLOGFILES 16     
MAXLOGMEMBERS 3     
MAXDATAFILES 100     
MAXINSTANCES 8     
MAXLOGHISTORY 292 
LOGFILE  
 GROUP 1 '/u01/app/oracle/oradata/LDB12C1/redo01.log'  SIZE 50M BLOCKSIZE 512,   
 GROUP 2 '/u01/app/oracle/oradata/LDB12C1/redo02.log'  SIZE 50M BLOCKSIZE 512,   
 GROUP 3 '/u01/app/oracle/oradata/LDB12C1/redo03.log'  SIZE 50M BLOCKSIZE 512 
DATAFILE   
 '/u01/app/oracle/oradata/LDB12C1/datafile/o1_mf_system_8yt644bz_.dbf',   
 '/u01/app/oracle/oradata/LDB12C1/datafile/o1_mf_example_8yt644lg_.dbf',   
 '/u01/app/oracle/oradata/LDB12C1/datafile/o1_mf_sysaux_8yt644f8_.dbf',   
 '/u01/app/oracle/oradata/LDB12C1/datafile/o1_mf_undotbs1_8yt644ht_.dbf',   
 '/u01/app/oracle/oradata/LDB12C1/datafile/o1_mf_users_8yt644nk_.dbf' 
CHARACTER SET AL32UTF8; 

-- Database can now be opened zeroing the online logs. 
ALTER DATABASE OPEN RESETLOGS; 

-- Commands to add tempfiles to temporary tablespaces. 
-- Online tempfiles have complete space information. 
-- Other tempfiles may require adjustment. 
ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/LDB12C1/datafile/temp01.dbf'      
SIZE 92274688  REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 32767M; 
-- End of tempfile additions.

Recriando “Controlfiles”, Abertura do BD & Ajuste do “Tablespace” temporário

[oracle@oel62-ora12c /]$ export ORACLE_SID=ldb12c1
[oracle@oel62-ora12c /]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Jul 22 16:43:40 2013
Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> shut immediate;
ORA-01507: database not mounted

ORACLE instance shut down.
SQL> @/tmp/Backup1/CONTROLFILE2TRACE1.SQL
ORACLE instance started.

Total System Global Area  801701888 bytes
Fixed Size		    2293496 bytes
Variable Size		  545259784 bytes
Database Buffers	  251658240 bytes
Redo Buffers		    2490368 bytes

Control file created.

Database altered.

Tablespace altered.

SQL>exit

    

Verificando a base de dados destino aberta e disponível, já convertida.

[oracle@oel62-ora12c /]$ export ORACLE_SID=ldb12c1
[oracle@oel62-ora12c /]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.1.0 Production on Mon Jul 22 16:43:40 2013
Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options

SQL> select platform_name from v$transportable_platform 
  2  where platform_id = (select platform_id from  v$database);

PLATFORM_NAME
--------------------------------------------------------------------------------
Linux x86 64-bit

SQL> select cdb, open_mode, log_mode from v$database;

CDB OPEN_MODE		 LOG_MODE
--- -------------------- ------------
NO  READ WRITE		 ARCHIVELOG

SQL> conn mahir/mahir
Connected.

SQL> select * from t;  

    N
----------
    1
    

Conclusão

Finalizamos o exemplo de transporte de BD, que foi objeto desse artigo. No mesmo utilizamos a cláusula “BACKUP FOR TRANSFORM” o qual como foi explicado no início do artigo, é um tipo de “Backup” transportável para qualquer plataforma contida na view “v$transportable_platform;”.

Vantagens: é um “Backup” transportável para qualquer plataforma descrita na view “v$transportable_platform;”

Desvantagens: Operação de conversão da base só pode ser feita no destino.

Joel é um DBA expert com mais de 12 anos de experiência, especializado nas áreas de bases de dados com especial ênfase em soluções de alta disponibilidade (RAC, Dataguard, e outros). É um palestrante habitual em eventos de Oracle como: OTN LAD TOUR e outros. É o primeiro latino-americano a ser nomeado "OTN Expert " no ano de 2003 e é Oracle ACE Director.

Mahir é um DBA Senior com mais de 10 anos de experiência no Oracle Database com foco especial em Alta disponibilidade e soluções de Recuperação contra desastres (RAC, Data Guard, RMAN,…). Atualmente trabalha para o Central Bank of the Republic of Azerbaijan. Ele é um Oracle Certified Professional DBA.
Mahir é palestrante do Azerbaijan Oracle User Group (AZEROUG) e também é blogger. Siga Mahir no seu blog http://www.mahir-quluzade.com

Mufalani é um DBA Sr. com mais de 10 anos de experiência, começou com o Oracle 8i, mas teve a oportunidade de dar suporte a Oracle 7.3.4 em diante. É especialista em banco de dados Oracle com foco principal em Performance & Tuning e RAC. É palestrante em eventos de Oracle como: OTN LAD TOUR e outros. Atualmente trabalha como consultor diversas empresas no segmento de variados ramos como: Educação, Saúde, Tecnologia, Seguros e etc. Foi o terceiro Oracle ACE a ser nomeado no Brasil e é OCP DBA nas versões 10g e 11g e OCE RAC 10gR2.