Revisão do RMAN CONVERT DATABASE: Migração de 6TB entre Linux e Solaris com downtime de 30 minutos

Revisão do RMAN CONVERT DATABASE: Migração de 6TB entre Linux e Solaris com downtime de 30 minutos

E olha que 20 minutos foi para rodar o utlrp.

Há alguns dias eu fiz um post sobre o RMAN CONVERT DATABASE, que permite que um banco de dados seja migrado para outra plataforma e arquitetura. No caso do meu teste, a migração foi de CentOS 4.8 x32-64 para Solaris 10 x32-64, ambos com Oracle Database 10.2.0.4.
Mas o tempo de parada possível para o cliente não permitia a migração desta forma, pois os servidores estão acessíveis apenas por rede, e não via Storage, e o banco possui alguns bons TB.

O Oracle Golden Gate não é uma opção para o cliente, pois ele não está disponível para sua plataforma origem (RHEL 4 PowerPC).

Quais minhas opções então?

Fui estudar melhor o RMAN CONVERT DATABASE. O comando é executado na plataforma origem, que cria um script (a ser executado na plataforma destino) e uma cópia dos DATAFILEs já convertidos para a plataforma destino, informada no comando. O meu problema é o tempo de criação destes DATAFILEs em uma área temporária (com o banco de dados origem em estado READ ONLY), mais a cópia para a nova plataforma via rede, mais a migração para ASM na plataforma destino. Fora o espaço necessário para as áreas temporárias de origem e destino, ou ter apenas a área no destino e monstar na origem como NFS.

CONVERT DATABASE NEW DATABASE 'CLIENTE' TRANSPORT SCRIPT '/home/oracle/transportscript.sql' to platform 'Solaris Operating System (x86-64)' DB_FILE_NAME_CONVERT '+DADOS/cliente/datafile/' '/stage/';

E o que faz o script gerado por este comando? Nada de complexo. Resumidamente, ele cria o controlfile, abre o banco de dados em RESETLOGs, e por fim invalida e recompila todas as Procedures.

-- The following commands will create a new control file and use it
 -- to open the database.
 -- Data used by Recovery Manager will be lost.
 -- The contents of online logs will be lost and all backups will
 -- be invalidated. Use this only if online logs are damaged.
 
 -- After mounting the created controlfile, the following SQL
 -- statement will place the database in the appropriate
 -- protection mode:
 --  ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE
 
 STARTUP NOMOUNT PFILE='/u01/app/oracle/product/10.2.0/db_1/dbs/init_00naj11c_1_0.ora'
 
 -- Create SPFILE
 CREATE SPFILE FROM PFILE = '/u01/app/oracle/product/10.2.0/db_1/dbs/init_00naj11c_1_0.ora';
 
 STARTUP FORCE NOMOUNT
 CREATE CONTROLFILE REUSE SET DATABASE "CLIENTE" RESETLOGS  ARCHIVELOG
     MAXLOGFILES 16
     MAXLOGMEMBERS 3
     MAXDATAFILES 100
     MAXINSTANCES 8
     MAXLOGHISTORY 292
 LOGFILE
   GROUP 1 SIZE 50M,
   GROUP 2 SIZE 50M,
   GROUP 3 SIZE 50M,
   GROUP 4 SIZE 100M
 DATAFILE
   '/stage/system.256.782246323',
   '/stage/undotbs1.258.782246325',
   '/stage/sysaux.257.782246325',
   '/stage/users.259.782246325',
   '/stage/example.265.782246405',
   '/stage/users.267.782246635',
   '/stage/users.269.782246711',
   '/stage/users.270.782246711',
   '/stage/users.271.782246713',
   '/stage/users.272.782246713',
   '/stage/users.273.782246713',
   '/stage/users.274.782246713',
   '/stage/users.275.782246721',
   '/stage/users.276.782246721',
   '/stage/users.277.782246721',
   '/stage/users.278.782246723'
 CHARACTER SET WE8ISO8859P1
 ;
 
 -- 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
      SIZE 20971520  AUTOEXTEND ON NEXT 655360  MAXSIZE 32767M;
 -- End of tempfile additions.
 --
 
 set echo off
 prompt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 prompt * Your database has been created successfully!
 prompt * There are many things to think about for the new database. Here
 prompt * is a checklist to help you stay on track:
 prompt * 1. You may want to redefine the location of the directory objects.
 prompt * 2. You may want to change the internal database identifier (DBID)
 prompt *    or the global database name for this database. Use the
 prompt *    NEWDBID Utility (nid).
 prompt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 SHUTDOWN IMMEDIATE
 STARTUP UPGRADE
 @@ ?/rdbms/admin/utlirp.sql
 SHUTDOWN IMMEDIATE
 STARTUP
 -- The following step will recompile all PL/SQL modules.
 -- It may take serveral hours to complete.
 @@ ?/rdbms/admin/utlrp.sql
 set feedback 6;

