Fim do suporte do RDS Custom para Oracle

1. Iniciar e configurar a instância do EC2

   Inicie uma instância do EC2 com as seguintes considerações:

   • Tipo de instância: escolha um tipo de instância do EC2 que satisfaça os requisitos de recursos do seu workload. Usar a mesma classe da instância do RDS Custom é um bom ponto de partida. Considere os requisitos de memória, CPU e largura de banda da rede.

   • Sistema operacional: Oracle Linux ou Red Hat Enterprise Linux (correspondente ou compatível com sua versão de sistema operacional do RDS Custom)

   • Software Oracle: instale o software Oracle Database (mesma versão principal, versão secundária, atualização de versão e, de preferência, os mesmos patches únicos do RDS Custom). Verifique se o software Oracle está instalado em /u01/app/oracle/ ou no local de sua preferência.

   • Armazenamento: configure os volumes do Amazon EBS com tamanho e IOPS adequados para satisfazer seus requisitos de workload. Use volumes gp3 para desempenho econômico ou io2 Block Express para workloads de alto desempenho.

2. Configurar a arquitetura de armazenamento

   1. Armazenamento do sistema de arquivos (recomendado para a maioria dos cenários)

      • Usar diretórios padrão do sistema de arquivos para arquivos de dados Oracle

      • Mais simples de gerenciar e adequado para a maioria dos workloads

      • Essa orientação usa exemplos de armazenamento do sistema de arquivos

   2. Oracle Automatic Storage Management (ASM)

      • Se o workload exigir o ASM, instale e configure o ASM autônomo na instância do EC2

      • Ajuste todos os parâmetros de caminho no arquivo init conforme necessário para usar grupos de discos do ASM (por exemplo, +DATA, +FRA)

      • O processo de migração é semelhante para o ASM, com ajustes de caminho

3. Configurar o mecanismo de transferência de arquivos

   Crie um mecanismo para transferir arquivos entre as instâncias do RDS Custom e do EC2. Você tem várias opções:

   1. Opção A: Amazon S3 (recomendado para a maioria dos cenários)

      • Criar um bucket do Amazon S3 ou usar um existente

      • Instalar e configurar a CLI da AWS nas duas instâncias

      • Para obter instruções, consulte Introdução à AWS CLI.

   2. Opção B: SCP/SFTP direto

      • Se as portas SSH estiverem abertas entre as instâncias, você poderá transferir arquivos diretamente

      • Adequado para arquivos pequenos, como arquivos de parâmetro e arquivos de senha

   3. Opção C: Amazon EFS

      • Se você já tem o Amazon EFS montado nas duas instâncias, pode usá-lo como um sistema de arquivos compartilhado

      • Adequado para ambientes com infraestrutura do EFS existente

      Essa orientação usa o Amazon S3 para dar exemplos, mas você pode adaptar os comandos para o método escolhido.

4. Configurar a conectividade de rede

   Garanta a conectividade de rede entre as instâncias do RDS Custom e do EC2:

   • Mesma VPC: os grupos de segurança devem permitir tráfego bidirecional na porta do receptor Oracle (padrão 1521 ou sua porta personalizada)

   • VPCs diferentes (mesma conta): configure o emparelhamento de VPC, tabelas de rotas e grupos de segurança

   • Contas diferentes: configure o emparelhamento de VPC entre contas ou use o AWS Transit Gateway

   • Verifique a conectividade: use ping e telnet para testar a conectividade na porta do banco de dados

5. Criar uma estrutura de diretórios no EC2

   A estrutura do diretório depende da arquitetura do banco de dados:

   exemplo Para não CDB:

   # Non-CDB directories
   mkdir -p /u01/app/oracle/oradata/ORCL/controlfile/
   mkdir -p /u01/app/oracle/oradata/ORCL/datafile
   mkdir -p /u01/app/oracle/oradata/ORCL/onlinelog
   mkdir -p /u01/app/oracle/oradata/ORCL/arch
   mkdir -p /u01/app/oracle/admin/ORCL/adump
   mkdir -p /u01/app/oracle/backup
   # Set ownership
   chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL
   chown -R oracle:oinstall /u01/app/oracle/admin/ORCL
   chown -R oracle:oinstall /u01/app/oracle/backup

   exemplo Para multilocatário (CDB com PDBs)

   # CDB directories
   mkdir -p /u01/app/oracle/oradata/ORCL/controlfile/
   mkdir -p /u01/app/oracle/oradata/ORCL/cdb/datafile
   mkdir -p /u01/app/oracle/oradata/ORCL/pdbseed/datafile
   mkdir -p /u01/app/oracle/oradata/ORCL/onlinelog
   mkdir -p /u01/app/oracle/oradata/ORCL/arch
   mkdir -p /u01/app/oracle/admin/ORCL/adump
   mkdir -p /u01/app/oracle/backup
   # PDB directories (RDS Custom uses OMF with GUID-based paths)
   # Create a generic pdb directory - migration will create subdirectories as needed
   mkdir -p /u01/app/oracle/oradata/ORCL/pdb/datafile
   # Set ownership
   chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL
   chown -R oracle:oinstall /u01/app/oracle/admin/ORCL
   chown -R oracle:oinstall /u01/app/oracle/backup

   nota

   O RDS Custom para Oracle usa o Oracle Managed Files (OMF) para arquivos de dados do PDB com subdiretórios baseados em GUID (por exemplo, /rdsdbdata/db/pdb/RDSCDB_A/{GUID}/datafile/). O processo de migração criará automaticamente a estrutura de subdiretórios necessária no destino. Você só precisa criar os diretórios pai.

   Estratégia de armazenamento: use um volume do EBS separado para /u01/app/oracle/backup para desanexá-lo e removê-lo facilmente após a conclusão da migração, diminuindo os custos de armazenamento.

