Pular para o conteúdo

Guia Completo para Migração de Bases Oracle 11g para Oracle 19c em Novos Servidores

Migrandos as bases legadas para o Oracle 19c

Neste artigo, não abordarei a atualização do banco de dados no mesmo servidor utilizando o DBUA (Database Upgrade Assistant), pois esse procedimento já é amplamente documentado.

Em vez disso, meu foco será a migração para um novo servidor, explorando estratégias que garantam integridade dos dados, continuidade operacional e eficiência no processo. Apresentarei métodos que minimizam o tempo de indisponibilidade, assegurando uma transição segura e bem planejada para o Oracle 19c.

Para ilustrar o processo, simularei um ambiente de produção baseado no Oracle 11g, que servirá como ponto de partida para a migração. O objetivo é demonstrar a transição para três cenários distintos:

  • Migração para File System
  • Migração para ASM (Automatic Storage Management)
  • Migração via IMPDP utilizando a rede

Além disso, abordarei estratégias avançadas de migração, como o uso do Data Guard e do GoldenGate, destacando suas vantagens e aplicabilidade para cenários que exigem mínima ou nenhuma indisponibilidade.

Todas as bases legadas devem ser previamente atualizadas para a versão 11.2.0.4 antes de prosseguir com a migração para o Oracle Database 19c.

Criando o ambiente no Oracle 11g

Estou simulando um ambiente de produção em menor escala no oracle 11g

— Verificar onde esta os datafiles

SQL
select name from v$datafile;

— Verifique se o parâmetro está devidamente configurado. Caso não esteja, ajuste-o corretamente com base no resultado da consulta acima.

SQL
show parameter db_create_file_dest
alter system set db_create_file_dest='/u02/oradata' scope=both sid='*';

— Criando as tablespaces

SQL
create tablespace ts1 datafile size 1m autoextend on next 1m maxsize unlimited;
create tablespace ts2 datafile size 1m autoextend on next 1m maxsize unlimited;
create tablespace ts3 datafile size 1m autoextend on next 1m maxsize unlimited;
create tablespace ts4 datafile size 1m autoextend on next 1m maxsize unlimited;

— Criando owner e usuarios de cada Aplicação

SQL
create USER owner1 identified by senha default tablespace ts1 quota unlimited on ts1;
create USER owner2 identified by senha default tablespace ts2 quota unlimited on ts2;
create USER owner3 identified by senha default tablespace ts3 quota unlimited on ts3;
create USER owner4 identified by senha default tablespace ts4 quota unlimited on ts4;
													
create USER USER1 identified by senha default tablespace ts1 quota unlimited on ts1;
create USER USER2 identified by senha default tablespace ts2 quota unlimited on ts2;
create USER USER3 identified by senha default tablespace ts3 quota unlimited on ts3;
create USER USER4 identified by senha default tablespace ts4 quota unlimited on ts4;

— Criando 1 tabela para cada owner

SQL
create table owner1.tabela1 tablespace ts1 as select * from all_objects;
create table owner2.tabela2 tablespace ts2 as select * from all_objects;
create table owner3.tabela3 tablespace ts3 as select * from all_objects;
create table owner4.tabela4 tablespace ts4 as select * from all_objects;

— Criando 1 role para cada Aplicação

SQL
create role role1;
create role role2;
create role role3;
create role role4;

— Dando permissões roles, owners e usuarios.

SQL
GRANT SELECT ON OWNER1.TABELA1 TO ROLE1;
GRANT SELECT ON OWNER2.TABELA2 TO ROLE2;
GRANT SELECT ON OWNER3.TABELA3 TO ROLE3;
GRANT SELECT ON OWNER4.TABELA4 TO ROLE4;

GRANT DBA TO OWNER1,OWNER2,OWNER3,OWNER4;
GRANT CONNECT,ROLE1 TO USER1;
GRANT CONNECT,ROLE2 TO USER2;
GRANT CONNECT,ROLE3 TO USER3;
GRANT CONNECT,ROLE4 TO USER4;

Neste momento, o ambiente está totalmente preparado para a migração para o Oracle 19c. Agora, o que será migrado?

Esta consulta é fundamental para garantir o sucesso da migração.

SQL
column PROPERTY_NAME format a35
column PROPERTY_NAME format a20
column DESCRIPTION format a20
SQL>  select * from database_properties where PROPERTY_NAME in ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');