Para agilizar a migração, minha idéia era a de migrar o banco, mas continuar aplicando ARCHIVEs na nova plataforma, que foram gerados na antiga plataforma. Mas o script criado pelo RMAN CONVERT DATABASE não permitiria isso, pois abre o banco em RESETLOGs, criando uma nova incarnação do banco de dados, inviabilizando a aplicação de ARCHIVEs da incarnação antiga.

Tentei também aplicar os ARCHIVEs antes do OPEN RESETLOGs, mas recebi um ORA-00600 informando que não era possível executar o RECOVER em um DATAFILE de UNDO. Esta pista é importante, veja mais a seguir.

Pesquisando mais a respeito, encontrei esta nota no MOS (My Oracle Support) a respeito da migração entre plataformas com o mesmo endian (meu caso). Vejam o que ela diz:

Cross-Platform Database Migration (across same endian) using RMAN Transportable Database [ID 1401921.1]
 It's default behavior is to perform datafile conversion on all datafiles in the database. However, only datafiles that contain undo data require conversion including all datafiles beloging to SYSTEM tablespace and all UNDO tablespaces.

O comando CONVERT DATABASE não faz ABSOLUTAMENTE NADA nos DATAFILEs de dados! Só é necessário converter os DATAFILEs das TABLESPACEs SYSTEM e UNDO, e não o banco todo. E a TABLESPACE SYSTEM só sofrerá conversão nos segmentos de ROLLBACK, que não são utilizados, pois estou utilizando UNDO_MANAGEMENT=AUTO.

Partindo desta premissa e de acordo com a nota, considerei que um RESTORE de RMAN normal funcionaria, e após o RESTORE, executar o CONVERT DATAFILE apenas no que é necessário, e em seguida executar RECOVER, aplicando ARCHIVEs até o dia da migração, onde só então executo o OPEN RESETLOGs após aplicar o último ARCHIVE. O CONTROLFILE posso recuperar facilmente com um RESTORE CONTROLFILE FROM, também via RMAN..