6. Verificar a configuração do banco de dados de origem

1. Faça login no host do banco de dados do RDS Custom como usuário rdsdb e defina o ambiente:

   exemplo

   # For non-CDB
   export ORACLE_HOME=/rdsdbbin/oracle.19.custom.r1.EE.1
   export ORACLE_SID=ORCL
   export PATH=$ORACLE_HOME/bin:$PATH
   
   # For multitenant CDB
   export ORACLE_HOME=/rdsdbbin/oracle.19.custom.r1.EE-CDB.1
   export ORACLE_SID=RDSCDB
   export PATH=$ORACLE_HOME/bin:$PATH

2. Conecte-se ao banco de dados e verifique a arquitetura:

   exemplo

   sqlplus / as sysdba
   SQL> SELECT name, cdb, open_mode, log_mode FROM v$database;

   exemplo Para não CDB, saída esperada

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

   exemplo Para multilocatário (CDB), saída esperada:

   NAME    CDB  OPEN_MODE             LOG_MODE
   --------- --- -------------------- ------------
   RDSCDB    YES READ WRITE           ARCHIVELOG

3. Se você tiver um CDB multilocatário, liste todos os PDBs e os status de cada um:

   exemplo

   SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs;

   Saída esperada (exemplo com 1 PDB chamado ORCLDB):

   exemplo

   CON_ID     NAME                           OPEN_MODE  RES
   ---------- ------------------------------ ---------- ---
   2          PDB$SEED                       READ ONLY  NO
   3          ORCLDB                         READ WRITE NO

4. Verifique o tamanho total do banco de dados:

   exemplo Para não CDB:

   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files;

   exemplo Para multilocatário:

   -- Total CDB size (all containers)
   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM cdb_data_files;
   -- Size per PDB
   SQL> SELECT p.name AS pdb_name,
         ROUND(SUM(d.bytes)/1024/1024/1024, 2) AS size_gb
   FROM v$pdbs p
   JOIN cdb_data_files d ON p.con_id = d.con_id
   GROUP BY p.name, p.con_id
   ORDER BY p.con_id;

Cronograma típico

1. Fase de duplicação (a origem permanece online): 30 minutos a várias horas, dependendo do tamanho do banco de dados

2. Fase de validação (a origem permanece online): de horas a dias, conforme necessário

3. Fase de substituição (breve tempo de inatividade): minutos para redirecionar os aplicativos para o EC2

Etapas da instância de banco de dados do RDS Custom (origem):

1. Pausar a automação do Amazon RDS Custom

2. Verificar a arquitetura do banco de dados (não CDB ou CDB com PDBs)

3. Criar um arquivo de senha e um arquivo de parâmetro a partir do banco de dados de origem

4. Copiar o arquivo de senha e o arquivo de parâmetro para a instância do EC2 de destino

5. Verificar se o banco de dados de origem está sendo executado no modo de log de arquivamento

6. Configurar tnsnames.ora no servidor de banco de dados do RDS Custom

Etapas da instância de banco de dados do EC2 (destino):

1. Editar o arquivo de parâmetro para o EC2 (específico da arquitetura)

2. Configurar tnsnames.ora no EC2

3. Configurar o ambiente para a instância do EC2

4. Configurar o Oracle Listener no EC2

5. Iniciar o banco de dados no EC2 no estado NOMOUNT

Etapas de duplicação do RMAN:

1. Executar a duplicação ativa do RMAN

2. Abrir o banco de dados (e PDBs para multilocatário)

3. Configurar a abertura automática do PDB (somente multilocatário)

4. Remover usuários e objetos específicos do RDS Custom

5. Criar SPFILE e configurar a inicialização automática

6. Retomar a automação do Amazon RDS Custom na origem (se a mantiver ativa)

1. Atualizar nome do banco de dados: para multilocatário, altere todas as ocorrências de RDSCDB para ORCL

2. Converter caminhos do RDS Custom em caminhos do EC2: substitua /rdsdbdata/ por /u01/app/oracle/

3. Remover parâmetros específicos do RDS Custom

   • dg_broker_config_file1 e dg_broker_config_file2 (se presente, - indica a existência de uma réplica)

   • standby_file_management (se presente)

   • spfile (criaremos um novo SPFILE mais tarde)

   • Qualquer parâmetro log_archive_dest que aponte para destinos em espera (mantenha somente log_archive_dest_1 para arquivamento local)

4. Adicionar parâmetros de conversão de nome de arquivo (veja abaixo)

5. Ajustar os parâmetros de memória com base no tamanho da instância do EC2 (opcional, mas recomendado)

O processo de duplicação ativa do RMAN inclui várias fases:

1. Conexão aos bancos de dados de origem e de destino

2. Criação de um SPFILE da memória no destino

3. Restauração do arquivo de controle no destino

4. Montagem do banco de dados de destino