O banco de dados Oracle 19c deve estar configurado com NLS_CHARACTERSET WE8MSWIN1252. Embora não seja um requisito obrigatório, essa configuração aumenta as chances de uma migração bem-sucedida.

SQL
select tablespace_name from dba_tablespaces order by 1;

Criando 2 bases 19c

orcl1 será asm

Bash
dbca -silent -createDatabase  -templateName General_Purpose.dbc -gdbName orcl1 -sid orcl1 -characterSet WE8MSWIN1252  -sysPassword senha -systemPassword senha -storageType ASM -datafileDestination  DG_DATA  -redoLogFileSize 50  -createAsContainerDatabase true -numberOfPDBs 1 -pdbName PDB1  -pdbAdminPassword Oracle_#123 -emConfiguration NONE

orcl2 será file system

Bash
dbca -silent -createDatabase  -templateName General_Purpose.dbc -gdbName orcl2 -sid orcl2 -characterSet WE8MSWIN1252  -sysPassword senha -systemPassword senha  -storageType FS -datafileDestination /u01/app/oracle/oradata  -redoLogFileSize 50  -createAsContainerDatabase true -numberOfPDBs 1 -pdbName PDB1  -pdbAdminPassword Oracle_#123 -emConfiguration NONE

Preparando o novo ambiente para a recepção dos dados do Oracle 11g.

SQL
Show pdbs

select name from v$datafile;

show parameter db_create_file_dest

alter system set db_create_file_dest='/u01/app/oracle/oradata' scope=both sid='*';

CREATE PLUGGABLE DATABASE fs_11g ADMIN USER PDBADMIN IDENTIFIED BY PDBADMIN ;

ALTER  PLUGGABLE DATABASE fs_11g OPEN;
ALTER  PLUGGABLE DATABASE fs_11g SAVE STATE;
ALTER SESSION SET CONTAINER=fs_11g;

select tablespace_name from dba_tablespaces;

Essas tablespaces não serão incluídas no processo de migração do Oracle 11g. Portanto, iremos selecionar apenas as demais tablespaces para a transição.

No Oracle 11g

SQL
select tablespace_name from dba_tablespaces where tablespace_name not in ('SYSTEM','SYSAUX','UNDOTBS1','TEMP');

Houve uma mudança no sistema operacional, passando de Solaris ou AIX para Linux, por exemplo. Neste documento, o ambiente de destino será o Linux.

São esses datafiles que iremos migrar.

SQL
select file_name from dba_Data_Files where  tablespace_name not in ('SYSTEM','SYSAUX','UNDOTBS1','TEMP');

No Oracle 19c

SQL
select name from v$datafile;

O comando para mudar de sistema operacional

Bash
convert datafile 'origem' to platform 'Linux x86 64-bit'  format 'destino'  parallelism 4;

Se o seu ambiente possuir uma alta capacidade de processamento (CPU), é possível utilizar um nível maior de paralelismo, reduzindo significativamente o tempo de migração. Como exemplo, configurei o paralelismo em 4.

Aqui estão exemplos fictícios demonstrando a conversão de datafiles dentro do mesmo sistema operacional, evidenciando a possibilidade de migração tanto para File System quanto para ASM:

  • Migração para File System:
Bash
CONVERT DATAFILE '/u02/oradata/orcl11g/users01.dbf'  
FORMAT '/u01/base/datafile/users01.dbf';

  • Migração para ASM:
Bash
CONVERT DATAFILE '/u02/oradata/orcl11g/users01.dbf'  
FORMAT '+DATA/base/datafile/users01.dbf';

Esses exemplos ilustram a flexibilidade do processo de migração, permitindo a transição para diferentes tipos de armazenamento de acordo com a necessidade do ambiente.

Datafiles de Origem (Oracle 11g)

Bash
/u02/oradata/orcl11g/users01.dbf                    
/u02/oradata/orcl11g/example01.dbf                  
/u02/oradata/ORCL11G/datafile/o1_mf_ts1_mxzzgpcl_.dbf
/u02/oradata/ORCL11G/datafile/o1_mf_ts2_mxzzgpqt_.dbf
/u02/oradata/ORCL11G/datafile/o1_mf_ts3_mxzzgq3m_.dbf
/u02/oradata/ORCL11G/datafile/o1_mf_ts4_mxzzgsr1_.dbf

Dafiles de Destino (ainda não existem) (Oracle 19c)