Então o procedimento é o seguinte:
– Servidor VELHO: Cria PFILE e copia para Servidor NOVO;
– Servidor NOVO: Adapta diretórios do PFILE, se necessário. Se caminhos mudaram, adicione parâmetros DB_FILE_NAME_CONVERT e LOG_FILE_NAME_CONVERT;
ALTER SYSTEM SET DB_FILE_NAME_CONVERT=’+DADOS’,’+CLIENTE’ SCOPE=SPFILE;
ALTER SYSTEM SET LOG_FILE_NAME_CONVERT=’+FRA’,’+CLIENTE’ SCOPE=SPFILE;
– Servidor NOVO: Inicia em NOMOUNT;
– Servidor VELHO: Cria BACKUP do CONTROLFILE por RMAN, copia o BACKUPPIECE para Servidor NOVO (BACKUP CURRENT CONTROLFILE);
– Servidor NOVO: Restaura o CONTROLFILE pelo RMAN (RESTORE CONTROLFILE FROM ‘/stage/o1_mf_ncnnf_TAG20120510T030757_7tppsy3n_.bkp’;);
– Servidor NOVO: Passa a instância para o estado MOUNT;
– Servidor VELHO: Executa BACKUPSET quente via RMAN, e copia para Servidor NOVO;
– Servidor NOVO: Executa CATALOG nos BACKUPSETs copiados via RMAN;
– Servidor NOVO: Executa RESTORE DATABASE via RMAN:
RMAN> {
RESTORE DATABASE;
SWITCH DATAFILE ALL;
SWITCH TEMPFILE ALL;
}
– Servidor VELHO: Verificar quais DATAFILEs tem segmentos de UNDO:
SQL> SELECT FILE_ID “Datafiles requiring Conversion” FROM DBA_DATA_FILES WHERE TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM DBA_ROLLBACK_SEGS);
– Servidor NOVO: Verificar nomes dos DATAFILEs informados no passo anterior:
SQL> SELECT NAME “Datafiles requiring Conversion” FROM V$DATAFILE WHERE FILE# IN (1,2);
– Servidor NOVO: Executa CONVERT em todos DATAFILEs com segmentos de UNDO:
RMAN> CONVERT DATAFILE ‘+CLIENTE/cliente/datafile/system.260.782918365’ FROM PLATFORM ‘Linux x86 64-bit’;
RMAN> CONVERT DATAFILE ‘+CLIENTE/cliente/datafile/undotbs1.274.782918689’ FROM PLATFORM ‘Linux x86 64-bit’;
– Servidor VELHO: Copia Archives para Servidor NOVO;
– Servidor NOVO: Executa CATALOG nos Archives copiados;
– Servidor NOVO: Executa RECOVER DATABASE;

Continuo executando uma atualização periodicamente até o dia da migração, dependendo do volume de ARCHIVEs gerados:
– Servidor VELHO: Copia Archives para Servidor NOVO;
– Servidor NOVO: Executa CATALOG nos Archives copiados;
– Servidor NOVO: Executa RECOVER DATABASE;

E no dia da migração:
– Servidor VELHO: Cria o último Archive: ALTER SYSTEM ARCHIVE LOG CURRENT;
– Servidor VELHO: Copia Archives para Servidor NOVO;
– Servidor NOVO: Executa CATALOG nos Archives copiados via RMAN;
– Servidor NOVO: Executa RECOVER DATABASE;
– Servidor NOVO: Abre o banco: ALTER DATABASE OPEN RESETLOGS;
– Servidor NOVO: Adiciona TEMPFILEs: ALTER TABLESPACE TEMP ADD TEMPFILE SIZE 20971520 AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;
– Servidor NOVO: SHUTDOWN IMMEDIATE;
– Servidor NOVO: STARTUP UPGRADE;
– Servidor NOVO: Invalidar todas as Procedures: @?/rdbms/admin/utlirp.sql;
– Servidor NOVO: SHUTDOWN IMMEDIATE;
– Servidor NOVO: STARTUP;
– Servidor NOVO: Recompilar todas as procedures: @?/rdbms/admin/utlrp.sql;

Para facilitar e agilizar ainda mais o processo, eu poderia até montar a FRA origem como NFS no destino, mas não foi necessário.
Teoricamente, eu poderia criar até um Data Guard Physical Standby na nova arquitetura, mas eu preferi evitar ao máximo procedimentos não homologados pela Oracle, que podem custar o suporte ao produto.

Não coloquei o teste todo aqui, porque no final foi praticamente um RESTORE / RECOVER normal, como se fosse em outro servidor mas da mesma plataforma. Mas quis compartilhar o planejamento aqui com vocês (e para mim também, mês que vem já terei esquecido como se fazia isso).