5. Cópia de todos os arquivos de dados da origem para o destino pela rede (a origem permanece online)

6. Recuperação do banco de dados de destino

7. Abertura do banco de dados de destino com RESETLOGS

1. Monitore a saída do RMAN:

   A sessão do RMAN exibirá informações detalhadas sobre o andamento, incluindo:

   • Alocação de canais

   • Andamento da cópia do arquivo de dados

   • Tempo estimado de conclusão

   • Bytes processados

   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00001 name=/rdsdbdata/db/ORCL_A/datafile/system01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/system01.dbf tag=TAG20260303T120000
   channel ORA_AUX_DISK_1: datafile copy complete, elapsed time: 00:05:23
   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00003 name=/rdsdbdata/db/ORCL_A/datafile/sysaux01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/sysaux01.dbf tag=TAG20260303T120000

   exemplo Resultado do exemplo:

   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00001 name=/rdsdbdata/db/ORCL_A/datafile/system01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/system01.dbf tag=TAG20260303T120000
   channel ORA_AUX_DISK_1: datafile copy complete, elapsed time: 00:05:23
   channel ORA_AUX_DISK_1: starting datafile copy
   input datafile file number=00003 name=/rdsdbdata/db/ORCL_A/datafile/sysaux01.dbf
   output file name=/u01/app/oracle/oradata/ORCL/datafile/sysaux01.dbf tag=TAG20260303T120000

2. Monitore operações de longa duração:

   exemplo Em uma sessão separada do SQL*Plus na instância do EC2 de destino:

   SQL> SELECT sid, serial#, opname, sofar, totalwork,
          ROUND(sofar/totalwork*100,2) pct_complete,
          time_remaining, elapsed_seconds
   FROM v$session_longops
   WHERE totalwork > 0 AND sofar <> totalwork
   ORDER BY start_time;

   Essa consulta mostra:

   • opname: nome da operação (por exemplo, “RMAN: restauração completa do arquivo de dados”)

   • sofar: blocos processados até agora

   • totalwork: total de blocos a serem processados

   • pct_complete: porcentagem concluída

   • time_remaining: estimativa de segundos restantes

   • elapsed_seconds: tempo decorrido até agora

3. Monitore os canais do RMAN:

   exemplo

   SQL> SELECT sid, serial#, context, sofar, totalwork,
          ROUND(sofar/totalwork*100,2) pct_complete
          FROM v$session_longops
   WHERE opname LIKE 'RMAN%'
          AND totalwork > 0
          AND sofar <> totalwork;

4. Verifique o log de alertas:

   exemplo Na instância do EC2 de destino, monitore o log de alertas em busca de erros ou avisos:

   tail -f $ORACLE_BASE/diag/rdbms/orcl/ORCL/trace/alert_ORCL.log

   Problemas comuns durante a duplicação do RMAN:

   • Tempo limite de rede

     RMAN-03009: failure of duplicate command on ORA_AUX_DISK_1 channel
     ORA-03135: connection lost contact

     Solução: aumente os valores de tempo limite da rede em sqlnet.ora nas duas instâncias:

     SQLNET.RECV_TIMEOUT=600
     SQLNET.SEND_TIMEOUT=600

   • Espaço insuficiente no destino

     RMAN-03009: failure of duplicate command
     ORA-19504: failed to create file "/u01/app/oracle/oradata/ORCL/datafile/users01.dbf"
     ORA-27040: file create error, unable to create file
     Linux-x86_64 Error: 28: No space left on device

     Solução: verifique o espaço disponível e adicione mais capacidade de volume do EBS:

     df -h /u01/app/oracle/oradata

   • Erros no arquivo de parâmetro

     RMAN-05021: this configuration cannot be used
     RMAN-06004: ORACLE error from auxiliary database: ORA-01261: Parameter db_create_file_dest destination string cannot be translated

     Solução: verifique se todos os diretórios no arquivo de parâmetro existem e têm as permissões adequadas.

   • Incompatibilidade do arquivo de senha

     RMAN-00571: ===========================================================
     RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
     RMAN-00571: ===========================================================
     RMAN-03002: failure of duplicate command at 03/03/2026 12:00:00
     RMAN-06136: ORACLE error from auxiliary database: ORA-01017: invalid username/password; logon denied

     Solução: o arquivo de senha no destino deve corresponder à origem e ter o nome correto (orapwORCL).

Etapas da instância de banco de dados do RDS Custom (principal):

1. Pausar a automação do Amazon RDS Custom

2. Verificar a arquitetura do banco de dados (não CDB ou CDB com PDBs)

3. Confirmar se o banco de dados principal está sendo executado no modo de log de arquivamento e FORCE_LOGGING está ativado

4. Criar um arquivo de senha

5. Executar um backup online do RMAN do banco de dados principal (ou usar a duplicação ativa)

6. Criar um arquivo de parâmetro do banco de dados de origem

7. Copiar os conjuntos de backup, o arquivo de parâmetro e o arquivo de senha para a instância do EC2 de destino

Etapas da instância de banco de dados do EC2 (em espera):

1. Copiar todos os arquivos da origem para a instância do EC2

2. Copiar o arquivo de senha para a instância do EC2

3. Editar o arquivo de parâmetro para o EC2 (específico da arquitetura)

4. Criar o arquivo de parâmetro do servidor a partir do arquivo de parâmetro