Bash
/u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/users01.dbf    
/u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/example01.dbf  
/u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/ts101.dbf      
/u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/ts201.dbf      
/u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/ts301.dbf      
/u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/ts401.dbf

Verifique no Oracle 11g se a tablespace é elegível para transporte.

Bash
SELECT 'EXEC SYS.DBMS_TTS.TRANSPORT_SET_CHECK(ts_list => '||chr(39)||tablespace_name||chr(39)||', incl_constraints => TRUE);' comando,' SELECT * FROM transport_set_violations;' verificar  from  dba_tablespaces    where  tablespace_name not in  ('SYSTEM','SYSAUX','UNDOTBS1','TEMP');

Todas as tablespaces são elegíveis para transporte. Caso alguma restrição seja identificada, será necessário corrigi-la antes de prosseguir com a migração.

No Oracle 11g

Iremos colocar todas as tablespaces em READ ONLY;

SQL
select 'alter tablespace '||tablespace_name||' read only;' comando from dba_tablespaces  where  tablespace_name not in ('SYSTEM','SYSAUX','UNDOTBS1','TEMP');

Criando um diretório para armazenar os datafiles convertidos ou copiados da origem.

SQL
cd /u01
mkdir backup
cp /u02/oradata/orcl11g/users01.dbf                       /u01/backup/users01.dbf  
cp /u02/oradata/orcl11g/example01.dbf                     /u01/backup/example01.dbf
cp /u02/oradata/ORCL11G/datafile/o1_mf_ts1_mxzzgpcl_.dbf  /u01/backup/ts1_01.dbf
cp /u02/oradata/ORCL11G/datafile/o1_mf_ts2_mxzzgpqt_.dbf  /u01/backup/ts2_01.dbf
cp /u02/oradata/ORCL11G/datafile/o1_mf_ts3_mxzzgq3m_.dbf  /u01/backup/ts3_01.dbf
cp /u02/oradata/ORCL11G/datafile/o1_mf_ts4_mxzzgsr1_.dbf  /u01/backup/ts4_01.dbf

Copie para area de backup

Agora, vamos criar um DIRECTORY no Oracle para utilização no expdp.

No Oracle 19c

SQL
set pagesize 500
select username from dba_users order by 1;

No processo de exportação (expdp) do Oracle 11g, excluirei diversos usuários que já existem no ambiente de destino no Oracle 19c. Dessa forma, evitamos redundâncias e garantimos uma migração mais eficiente.

Bash
expdp system/senha DIRECTORY=oracle11 DUMPFILE=oracle11g.dmp VERSION=12 FULL=Y TRANSPORTABLE=ALWAYS EXCLUDE=TABLE_STATISTICS,INDEX_STATISTICS LOGFILE=oracle1	1g.log  REUSE_DUMPFILES=y EXCLUDE=SCHEMA:\"IN\(\'APPQOSSYS\',\'AUDSYS\',\'CTXSYS\',\'DBSFWUSER\',\'DBSNMP\',\'DIP\',\'DVF\',\'DVSYS\',\'GGSYS\',\'GSMADMIN_INTERNAL\',\'GSMCATUSER\',\'GSMUSER\',\'LBACSYS\',\'MDDATA\',\'MDSYS\',\'OJVMSYS\',\'OLAPSYS\',\'ORACLE_OCM\',\'ORDDATA\',\'ORDPLUGINS\',\'ORDSYS\',\'OUTLN\',\'PDBADMIN\',\'REMOTE_SCHEDULER_AGENT\',\'SI_INFORMTN_SCHEMA\',\'SH\',\'SYS$UMF\',\'SYSBACKUP\',\'SYSDG\',\'SYSKM\',\'SYSRAC\',\'SYSTEM\',\'WMSYS\',\'XDB\'\)\" \

Explicação das sintaxes especiais:

EXCLUDE=SCHEMA: Exclui os esquemas listados.

Aspas duplas (\”) e parênteses escapados (\( e \)) garantem que o shell não interprete os caracteres de forma incorreta.

DUMPFILE e LOGFILE: Define os arquivos de dump e log.

FULL=Y: Faz a exportação completa do banco, excluindo apenas os esquemas especificados.

REUSE_DUMPFILES=Y: Permite sobrescrever os arquivos de dump caso já existam.

Esse comando pode ser executado diretamente no terminal Linux.

Após a execução do expdp, percebi que os usuários SYSMAN e APEX_030200 não precisam ser migrados. Portanto, irei adicioná-los à lista de EXCLUDE para otimizar o processo de exportação.