5. Restaurar arquivo de controle e banco de dados em espera

Etapas de configuração do Data Guard:

1. Configurar receptores Oracle nas duas instâncias

2. Configurar tnsnames.ora nas duas instâncias

3. Iniciar o agente do Oracle Data Guard nas duas instâncias (opcional, mas recomendado)

4. Ativar a configuração do Oracle Data Guard

5. Configurar fal_server e fal_client na instância em espera do EC2

6. Configurar os arquivos de log redo em espera nas duas instâncias

7. Recuperar a instância em espera

8. Executar a transição manual

9. Abrir o banco de dados (e PDBs para multilocatário)

10. Configurar a abertura automática do PDB (somente multilocatário)

11. Remover usuários e objetos específicos do RDS Custom

12. Criar SPFILE e configurar a inicialização automática

1. Atualizar nome do banco de dados: para multilocatário, altere todas as ocorrências de RDSCDB para ORCL

2. Alterar db_unique_name: de ORCL_A (ou RDSCDB_A) para ORCL_B

3. Converter caminhos do RDS Custom em caminhos do EC2: substitua /rdsdbdata/ por /u01/app/oracle/

4. Remover parâmetros específicos do RDS Custom

   • dg_broker_config_file1 e dg_broker_config_file2 (se estiver presente)

   • standby_file_management (se presente)

   • spfile (criaremos um novo SPFILE mais tarde)

   • Qualquer parâmetro log_archive_dest que aponte para destinos em espera

5. Ajustar os parâmetros de memória com base no tamanho da instância do EC2 (opcional, mas recomendado)

1. Monitore as estatísticas do Data Guard:

   -- Comprehensive Data Guard statistics
   SQL> SELECT name, value, unit, time_computed, datum_time
   FROM v$dataguard_stats
   ORDER BY name;

   Principais métricas a serem monitoradas:

   • atraso de transporte: diferença de tempo entre o momento em que o redo foi gerado no banco de dados principal e recebido no banco de dados em espera

   • atraso de aplicação: diferença de tempo entre o momento em que o redo foi gerado e aplicado no banco de dados em espera

   • taxa de aplicação: taxa na qual o redo está sendo aplicado (MB/s)

   • redo recebido: total de redos recebidos no banco de dados em espera

   • redo aplicado: total de redos aplicados no banco de dados em espera

2. Monitore o envio de logs de arquivos:

   No banco de dados principal (RDS Custom):

   -- Check archive log generation rate
   SQL> SELECT TO_CHAR(first_time, 'YYYY-MM-DD HH24') AS hour,
          COUNT(*) AS log_count,
          ROUND(SUM(blocks * block_size)/1024/1024/1024, 2) AS size_gb
   FROM v$archived_log
   WHERE first_time > SYSDATE - 1
   GROUP BY TO_CHAR(first_time, 'YYYY-MM-DD HH24')
   ORDER BY hour;
   
   -- Check archive log destination status
   SQL> SELECT dest_id, status, error, destination
   FROM v$archive_dest
   WHERE status != 'INACTIVE';

   No banco de dados em espera (EC2):

   -- Check archive log apply status
   SQL> SELECT sequence#, first_time, next_time, applied
   FROM v$archived_log
   WHERE applied = 'NO'
   ORDER BY sequence#;
   
   -- Check archive log gap
   SQL> SELECT thread#, low_sequence#, high_sequence#
   FROM v$archive_gap;

3. Monitore o processo gerenciado de recuperação:

   -- Check if managed recovery is running
   SQL> SELECT process, status, thread#, sequence#, block#, blocks
   FROM v$managed_standby
   WHERE process LIKE 'MRP%' OR process LIKE 'RFS%';
   
   -- Check recovery progress
   SQL> SELECT process, status, sequence#,
          TO_CHAR(timestamp, 'YYYY-MM-DD HH24:MI:SS') AS timestamp
   FROM v$managed_standby
   ORDER BY process;

4. Monitore a taxa de aplicação de redos para multilocatário:

   Para bancos de dados multilocatário, monitore a taxa de aplicação por PDB:

   -- Check redo apply rate per container
   SQL> SELECT con_id, name,
          ROUND(SUM(value)/1024/1024, 2) AS redo_applied_mb
   FROM v$con_sysstat cs, v$containers c
   WHERE cs.con_id = c.con_id
     AND cs.name = 'redo size'
   GROUP BY con_id, name
   ORDER BY con_id;

5. Monitore os logs redo em espera:

   -- Check standby redo log status
   SQL> SELECT group#, thread#, sequence#, bytes/1024/1024 AS size_mb, status
   FROM v$standby_log
   ORDER BY group#;
   
   -- Check if standby redo logs are being used
   SQL> SELECT group#, thread#, sequence#, status, archived
   FROM v$standby_log
   WHERE status = 'ACTIVE';

6. Estime a conclusão da sincronização:

   Calcule o tempo restante com base na taxa de aplicação:

   -- Calculate estimated time to catch up
   SQL> SELECT
          ROUND((SELECT value FROM v$dataguard_stats WHERE name = 'apply lag')/60, 2) AS lag_minutes,
          ROUND((SELECT value FROM v$dataguard_stats WHERE name = 'apply rate')/1024, 2) AS apply_rate_mbps,
          ROUND(
            (SELECT value FROM v$dataguard_stats WHERE name = 'apply lag') /
            NULLIF((SELECT value FROM v$dataguard_stats WHERE name = 'apply rate'), 0) / 60,
            2
          ) AS estimated_catchup_minutes
   FROM dual;

1. Verifique as versões do fuso horário:

   SELECT * FROM v$timezone_file;
   SELECT PROPERTY_NAME, PROPERTY_VALUE
   FROM database_properties
   WHERE PROPERTY_NAME LIKE '%DST%';

2. Como solução alternativa, defina a variável de ambiente do arquivo de fuso horário para corresponder ao que seu $ORACLE_HOME tem disponível:

   ls $ORACLE_HOME/oracore/zoneinfo/timezlrg_*.dat
   export ORA_TZFILE=$ORACLE_HOME/oracore/zoneinfo/timezone_40.dat

   Ajuste o número para corresponder à versão disponível em sua instalação.

3. Repita a entrega:

   sqlplus / as sysdba
   SQL> DROP USER RDSADMIN CASCADE;

1. Verifique a versão exata da RU na origem e no destino:

   -- On both source and target
   SQL> SELECT * FROM v$version;
   
   SQL> SELECT patch_id, patch_uid, version, action, status, description
   FROM dba_registry_sqlpatch
   ORDER BY action_time DESC;

2. Verifique o nível do patch de $ORACLE_HOME:

   # On both instances
   $ORACLE_HOME/OPatch/opatch lsinventory

3. Se as versões não coincidirem, alinhe-as antes da migração aplicando ou revertendo os patches conforme necessário.

4. Se você precisar continuar com RUs incompatíveis, execute o patch de dados após a migração:

   cd $ORACLE_HOME/OPatch
   ./datapatch -verbose

5. Verifique se há objetos inválidos e recompile:

   SQL> @?/rdbms/admin/utlrp.sql
   
   SQL> SELECT owner, object_type, COUNT(*)
   FROM dba_objects
   WHERE status = 'INVALID'
   GROUP BY owner, object_type;

1. Verifique se os grupos de segurança permitem a porta nos dois sentidos

2. Verifique iptables no EC2:

   sudo iptables -L INPUT -n -v

3. Adicione uma regra, se necessário:

   # Insert rule before the REJECT rule (typically position 5)
   sudo iptables -I INPUT 5 -p tcp --dport 1521 -j ACCEPT
   
   # For enhanced security, allow only from specific source IPs
   sudo iptables -I INPUT 5 -p tcp -s <RDS_Custom_IP> --dport 1521 -j ACCEPT
   
   # Save rules permanently
   sudo service iptables save

4. Teste de conectividade:

   telnet <EC2_instance_IP> 1521
   tnsping DB_SOURCE
   tnsping DB_TARGET

1. Verifique quais arquivos de dados estão faltando:

   SQL> SELECT name, status FROM v$datafile WHERE status != 'ONLINE';

2. Se os arquivos foram colocados no diretório errado, renomeie-os no arquivo de controle:

   SQL> ALTER DATABASE RENAME FILE '/wrong/path/datafile.dbf' TO '/correct/path/datafile.dbf';

3. Para evitar isso, sempre verifique os caminhos do arquivo de dados de origem com SELECT con_id, name FROM v$datafile ORDER BY con_id; antes de configurar o arquivo de parâmetro.

1. Force o registro do serviço:

   SQL> ALTER SYSTEM REGISTER;

2. Se os serviços ainda não aparecerem, verifique o parâmetro local_listener:

   SQL> SHOW PARAMETER local_listener;

   Ele deve apontar para o endereço correto do receptor. Se necessário, atualize-o:

   SQL> ALTER SYSTEM SET local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=<EC2_instance_IP>)(PORT=1521))';
   SQL> ALTER SYSTEM REGISTER;

3. Verifique com:

   lsnrctl services

1. Verifique se o banco de dados em espera está no modo MOUNT:

   SQL> SELECT status FROM v$instance;

2. Verifique se fal_server e fal_client estão configurados corretamente no banco de dados em espera:

   SQL> SHOW PARAMETER fal_server
   SQL> SHOW PARAMETER fal_client

3. Verifique a conectividade de rede:

   tnsping ORCL_A # or RDSCDB_A for multitenant

4. Verifique se o parâmetro log_archive_dest_2 no banco de dados principal aponta para o banco de dados em espera (se configurado manualmente sem o agente).

1. Verifique a taxa de aplicação:

   SQL> SELECT name, value, unit FROM v$dataguard_stats WHERE name IN ('apply rate', 'apply lag');

2. Aumente o paralelismo para a aplicação de redo (requer a licença ativa do Data Guard):

   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
   SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE PARALLEL 4 DISCONNECT FROM SESSION;

3. Verifique se não há restrições de recursos (CPU, E/S) na instância em espera.

1. Faça uma verificação cruzada e limpe as entradas de log de arquivamento desatualizadas:

   RMAN> CROSSCHECK ARCHIVELOG ALL;
   RMAN> DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;

2. Execute novamente apenas o backup do log de arquivamento:

   RMAN> RUN {
   SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
   BACKUP AS COMPRESSED BACKUPSET
   FILESPERSET 50
   FORMAT '/rdsdbdata/backup/arch_%U'
   ARCHIVELOG ALL;
   }

1. Backup final: faça um backup final da instância do RDS Custom para fins de arquivamento

   # Create final snapshot
   aws rds create-db-snapshot \
     --db-instance-identifier my-custom-instance \
     --db-snapshot-identifier my-custom-instance-final-snapshot \
     --region us-east-1

2. Documente a migração: atualize os runbooks e a documentação com a nova configuração do EC2

3. Exclua a instância do RDS Custom: use o console ou a CLI da AWS para excluir a instância

   # Delete RDS Custom instance without final snapshot (if already created above)
   aws rds delete-db-instance \
     --db-instance-identifier my-custom-instance \
     --skip-final-snapshot \
     --region us-east-1
   
   # Or create a final snapshot before deletion
   aws rds delete-db-instance \
     --db-instance-identifier my-custom-instance \
     --final-db-snapshot-identifier my-custom-instance-final-snapshot \
     --region us-east-1

4. Apague os recursos: remova instantâneos, grupos de parâmetros e grupos de opções associados, se não forem mais necessários

5. Atualize a documentação: garanta que toda a documentação operacional reflita a nova arquitetura baseada em EC2

1. Faça uma avaliação completa:

   Antes de iniciar a migração, faça uma avaliação abrangente do seu ambiente:

   • Inventário de banco de dados: documente todos os bancos de dados, tamanhos, arquiteturas (não CDB x multilocatário) e dependências

   • Dependências de aplicativo: identifique todos os aplicativos que se conectam ao banco de dados e os métodos de conexão

   • Linha de base de desempenho: capture métricas de desempenho (CPU, memória, E/S, rede) para comparação após a migração

   • Requisitos de backup e recuperação: documente o RPO (objetivo de ponto de recuperação) e o RTO (objetivo de tempo de recuperação)

   • Requisitos de conformidade: identifique os requisitos normativos ou de conformidade que possam afetar a migração

2. Escolha o tipo certo de instância do EC2:

   Selecione um tipo de instância do EC2 com base nas características do workload:

   Tipo de workload	Família de instâncias recomendada	Características principais
   OLTP geral	M6i, M6a, M7i	Computação, memória e rede balanceadas
   Consumo intensivo de memória	R6i, R6a, R7i, X2idn	Alta relação memória/CPU
   Uso intenso de computação	C6i, C6a, C7i	Alto desempenho da CPU
   Consumo intensivo de E/S	I4i, Im4gn	Alto armazenamento SSD NVMe local
   Workloads mistos	M5, M5a, M5n	Desempenho equilibrado e econômico

   Diretrizes de dimensionamento de instâncias:

   • Começar com a mesma classe da instância do RDS Custom

   • Monitorar a utilização de recursos durante uma migração de teste

   • Usar o AWS Compute Optimizer para obter recomendações

   • Planejar 20% a 30% de espaço livre para crescimento e picos de carga

3. Projete sua arquitetura de armazenamento:

   Tipos de volume do EBS:

   Tipo de volume	Caso de uso	desempenho	Custo
   gp3	Uso geral, a maioria dos workloads	Até 16.000 IOPS, 1.000 MB/s	Baixo
   io2 Block Express	Missão crítica, alto desempenho	Até 256.000 IOPS, 4.000 MB/s	Alto
   Io1	Bancos de dados de alta performance	Até 64.000 IOPS, 1.000 MB/s	Médio-alto
   gp2	Finalidade do legado	Até 16.000 IOPS	Baixo

   Recomendações de layout de armazenamento:

   # Recommended layout for production databases
         /u01/app/oracle          # Oracle software (50-100 GB, gp3)
         /u01/app/oracle/oradata  # Data files (sized for database, gp3 or io2)
         /u01/app/oracle/arch     # Archive logs (separate volume, gp3)
         /u01/app/oracle/backup   # Backups (separate volume, gp3, can be detached post-migration)

   Benefícios de volumes separados:

   • Alocação de IOPS independente

   • Gerenciamento de capacidade mais fácil

   • Estratégias simplificadas de backup e snapshot

   • Melhor isolamento de desempenho

4. Estabeleça um plano de reversão:

   Sempre tenha uma estratégia de reversão:

   • Manter a instância do RDS Custom em execução durante o período de validação (recomenda-se de 1 a 2 semanas)

   • Manter backups regulares da origem e do destino

   • Documentar procedimentos de reversão, incluindo alterações de string de conexão

   • Testar o processo de reversão em um ambiente que não seja de produção

   • Definir critérios de reversão (degradação do desempenho, inconsistência de dados, erros de aplicativos)

1. Cronometre sua migração:

   Escolha a janela de tempo ideal:

   • Períodos de baixo tráfego: fins de semana, feriados ou horários fora de pico

   • Janelas de manutenção: alinhe-se com a manutenção programada, se possível

   • Evite o final do mês/final do trimestre: esses períodos geralmente têm altos volumes de transações

   • Considere os fusos horários: para aplicativos globais, escolha um horário que minimize o impacto em todas as regiões

2. Plano de comunicação:

   Estabeleça uma comunicação clara:

   • Notificação às partes interessadas: informe todas as partes interessadas com pelo menos 2 semanas de antecedência

   • Equipes de aplicativos: coordene com as equipes de aplicativos as atualizações da string de conexão

   • Atualizações de status: forneça atualizações regulares durante a migração

   • Caminho de escalação: defina procedimentos claros de escalação de problemas

   • Comunicação pós-migração: confirme a conclusão bem-sucedida e quaisquer ações de acompanhamento

3. Pontos de verificação de validação:

   Implemente a validação em cada estágio:

   Validação pré-migração:

   -- Capture object counts
   SQL> SELECT object_type, COUNT(*) FROM dba_objects GROUP BY object_type ORDER BY object_type;
   
   -- Capture tablespace usage
   SQL> SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024, 2) AS size_gb
   FROM dba_data_files GROUP BY tablespace_name;
   
   -- Capture user counts
   SQL> SELECT COUNT(*) FROM dba_users;
   
   -- For multitenant, capture PDB information
   SQL> SELECT con_id, name, open_mode FROM v$pdbs;

   Validação pós-migração:

   -- Verify object counts match
   SQL> SELECT object_type, COUNT(*) FROM dba_objects GROUP BY object_type ORDER BY object_type;
   
   -- Verify no invalid objects
   SQL> SELECT owner, object_type, object_name FROM dba_objects WHERE status = 'INVALID';
   
   -- Verify tablespace usage
   SQL> SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024, 2) AS size_gb
   FROM dba_data_files GROUP BY tablespace_name;
   
   -- Verify database size matches
   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files;
   
   -- For multitenant, verify all PDBs are open
   SQL> SELECT con_id, name, open_mode FROM v$pdbs;

4. Validação de desempenho:

   Compare as métricas de desempenho antes e depois da migração:

   -- Capture AWR snapshots before migration (on RDS Custom)
   SQL> EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;
   
   -- After migration (on EC2), compare metrics
   SQL> SELECT snap_id, begin_interval_time, end_interval_time
   FROM dba_hist_snapshot
   ORDER BY snap_id DESC
   FETCH FIRST 10 ROWS ONLY;
   
   -- Generate AWR report for comparison
   SQL> @?/rdbms/admin/awrrpt.sql

   Principais métricas a serem comparadas:

   • Média de sessões ativas

   • Tempo do banco de dados por transação

   • Leituras físicas por segundo

   • Leituras lógicas por segundo

   • Tamanho de redo por segundo

   • Chamadas de usuário por segundo

   • Tempo de análise por execução

1. Após a migração, otimize o desempenho do banco de dados:

   1. Ajuste de desempenho do banco de dados:

      Colete estatísticas:

      -- Gather dictionary statistics
      SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
      
      -- Gather fixed object statistics
      SQL> EXEC DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
      
      -- Gather schema statistics
      SQL> EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SCHEMA_NAME', cascade=>TRUE);
      
      -- For multitenant, gather statistics for each PDB
      SQL> ALTER SESSION SET CONTAINER = PDB_NAME;
      SQL> EXEC DBMS_STATS.GATHER_DATABASE_STATS(cascade=>TRUE);

      Otimize os parâmetros de memória:

      -- Enable Automatic Memory Management (if not already enabled)
      SQL> ALTER SYSTEM SET MEMORY_TARGET = 24G SCOPE=SPFILE;
      SQL> ALTER SYSTEM SET MEMORY_MAX_TARGET = 28G SCOPE=SPFILE;
      SQL> SHUTDOWN IMMEDIATE;
      SQL> STARTUP;
      
      -- Or use Automatic Shared Memory Management
      SQL> ALTER SYSTEM SET SGA_TARGET = 16G SCOPE=SPFILE;
      SQL> ALTER SYSTEM SET PGA_AGGREGATE_TARGET = 8G SCOPE=SPFILE;

      Configure o cache de resultados:

      -- Enable result cache for frequently accessed queries
      SQL> ALTER SYSTEM SET RESULT_CACHE_MAX_SIZE = 1G;
      SQL> ALTER SYSTEM SET RESULT_CACHE_MODE = MANUAL;

   2. Otimização de armazenamento:

      Habilite a compactação:

      -- For tables with infrequent updates
      ALTER TABLE large_table MOVE COMPRESS FOR OLTP;
      
      -- For archive/historical data
      ALTER TABLE archive_table MOVE COMPRESS FOR ARCHIVE HIGH;
      
      -- Rebuild indexes after compression
      ALTER INDEX index_name REBUILD ONLINE;

      Implemente o particionamento:

      -- For large tables, consider partitioning
      -- Example: Range partitioning by date
      CREATE TABLE sales_partitioned (
          sale_id NUMBER,
          sale_date DATE,
          amount NUMBER
      )
      PARTITION BY RANGE (sale_date) (
          PARTITION sales_2024 VALUES LESS THAN (TO_DATE('2025-01-01', 'YYYY-MM-DD')),
          PARTITION sales_2025 VALUES LESS THAN (TO_DATE('2026-01-01', 'YYYY-MM-DD')),
          PARTITION sales_2026 VALUES LESS THAN (MAXVALUE)
      );

   3. Implemente monitoramento e alertas:

      Métricas personalizadas do CloudWatch:

      Crie um script para publicar métricas do Oracle no CloudWatch:

      #!/bin/bash
      # publish_oracle_metrics.sh
      
      INSTANCE_ID=$(ec2-metadata --instance-id | cut -d " " -f 2)
      REGION=$(ec2-metadata --availability-zone | cut -d " " -f 2 | sed 's/[a-z]$//')
      
      # Get tablespace usage
      TABLESPACE_USAGE=$(sqlplus -s / as sysdba << EOF
      SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING OFF ECHO OFF
      SELECT ROUND(MAX(percent_used), 2)
      FROM (
           SELECT tablespace_name,
                  ROUND((used_space/tablespace_size)*100, 2) AS percent_used
           FROM dba_tablespace_usage_metrics
      );
      EXIT;
      EOF
      )
      
      # Publish to CloudWatch
      aws cloudwatch put-metric-data \
        --region $REGION \
        --namespace "Oracle/Database" \
        --metric-name "TablespaceUsage" \
        --value $TABLESPACE_USAGE \
        --unit Percent \
        --dimensions InstanceId=$INSTANCE_ID,Database=ORCL
      # Add more metrics as needed (sessions, wait events, etc.)

      Defina alarmes do CloudWatch:

      # Create alarm for high tablespace usage
      aws cloudwatch put-metric-alarm \
        --alarm-name oracle-high-tablespace-usage \
        --alarm-description "Alert when tablespace usage exceeds 85%" \
        --metric-name TablespaceUsage \
        --namespace Oracle/Database \
        --statistic Maximum \
        --period 300 \
        --evaluation-periods 2 \
        --threshold 85 \
        --comparison-operator GreaterThanThreshold \
        --alarm-actions arn:aws:sns:region:account-id:topic-name

   4. Fortalecimento da segurança:

      Segurança do banco de dados:

      -- Enforce password complexity
      ALTER PROFILE DEFAULT LIMIT
          PASSWORD_LIFE_TIME 90
          PASSWORD_GRACE_TIME 7
          PASSWORD_REUSE_TIME 365
          PASSWORD_REUSE_MAX 5
          FAILED_LOGIN_ATTEMPTS 5
          PASSWORD_LOCK_TIME 1;
      
      -- Enable audit
      ALTER SYSTEM SET AUDIT_TRAIL = DB, EXTENDED SCOPE=SPFILE;
      SHUTDOWN IMMEDIATE;
      STARTUP;
      
      -- Audit critical operations
      AUDIT ALL ON SYS.AUD$ BY ACCESS;
      AUDIT CREATE USER BY ACCESS;
      AUDIT DROP USER BY ACCESS;
      AUDIT ALTER USER BY ACCESS;
      AUDIT CREATE SESSION BY ACCESS WHENEVER NOT SUCCESSFUL;

      Segurança de rede:

      # Restrict SSH access
      sudo vi /etc/ssh/sshd_config
      # Set: PermitRootLogin no
      # Set: PasswordAuthentication no
      
      # Configure firewall
      sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.0.0/8" port port="1521" protocol="tcp" accept'
      sudo firewall-cmd --reload
      
      # Enable Oracle Native Network Encryption
      # Edit sqlnet.ora
      SQLNET.ENCRYPTION_SERVER = REQUIRED
      SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)
      SQLNET.CRYPTO_CHECKSUM_SERVER = REQUIRED
      SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)

1. Estratégia de backup e recuperação:

   Implemente uma estratégia abrangente de backup:

   #!/bin/bash
   # rman_backup.sh - Daily incremental backup script
   
   export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
   export ORACLE_SID=ORCL
   export PATH=$ORACLE_HOME/bin:$PATH
   
   # Backup to local disk
   rman target / << EOF
   RUN {
       ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/u01/app/oracle/backup/inc_%U';
       BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;
       DELETE NOPROMPT OBSOLETE;
       CROSSCHECK BACKUP;
       DELETE NOPROMPT EXPIRED BACKUP;
   }
   EXIT;
   EOF
   
   # Copy backups to S3
   aws s3 sync /u01/app/oracle/backup/ s3://my-oracle-backups/$(date +%Y%m%d)/ \
       --storage-class STANDARD_IA \
       --exclude "*" \
       --include "inc_*" \
       --include "arch_*"
   
   # Clean up local backups older than 7 days
   find /u01/app/oracle/backup/ -name "inc_*" -mtime +7 -delete
   find /u01/app/oracle/backup/ -name "arch_*" -mtime +7 -delete

   Agende backups com o cron:

   # Edit crontab
   crontab -e
   
   # Add backup schedule
   # Full backup on Sunday at 2 AM
   0 2 * * 0 /home/oracle/scripts/rman_full_backup.sh >> /home/oracle/logs/backup_full.log 2>&1
   
   # Incremental backup Monday-Saturday at 2 AM
   0 2 * * 1-6 /home/oracle/scripts/rman_incremental_backup.sh >> /home/oracle/logs/backup_inc.log 2>&1
   
   # Archive log backup every 4 hours
   0 */4 * * * /home/oracle/scripts/rman_archivelog_backup.sh >> /home/oracle/logs/backup_arch.log 2>&1

1. Avaliar a arquitetura de banco de dados (não CDB ou multilocatário)

2. Escolher a opção de migração apropriada com base em seus requisitos de complexidade e tolerância ao tempo de inatividade

3. Concluir todas as etapas de pré-requisito, incluindo a configuração da instância do EC2 e a configuração da rede

4. Seguir as etapas detalhadas de migração para a opção escolhida

5. Realizar validação e testes completos

6. Concluir tarefas pós-migração para garantir a prontidão para a produção

7. Desativar a instância do RDS Custom após a validação bem-sucedida