O comando ficou assim:

Bash
expdp system/senha DIRECTORY=oracle11 DUMPFILE=oracle11g.dmp VERSION=12 FULL=Y TRANSPORTABLE=ALWAYS EXCLUDE=TABLE_STATISTICS,INDEX_STATISTICS LOGFILE=oracle11g.log  REUSE_DUMPFILES=y EXCLUDE=SCHEMA:\"IN\(\'APPQOSSYS\',\'AUDSYS\',\'CTXSYS\',\'DBSFWUSER\',\'DBSNMP\',\'DIP\',\'DVF\',\'DVSYS\',\'GGSYS\',\'GSMADMIN_INTERNAL\',\'GSMCATUSER\',\'GSMUSER\',\'LBACSYS\',\'MDDATA\',\'MDSYS\',\'OJVMSYS\',\'OLAPSYS\',\'ORACLE_OCM\',\'ORDDATA\',\'ORDPLUGINS\',\'ORDSYS\',\'OUTLN\',\'PDBADMIN\',\'REMOTE_SCHEDULER_AGENT\',\'SI_INFORMTN_SCHEMA\',\'SH\',\'SYS$UMF\',\'SYSBACKUP\',\'SYSDG\',\'SYSKM\',\'SYSRAC\',\'SYSTEM\',\'WMSYS\',\'XDB\',\'SYSMAN\',\'APEX_030200\'\)\" \

Ao final do processo de expdp, são exibidas as tablespaces que estão sendo transportadas.

Bash
******************************************************************************
Datafiles required for transportable tablespace EXAMPLE:
  /u02/oradata/orcl11g/example01.dbf
Datafiles required for transportable tablespace TS1:
  /u02/oradata/ORCL11G/datafile/o1_mf_ts1_mxzzgpcl_.dbf
Datafiles required for transportable tablespace TS2:
  /u02/oradata/ORCL11G/datafile/o1_mf_ts2_mxzzgpqt_.dbf
Datafiles required for transportable tablespace TS3:
  /u02/oradata/ORCL11G/datafile/o1_mf_ts3_mxzzgq3m_.dbf
Datafiles required for transportable tablespace TS4:
  /u02/oradata/ORCL11G/datafile/o1_mf_ts4_mxzzgsr1_.dbf
Datafiles required for transportable tablespace USERS:
  /u02/oradata/orcl11g/users01.dbf
Job "SYSTEM"."SYS_EXPORT_FULL_01" successfully completed at Sun Mar 23 16:39:41 2025 elapsed 0 00:01:37
[oracle@servidor3 backup]$

No Oracle 19c, ao tentar criar o diretório com o usuário oracle:

Bash
cd /u01
mkdir backup

Foi identificado que o usuário oracle não possuía permissão para essa ação.

Por isso, o diretório foi criado utilizando o usuário root.

Agora, irei copiar todos os arquivos do diretório /u01/backup do servidor3 (Oracle 11g) para o diretório /u01/backup no servidor ol7server (Oracle 19c).

Bash
scp /u01/backup/*.* oracle@192.168.0.220:/u01/backup

Realizar a transferência dos datafiles para o diretório da base FS_11G, garantindo uma migração segura e eficiente.

Bash
cp /u01/backup/*.dbf /u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/

Conforme tela acima já criei o diretório para fazer o impdp.

Adicionar no tnsnames.ora

Bash
fs_11g =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.220)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = fs_11g)
    )
  )

Testar conexão

Bash
impdp system/senha@fs_11g DIRECTORY=oracle11 DUMPFILE=oracle11g.dmp  LOGFILE=impdporacle11g.log TRANSPORT_DATAFILES='/u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/example01.dbf','/u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/users01.dbf','/u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/ts1_01.dbf','/u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/ts2_01.dbf','/u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/ts3_01.dbf','/u01/app/oracle/oradata/ORCL2/310BD390EC532AEBE063DC00A8C07EEB/datafile/ts4_01.dbf'

Verificando

SQL
select tablespace_name from dba_tablespaces;

select username from dba_users where username like 'US%'
union
select username from dba_users where username like 'OWN%';
SQL
select role from dba_Roles where role like 'ROLE%';

SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE LIKE 'US%' UNION
SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE LIKE 'OWNER%';

SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE LIKE 'US%' UNION
SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE LIKE 'OWNER%';

SQL
SELECT * FROM DBA_TAB_PRIVS WHERE GRANTEE  LIKE  'ROLE%';

Concluí com êxito a migração do File System, garantindo uma transição eficiente e bem-sucedida.

Daremos início agora ao processo de migração utilizando ASM.

Preparando o novo ambiente para a recepção dos dados do Oracle 11g.

SQL
Show pdbs

select name from v$datafile;

show parameter db_create_file_dest
alter system set db_create_file_dest='/u01/app/oracle/oradata' scope=both sid='*';

CREATE PLUGGABLE DATABASE baseasm_11g ADMIN USER PDBADMIN IDENTIFIED BY PDBADMIN ;

ALTER  PLUGGABLE DATABASE baseasm_11g OPEN;
ALTER  PLUGGABLE DATABASE baseasm_11g SAVE STATE;
ALTER SESSION SET CONTAINER=baseasm_11g;

select tablespace_name from dba_tablespaces;

Essas tablespaces não serão incluídas no processo de migração do Oracle 11g. Portanto, iremos selecionar apenas as demais tablespaces para a transição.

No Oracle 11g

SQL
select tablespace_name from dba_tablespaces where tablespace_name not in ('SYSTEM','SYSAUX','UNDOTBS1','TEMP');

São esses datafiles que iremos migrar.

SQL
select file_name from dba_Data_Files where  tablespace_name not in ('SYSTEM','SYSAUX','UNDOTBS1','TEMP');

No Oracle 19c

SQL
select name from v$datafile;

Esses são os arquivos que iremos format em ASM.

SQL
CONVERT DATAFILE '/u01/backup/users01.dbf'   FORMAT '+DG_DATA/ORCL1/311F933B879B244FE063DC00A8C02C7C/DATAFILE/users01.dbf';
CONVERT DATAFILE '/u01/backup/example01.dbf' FORMAT '+DG_DATA/ORCL1/311F933B879B244FE063DC00A8C02C7C/DATAFILE/example01.dbf';
CONVERT DATAFILE '/u01/backup/ts1_01.dbf'    FORMAT '+DG_DATA/ORCL1/311F933B879B244FE063DC00A8C02C7C/DATAFILE/ts1_01.dbf';
CONVERT DATAFILE '/u01/backup/ts2_01.dbf'    FORMAT '+DG_DATA/ORCL1/311F933B879B244FE063DC00A8C02C7C/DATAFILE/ts2_01.dbf';
CONVERT DATAFILE '/u01/backup/ts3_01.dbf'    FORMAT '+DG_DATA/ORCL1/311F933B879B244FE063DC00A8C02C7C/DATAFILE/ts3_01.dbf';
CONVERT DATAFILE '/u01/backup/ts4_01.dbf'    FORMAT '+DG_DATA/ORCL1/311F933B879B244FE063DC00A8C02C7C/DATAFILE/ts4_01.dbf';

Para verificar os arquivos no ASM como usuário grid, utilize o seguinte comando:

Bash
asmcmd ls +DG_DATA/ORCL1/311EA1FF08DF1303E063DC00A8C0C7B5/DATAFILE

Esse comando listará os arquivos presentes no diretório DATAFILE, permitindo confirmar que os arquivos foram convertidos para ASM.

Criando um DIRECTORY para realizar a importação de dados com o impdp.

SQL
CREATE DIRECTORY ORACLE11 AS '/u01/backup';
grant read,write on directory oracle11 to system;

Adicionar no tnsnames.ora

Bash
baseasm_11g =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.220)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = baseasm_11g)
    )
  )

Testar conexão

Bash
impdp system/senha@baseasm_11g DIRECTORY=oracle11 DUMPFILE=oracle11g.dmp  LOGFILE=impdporacle11g.log TRANSPORT_DATAFILES='+DG_DATA/ORCL1/311F933B879B244FE063DC00A8C02C7C/DATAFILE/users01.dbf','+DG_DATA/ORCL1/311F933B879B244FE063DC00A8C02C7C/DATAFILE/example01.dbf','+DG_DATA/ORCL1/311F933B879B244FE063DC00A8C02C7C/DATAFILE/ts1_01.dbf','+DG_DATA/ORCL1/311F933B879B244FE063DC00A8C02C7C/DATAFILE/ts2_01.dbf','+DG_DATA/ORCL1/311F933B879B244FE063DC00A8C02C7C/DATAFILE/ts3_01.dbf','+DG_DATA/ORCL1/311F933B879B244FE063DC00A8C02C7C/DATAFILE/ts4_01.dbf'

Devido aos erros ocorridos durante a migração do File System, optei por realizar um novo expdp, incluindo os esquemas APEX_030200 e SYSMAN. Agora, iremos analisar quais erros poderão ocorrer no ambiente ASM.

Verificando

SQL
select tablespace_name from dba_tablespaces;

select username from dba_users where username like 'US%'
union
select username from dba_users where username like 'OWN%';

SQL
select role from dba_Roles where role like 'ROLE%';

column grantee format a10
column privilege format a30
column granted_role format a10

SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE LIKE 'US%' UNION
SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE LIKE 'OWNER%';

SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE LIKE 'US%' UNION
SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE LIKE 'OWNER%'

SQL
column owner format a10
column table_name format a10
column grantor format a10
column PRIVILEGE   format a10
set linesize 200
SELECT * FROM DBA_TAB_PRIVS WHERE GRANTEE  LIKE  'ROLE%';

Finalizei com sucesso a migração do ASM, assegurando uma transição eficiente e bem-sucedida.

Os métodos utilizados foram expdp seguido de impdp. Existe uma alternativa que utiliza apenas impdp, porém, essa abordagem demanda um alto consumo de rede.

Vale a pena avaliar se a infraestrutura suporta essa carga antes de optar por essa estratégia.

Preparando o novo ambiente para a recepção dos dados do Oracle 11g.

SQL
Show pdbs
select name from v$datafile;
show parameter db_create_file_dest

SQL
CREATE PLUGGABLE DATABASE fs2_11g ADMIN USER PDBADMIN IDENTIFIED BY PDBADMIN ; 
ALTER  PLUGGABLE DATABASE fs2_11g OPEN;
ALTER  PLUGGABLE DATABASE fs2_11g SAVE STATE;
ALTER SESSION SET CONTAINER=fs2_11g;

select tablespace_name from dba_tablespaces;

SQL
create directory oracle11 as '/u01/backup';
grant read,write on directory oracle11 to system;
create public database link oracle11g connect to system identified by senha using 'ORCL11G';

No arquivo tnsnames.ora do Oracle 19c, adicionaremos a entrada correspondente ao Oracle 11g e a nova base criada.

Essa configuração permitirá a comunicação entre os bancos de dados por meio de um dblink, viabilizando o uso da rede para a transferência de dados.

SQL
ORCL11G=
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.243)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl11g)
    )
  )

fs2_11g =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.220)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = fs2_11g)
    )
  )

Testando database link

A comunicação entre os bancos de dados foi estabelecida com sucesso.TRealizar a transferência dos datafiles para o diretório da base FS2_11G

Bash
cp /u01/backup/users01.dbf     /u01/app/oracle/oradata/ORCL2/31211854CB7D3C35E063DC00A8C030BC/datafile
cp /u01/backup/example01.dbf   /u01/app/oracle/oradata/ORCL2/31211854CB7D3C35E063DC00A8C030BC/datafile
cp /u01/backup/ts1_01.dbf      /u01/app/oracle/oradata/ORCL2/31211854CB7D3C35E063DC00A8C030BC/datafile
cp /u01/backup/ts2_01.dbf      /u01/app/oracle/oradata/ORCL2/31211854CB7D3C35E063DC00A8C030BC/datafile
cp /u01/backup/ts3_01.dbf      /u01/app/oracle/oradata/ORCL2/31211854CB7D3C35E063DC00A8C030BC/datafile
cp /u01/backup/ts4_01.dbf      /u01/app/oracle/oradata/ORCL2/31211854CB7D3C35E063DC00A8C030BC/datafile

Bash
impdp system/senha@fs2_11g network_link=oracle11g version=12 full=y transportable=always metrics=y exclude=statistics directory=oracle11 logfile=impdp_fs2_11g.log transport_datafiles='/u01/app/oracle/oradata/ORCL2/31211854CB7D3C35E063DC00A8C030BC/datafile/users01.dbf','/u01/app/oracle/oradata/ORCL2/31211854CB7D3C35E063DC00A8C030BC/datafile/example01.dbf','/u01/app/oracle/oradata/ORCL2/31211854CB7D3C35E063DC00A8C030BC/datafile/ts1_01.dbf','/u01/app/oracle/oradata/ORCL2/31211854CB7D3C35E063DC00A8C030BC/datafile/ts2_01.dbf','/u01/app/oracle/oradata/ORCL2/31211854CB7D3C35E063DC00A8C030BC/datafile/ts3_01.dbf','/u01/app/oracle/oradata/ORCL2/31211854CB7D3C35E063DC00A8C030BC/datafile/ts4_01.dbf'

Verificando

SQL
select tablespace_name from dba_tablespaces;

select username from dba_users where username like 'US%'
union
select username from dba_users where username like 'OWN%';

SQL
select role from dba_Roles where role like 'ROLE%';

column grantee format a10
column privilege format a30
column granted_role format a10

SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE LIKE 'US%' UNION
SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE LIKE 'OWNER%';

SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE LIKE 'US%' UNION
SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE LIKE 'OWNER%';

SQL
column owner format a10
column table_name format a10
column grantor format a10
column PRIVILEGE   format a10
set linesize 200
SELECT * FROM DBA_TAB_PRIVS WHERE GRANTEE  LIKE  'ROLE%';

Em todos os cenários executados (File System e ASM), utilizando EXPDP e IMPDP, e no último caso, apenas IMPDP via rede para a migração, o processo foi concluído com êxito. Os erros observados foram irrelevantes e não impactaram o resultado final.

Para finalizar a migração em todos os cenários abordados neste artigo, é essencial definir se o Oracle 11g continuará sendo utilizado. Caso seja mantido, será necessário um passo adicional no processo.

Se for esse o caso, todas as tablespaces serão configuradas para o modo READ WRITE:

SQL
SELECT 'ALTER TABLESPACE ' || tablespace_name || ' READ WRITE;' AS comando  
FROM dba_tablespaces  
WHERE tablespace_name NOT IN ('SYSTEM', 'SYSAUX', 'UNDOTBS1', 'TEMP');

Por outro lado, caso o Oracle 11g não seja mais necessário, o ambiente poderá ser encerrado com os seguintes comandos:

Bash
SHUTDOWN IMMEDIATE;  
EXIT;

Com isso, a migração será concluída com êxito!

Em todos os cenários executados (File System e ASM), utilizando EXPDP e IMPDP, e no último caso, apenas IMPDP via rede para a migração, o processo foi concluído com êxito. Os erros observados foram irrelevantes e não impactaram o resultado final.  Vale destacar que este é um ambiente de teste e não um ambiente crítico de produção, onde é fundamental adotar precauções adicionais para garantir total segurança e integridade dos dados.

Ao final do processo de migração, é altamente recomendável executar o seguinte script para recompilar objetos inválidos no banco de dados:

Bash
@?/rdbms/admin/utlrp.sql

O script utlrp.sql recompila automaticamente todos os objetos inválidos no banco de dados, garantindo a integridade e o desempenho ideal do ambiente após a migração.

Em ambiente de produção, antes de definir as tablespaces como Read-Only para a migração, é essencial adotar algumas precauções. É fundamental desativar previamente todos os processos que realizam gravações, como Jobs, Schedulers e possíveis tarefas agendadas na Crontab, evitando falhas durante a transição. Lembre-se de que, uma vez em Read-Only, qualquer tentativa de escrita resultará em erros. Normalmente, Schedulers e Jobs são utilizados para essa finalidade, mas é importante verificar se há dependências na Crontab também.

Para gerenciar Jobs durante o processo de migração, existem duas abordagens possíveis:

Opção 1: Utilizando Scripts SQL

1.Crie um arquivo jobs.sql e adicione os seguintes comandos:

SQL
spool desativa_job.sql  
select 'dbms_job.broken('||job||',true);' from dba_jobs where broken = 'N';  
spool off  

spool ativa_job.sql  
select 'dbms_job.broken('||job||',false);' from dba_jobs where broken = 'N';  
spool off

2.Execute o script

SQL
@jobs.sql

Isso gerará dois arquivos:

desativa_job.sql → Deve ser executado antes de definir as tablespaces como Read-Only.

ativa_job.sql → Deve ser executado após as tablespaces retornarem para Read-Write (ONLINE).

Opção 2: Ajustando o parâmetro JOB_QUEUE_PROCESSES

1.Consulte o valor atual do parâmetro para posterior restauração:

SQL
show parameter job_queue_processes;

2.Para desativar os Jobs, execute:

SQL
alter system set job_queue_processes=0 scope=both sid='*';

3.Para reativá-los, basta restaurar o valor salvo anteriormente:

SQL
alter system set job_queue_processes=<valor_anterior> scope=both sid='*';

Ambas as abordagens garantem que nenhum Job em execução cause conflitos durante a migração das Tablespaces.

Para desativar e reativar os Schedulers durante a migração, há uma abordagem eficiente utilizando scripts SQL.

1.Crie um arquivo chamado sched.sql e adicione os seguintes comandos:

SQL
spool desativa_sched.sql  
SELECT 'EXEC dbms_scheduler.disable (''' || owner || '.' || job_name || ''');'  
FROM dba_scheduler_jobs  
WHERE enabled = 'TRUE'  
ORDER BY owner, job_name;  
spool off  

spool ativa_sched.sql  
SELECT 'EXEC dbms_scheduler.enable (''' || owner || '.' || job_name || ''');'  
FROM dba_scheduler_jobs  
WHERE enabled = 'TRUE'  
ORDER BY owner, job_name;  
spool off

2.Execução do script:

SQL
@sched.sql

Isso gerará dois arquivos:

desativa_sched.sql → Responsável por desativar os Schedulers.

ativa_sched.sql → Responsável por reativá-los.

3.Ordem de execução:

Antes de definir as Tablespaces como Read-Only, execute:

SQL
@desativa_sched.sql

Após retornar as Tablespaces para Read-Write (ONLINE), reative os Schedulers com:

SQL
@ativa_sched.sql

Essa abordagem garante que nenhum Job Agendado interfira no processo de migração.

Para monitorar a execução de Jobs e Schedulers no banco de dados, utilize os seguintes comandos:

SQL
SELECT * FROM DBA_JOBS_RUNNING;
SELECT * FROM DBA_SCHEDULER_RUNNING_JOBS;

Esses comandos exibem a lista de Jobs e Schedulers que estão em execução no momento, permitindo um gerenciamento preciso antes de realizar manutenções ou migrações no ambiente.

            Uma estratégia amplamente adotada por muitas empresas para migrações seguras e com baixa indisponibilidade é a criação de um novo servidor contendo ambas as versões do Oracle: a antiga e a nova.

Passo a passo da abordagem

1.Configuração do Data Guard:

  • No novo servidor, configuramos um Data Guard com a versão antiga do Oracle, mantendo a replicação ativa e sincronizada com o ambiente de produção atual.

2.Sincronização e agendamento da migração:

  • Após a validação do funcionamento e da atualização contínua do Data Guard, define-se uma data para a migração definitiva.

3.Interrupção controlada e ativação do novo ambiente:

  • No momento da transição:
    • Desativamos o Primary no ambiente antigo.
    • Paralisamos o Standby no novo servidor.
    • Convertendo o Standby em Primary, ativamos o banco de dados na nova infraestrutura.

4.Atualização para a nova versão do Oracle:

  • Com o ambiente já operacional, utilizamos o DBUA (Database Upgrade Assistant) para realizar a atualização do Oracle.

5.Plano de contingência:

Caso ocorra algum problema durante a migração, o ambiente antigo pode ser rapidamente reativado, garantindo um rollback seguro.

Pontos importantes:

O tempo de indisponibilidade é reduzido, pois a maior parte do processo ocorre de forma prévia e sincronizada.

O Data Guard só pode ser implementado entre servidores com o mesmo sistema operacional, sendo um requisito essencial para essa abordagem.

Essa estratégia já foi aplicada com sucesso, demonstrando sua eficácia e confiabilidade no processo de migração do Oracle!

Por fim, embora eu não tenha implementado essa abordagem, existe uma solução avançada para migração sem indisponibilidade: o Oracle GoldenGate.

Essa poderosa tecnologia permite a replicação contínua e em tempo real entre o ambiente de origem e o novo ambiente, garantindo que todas as transações sejam sincronizadas de forma precisa. Assim, a migração ocorre sem impacto na disponibilidade do banco de dados, proporcionando uma transição fluida, segura e imperceptível para os usuários.

O principal desafio dessa solução, no entanto, é o custo, uma vez que a implementação exige a aquisição de duas licenças do Oracle GoldenGate—uma para o ambiente de origem e outra para o ambiente de destino.

José Eskinazi

José Eskinazi

oca 10g, ocp 10g, ocp 11g e ocp19c

Prestigie o autor e deixe o seu comentário:

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Marcações: