# Fim do suporte do RDS Custom para Oracle
<a name="RDS-Custom-for-Oracle-end-of-support"></a>

**nota**  
Aviso de fim do suporte: em 31 de março de 2027, a AWS encerrará o suporte para o Amazon RDS Custom para Oracle. Depois de 31 de março de 2027, você não poderá mais acessar o console nem os recursos do RDS Custom para Oracle. Para obter mais informações, consulte [Fim do suporte do RDS Custom para Oracle](#RDS-Custom-for-Oracle-end-of-support).

## Visão geral
<a name="RDS-Custom-for-Oracle-end-of-support-overview"></a>

Após uma análise cuidadosa, a AWS tomou a decisão de descontinuar o serviço Amazon RDS Custom para Oracle. O serviço será descontinuado a partir de **31 de março de 2027**. Essa orientação prescritiva fornece estratégias de migração detalhadas para ajudar você a migrar do RDS Custom para Oracle para bancos de dados Oracle autogerenciados no Amazon Elastic Compute Cloud (Amazon EC2).

### Cronogramas principais
<a name="RDS-Custom-for-Oracle-end-of-support-key_timelines"></a>
+ **De 31 de março de 2026 a 31 de março de 2027**: recomendamos que você migre do RDS Custom para Oracle para executar o Oracle no EC2. Durante esse período, você pode continuar usando o RDS Custom para Oracle com os recursos e o suporte existentes.
+ **Após 31 de março de 2027**: você não poderá mais usar o serviço RDS Custom para Oracle.

### Público-alvo
<a name="RDS-Custom-for-Oracle-end-of-support-target_audience"></a>

Essa orientação se destina a:
+ Administradores de banco de dados responsáveis pelas migrações de bancos de dados Oracle
+ Arquitetos de nuvem que planejam estratégias de migração
+ Engenheiros de DevOps que gerenciam a infraestrutura de banco de dados
+ Gerentes de TI que supervisionam o processo de migração

### Pré-requisitos
<a name="RDS-Custom-for-Oracle-end-of-support-prerequisites"></a>

Antes de começar, verifique se você tem:
+ Uma instância ativa do Amazon RDS Custom para Oracle que executa o Oracle 19c Enterprise Edition
+ Permissões apropriadas do AWS Identity and Access Management (IAM) para criar e gerenciar instâncias do EC2
+ Compreensão da sua arquitetura de banco de dados (não CDB ou CDB multilocatário com PDBs)
+ Planejamento de conectividade de rede entre as instâncias de origem e de destino
+ Estratégia de backup e recuperação para sua migração

## Opções de migração
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options"></a>

Como parte do processo de migração, você pode escolher uma das duas opções de migração com base nos requisitos comerciais e no caso de uso:

### Opção 1: duplicação ativa do RMAN (migração online/offline)
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-RMAN"></a>

**Mais adequado para**
+ Workloads que podem permitir o tempo de inatividade planejado durante a substituição final
+ Requisitos de migração mais simples com menos peças móveis
+ Bancos de dados para os quais você deseja uma migração simples e única
+ Cenários em que você não precisa de sincronização contínua antes da substituição

**Características principais**
+ **Tempo de inatividade**: tempo de inatividade mínimo durante a substituição final (o banco de dados permanece online durante a duplicação, breve tempo de inatividade para a substituição final)
+ **Complexidade**: menor complexidade com a duplicação direta do banco de dados
+ **Duração**: o tempo de migração depende do tamanho do banco de dados e da largura de banda da rede
+ **Fallback**: requer a manutenção do banco de dados de origem até que a validação seja concluída
+ **Capacidade online**: o banco de dados de origem permanece online e acessível durante o processo de duplicação

**Abordagem de migração:** a duplicação ativa do RMAN cria uma cópia exata do banco de dados de origem no destino copiando os arquivos do banco de dados de origem ativo e em execução pela rede. O banco de dados de origem permanece online e acessível aos aplicativos durante o processo de duplicação. Para bancos de dados multilocatário, o RMAN duplica automaticamente todo o CDB, incluindo`CDB$ROOT`, `PDB$SEED` e todos os bancos de dados conectáveis em uma única operação. Somente uma breve janela de substituição é necessária para redirecionar os aplicativos para a nova instância do EC2.

### Opção 2: Oracle Data Guard (migração online)
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-Oracle-Data-Guard"></a>

**Mais adequado para**
+ Workloads de produção que exigem o tempo de inatividade mínimo
+ Bancos de dados essenciais que devem permanecer disponíveis
+ Cenários em que você precisa de sincronização contínua antes da substituição
+ Migrações que exigem capacidade de fallback integrada

**Características principais**
+ **Tempo de inatividade**: tempo de inatividade quase zero (segundos a minutos para a transição)
+ **Complexidade**: maior complexidade com a configuração do Data Guard
+ **Duração**: tempo de configuração inicial mais sincronização contínua até a transição
+ **Fallback**: capacidade de fallback integrada, mantendo a origem em espera

**Abordagem de migração:** o Oracle Data Guard mantém um banco de dados em espera sincronizado, enviando e aplicando continuamente logs redo do banco de dados principal. Quando estiver tudo pronto para concluir a migração, você executa uma transição que promove o modo de espera do EC2 para o banco de dados principal com o tempo de inatividade mínimo. Para bancos de dados multilocatário, o Data Guard protege automaticamente todo o CDB, incluindo todos os PDBs.

 **Matriz de decisão** 

Use a matriz a seguir para ajudar a escolher a opção de migração apropriada:


|  **Aspecto**  |  **Duplicação ativa do RMAN**  |  **Oracle Data Guard**  | 
| --- | --- | --- | 
| **Disponibilidade do banco de dados de origem** | Online durante a duplicação | Online durante todo o processo | 
| **Tempo de inatividade aceitável** | De minutos a horas (substituição final) | De segundos a minutos (transição) | 
| **Complexidade da migração** | Menor | Mais alto | 
| **Sincronização contínua** | Não | Sim | 
| **Capacidade de fallback** | Manual (mantenha a origem) | Integrado (automático) | 
| **Teste antes da substituição** | Limitado | Teste completo possível | 
| **Requisito de largura de banda da rede** | Alto durante a duplicação | Moderado (contínuo) | 
| **Melhor para** | A maioria das migrações, dev/teste, substituição planejada | Produção, missão crítica, tempo de inatividade quase zero | 

### Considerações sobre a arquitetura
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-architecture-considerations"></a>

As duas opções de migração oferecem suporte a duas arquiteturas de banco de dados Oracle:

 **Não CDB** 

Bancos de dados Oracle tradicionais de instância única sem a arquitetura multilocatário. Esses bancos de dados:
+ Têm uma única instância de banco de dados
+ Não usam bancos de dados conectáveis (PDBs)
+ São mais simples de gerenciar e migrar
+ Normalmente chamados de ORCL no RDS Custom para Oracle

 **Multilocatário (CDB com PDBs)** 

Bancos de dados de contêiner (CDB) que hospedam vários bancos de dados conectáveis (PDBs), introduzidos no Oracle 12c. Esses bancos de dados:
+ Têm um banco de dados de contêiner (CDB) com `CDB$ROOT` e `PDB$SEED`
+ Hospedam um ou mais bancos de dados conectáveis (PDBs)
+ Fornecem consolidação de banco de dados e isolamento de recursos
+ Normalmente chamados de RDSCDB no RDS Custom para Oracle
+ Usam o Oracle Managed Files (OMF) com subdiretórios baseados em GUID para arquivos de dados do PDB

**Observação importante para migrações multilocatário**: o banco de dados de destino será renomeado para ORCL durante o processo de migração (origem: RDSCDB → destino: ORCL). Isso simplifica a configuração de destino e se alinha às convenções de nomenclatura padrão.

 **Principais diferenças na abordagem de migração** 


|  **Aspecto**  |  **Não CDB**  |  **Multilocatário (CDB com PDBs)**  | 
| --- | --- | --- | 
| **Escopo da migração** | Banco de dados único | CDB inteiro com todos os PDBs | 
| **Estado de pós-migração**  | Banco de dados aberto com READ WRITE | CDB aberto com READ WRITE; PDBs no estado MOUNTED | 
| **Gerenciamento de PDB** | N/D | É necessário abrir PDBs e configurar a abertura automática | 
| **Limpeza** | Banco de dados único | CDB$ROOT (em cascata para PDBs); lidar com usuários comuns de C\#\# | 
| **Conexões de aplicativo** | Serviço de banco de dados | Serviços de PDB (não CDB) | 
| **Arquivo de parâmetro** | Parâmetros padrão | Requer enable\_pluggable\_database=TRUE | 
| **Complexidade** | Menor | Maior devido a vários contêineres | 

## Pré-requisitos comuns para as duas opções de migração
<a name="RDS-Custom-for-Oracle-end-of-support-common-prerequisites"></a>

Antes de começar qualquer opção de migração, conclua estas etapas pré-requisitos:

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.

1. 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

   1. 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

1. 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](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).

   1. 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

   1. 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.

1. 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

1. Criar uma estrutura de diretórios no EC2

   A estrutura do diretório depende da arquitetura do banco de dados:  
**Example 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
   ```  
**Example 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.

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

Antes de iniciar a migração, verifique 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:  
**Example**  

   ```
   # 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
   ```

1. Conecte-se ao banco de dados e verifique a arquitetura:  
**Example**  

   ```
   sqlplus / as sysdba
   SQL> SELECT name, cdb, open_mode, log_mode FROM v$database;
   ```  
**Example Para não CDB, saída esperada**  

   ```
   NAME CDB OPEN_MODE                 LOG_MODE
   --------- --- -------------------- ------------
   ORCL NO  READ  WRITE               ARCHIVELOG
   ```  
**Example Para multilocatário (CDB), saída esperada:**  

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

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

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

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

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

1. Verifique o tamanho total do banco de dados:  
**Example Para não CDB:**  

   ```
   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files;
   ```  
**Example 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;
   ```

## Opção 1: migração física usando a duplicação ativa do RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1"></a>

**Topics**
+ [Quando usar a duplicação ativa do RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-when-to-use)
+ [Visão geral da duplicação ativa do RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-overview)
+ [Fluxo de trabalho de migração para duplicação ativa do RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-migration-workflow)
+ [Etapa 1: pausar a automação do Amazon RDS Custom](#RDS-Custom-for-Oracle-end-of-support-option-1-step-1)
+ [Etapa 2: criar arquivos de senha e parâmetro](#RDS-Custom-for-Oracle-end-of-support-option-1-step-2)
+ [Etapa 3: transferir arquivos para o EC2](#RDS-Custom-for-Oracle-end-of-support-option-1-step-3)
+ [Etapa 4: editar arquivo de parâmetro no EC2](#RDS-Custom-for-Oracle-end-of-support-option-1-step-4)
+ [Etapa 5: configurar o TNS e o receptor](#RDS-Custom-for-Oracle-end-of-support-option-1-step-5)
+ [Etapa 6: iniciar o banco de dados em `NOMOUNT` no EC2](#RDS-Custom-for-Oracle-end-of-support-option-1-step-6)
+ [Etapa 7: executar a duplicação ativa do RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-step-7)
+ [Etapa 8: abrir PDBs (somente multilocatário)](#RDS-Custom-for-Oracle-end-of-support-option-1-step-8)
+ [Etapa 9: remover objetos do RDS Custom](#RDS-Custom-for-Oracle-end-of-support-option-1-step-9)
+ [Etapa 10: configurar a inicialização automática](#RDS-Custom-for-Oracle-end-of-support-option-1-step-10)
+ [Etapa 11: validação final](#RDS-Custom-for-Oracle-end-of-support-option-1-step-11)

Esta seção fornece etapas detalhadas para migrar seu banco de dados Oracle do RDS Custom para Oracle para o EC2 usando a duplicação ativa do RMAN. Esse método é duplicado de um banco de dados ativo e em execução, mantendo a origem online e acessível durante o processo de migração.

### Quando usar a duplicação ativa do RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-when-to-use"></a>

Escolha a duplicação ativa do RMAN quando:
+ Você quiser manter o banco de dados de origem online e acessível durante a migração
+ Você puder pagar uma breve janela de substituição para o redirecionamento final do aplicativo
+ Você quiser um processo de migração simples com menos partes móveis
+ O tamanho do banco de dados e a largura de banda da rede permitirem um tempo de duplicação razoável
+ Não for necessário sincronizar continuamente antes da substituição
+ Você estiver migrando bancos de dados de produção, desenvolvimento ou teste

### Visão geral da duplicação ativa do RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-overview"></a>

A duplicação ativa do RMAN não requer um backup nem a desativação do banco de dados de origem. Ela duplica o banco de dados de origem ativo e em execução para o destino copiando os arquivos do banco de dados pela rede enquanto a origem permanece online e acessível aos aplicativos.

**Principais vantagens:**
+ **A origem permanece online**: os aplicativos podem continuar acessando o banco de dados de origem durante a duplicação
+ **Sem necessidade de backup**: elimina a necessidade de armazenamento de backup intermediário
+ **Transferência direta de rede**: os arquivos do banco de dados são copiados diretamente da origem para o destino
+ **Consistência automática**: o RMAN garante que o banco de dados duplicado seja consistente
+ **Operação única**: para multilocatário, duplica o CDB inteiro, incluindo todos os PDBs em uma operação

O processo de duplicação cria uma cópia exata do banco de dados de origem no destino, incluindo todos os arquivos de dados, arquivos de controle e logs redo. O banco de dados de origem continua atendendo às solicitações de aplicativo durante todo o processo de duplicação. Somente uma breve janela de substituição é necessária no final para redirecionar os aplicativos da origem para o destino.

**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

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

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

### Fluxo de trabalho de migração para duplicação ativa do RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-migration-workflow"></a>

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

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

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

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

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

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

1. 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)

1. Configurar tnsnames.ora no EC2

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

1. Configurar o Oracle Listener no EC2

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

**Etapas de duplicação do RMAN:**

1. Executar a duplicação ativa do RMAN

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

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

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

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

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

### Etapa 1: pausar a automação do Amazon RDS Custom
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-1"></a>

Pause o modo de automação em sua instância do RDS Custom antes de prosseguir com as etapas de migração para garantir que a automação não interfira na atividade do RMAN. O parâmetro --resume-full-automation-mode-minute (240 minutos = 4 horas neste exemplo) deve ser ajustado com base no tamanho do banco de dados e no tempo de duplicação esperado.

**Importante**: pausar a automação não afeta a disponibilidade do banco de dados. O banco de dados permanece online e acessível aos aplicativos durante o processo de duplicação.

**Example**  

```
aws rds modify-db-instance \
--db-instance-identifier my-custom-instance \
--automation-mode all-paused \
--resume-full-automation-mode-minute 240 \
--region us-east-1 
--query 'DBInstances[0].AutomationMode'
```

Valide o status da automação:

**Example**  

```
aws ds describe-db-instances \
--db-instance-identifier my-custom-instance \
--region us-east-1 \
--query 'DBInstances[0].AutomationMode'
```

Saída esperada: "`all-paused`"

### Etapa 2: criar arquivos de senha e parâmetro
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-2"></a>

Crie um arquivo de senha usando `orapwd`. Recupere a senha SYS do AWS Secrets Manager (armazenada durante a criação da instância do RDS Custom).

**Example**  

```
# Non-CDB
$ORACLE_HOME/bin/orapwd file=/rdsdbdata/config/orapwORCL password={{<SYS_PASSWORD>}} entries=10
# Multitenant
$ORACLE_HOME/bin/orapwd file=/rdsdbdata/config/orapwRDSCDB password={{<SYS_PASSWORD>}} entries=10
```

Crie um arquivo de parâmetro do banco de dados de origem:

**Example**  

```
sqlplus / as sysdba
SQL> CREATE PFILE='/tmp/initORCL.ora' FROM SPFILE; -- Non-CDB
SQL> CREATE PFILE='/tmp/initRDSCDB.ora' FROM SPFILE; -- Multitenant
```

O arquivo de parâmetro gerado conterá caminhos e parâmetros específicos do RDS Custom. Para multilocatário, os principais parâmetros incluem:
+ `enable_pluggable_database` = `TRUE` (crítico para multilocatário)
+ `noncdb_compatible` = `TRUE` (para compatibilidade com versões anteriores)
+ Caminhos de arquivo de dados para `CDB$ROOT`, `PDB$SEED` e todos os PDBs
+ `db_create_file_dest` e `db_create_online_log_dest_1` para OMF

### Etapa 3: transferir arquivos para o EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-3"></a>

Escolha seu método preferido de transferência de arquivos. Esta orientação usa o Amazon S3 como exemplos.

 **Usar o Amazon S3:** 

#### Usando o Amazon S3:
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-3-ec2"></a>

**Example Para não CDB:**  

```
# Copy files to Amazon S3 from the RDS Custom instance
aws s3 cp /tmp/initORCL.ora s3://{{<YOUR_BUCKET>}}/
aws s3 cp /rdsdbdata/config/orapwORCL s3://{{<YOUR_BUCKET>}}/
# On EC2, download files
aws s3 cp s3://{{<YOUR_BUCKET>}}/initORCL.ora $ORACLE_HOME/dbs/
aws s3 cp s3://{{<YOUR_BUCKET>}}/orapwORCL $ORACLE_HOME/dbs/
```

**Example Para multilocatário**  

```
# Copy files to Amazon S3 from the RDS Custom instance
aws s3 cp /tmp/initRDSCDB.ora s3://{{<YOUR_BUCKET>}}/
aws s3 cp /rdsdbdata/config/orapwRDSCDB s3://{{<YOUR_BUCKET>}}/
# On EC2, download and rename files to use ORCL naming
aws s3 cp s3://{{<YOUR_BUCKET>}}/initRDSCDB.ora $ORACLE_HOME/dbs/initORCL.ora
aws s3 cp s3://{{<YOUR_BUCKET>}}/orapwRDSCDB $ORACLE_HOME/dbs/orapwORCL
```

Valide os arquivos no EC2:

**Example**  

```
ls -l $ORACLE_HOME/dbs/initORCL.ora
ls -l $ORACLE_HOME/dbs/orapwORCL
```

### Etapa 4: editar arquivo de parâmetro no EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-4"></a>

O arquivo de parâmetro requer uma edição cuidadosa para garantir a migração bem-sucedida. Essa é uma das etapas mais importantes no processo de migração.

Edite `$ORACLE_HOME/dbs/initORCL.ora` na instância do EC2 e faça essas alterações essenciais:

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

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

1. 

**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)

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

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

**Compreensão dos parâmetros de conversão de nome de arquivo:** 

Os parâmetros `DB_FILE_NAME_CONVERT` e `LOG_FILE_NAME_CONVERT` são essenciais para a duplicação do RMAN. Eles dizem ao RMAN como mapear os caminhos do arquivo de origem para os caminhos do arquivo de destino durante o processo de duplicação. Sem esses parâmetros, o RMAN tentará criar arquivos nos mesmos caminhos da origem, o que falhará no EC2.

**Considerações importantes:**
+ Cada parâmetro aceita pares de cadeias de caracteres: caminho de origem seguido pelo caminho de destino
+ Vários pares podem ser especificados em um único parâmetro
+ Para multilocatário, você deve mapear caminhos para `CDB$ROOT`, `PDB$SEED` e todos os PDBs
+ A ordem dos pares é importante: o RMAN os processa na ordem especificada
+ Os caminhos diferenciam maiúsculas de minúsculas e devem coincidir exatamente

**Mapeamentos de caminho:**


**Não CDB:**  

|  **Caminho personalizado do RDS**  |  **Caminho do EC2**  |  **Descrição**  | 
| --- | --- | --- | 
| /rdsdbbin | /u01/app/oracle | Base Oracle | 
| /rdsdbdata/db/ORCL\_A/datafile/ | /u01/app/oracle/oradata/ORCL/datafile/ | Arquivos de dados | 
| /rdsdbdata/db/ORCL\_A/controlfile/ | /u01/app/oracle/oradata/ORCL/controlfile/ | Arquivos de controle | 
| /rdsdbdata/db/ORCL\_A/onlinelog/ | /u01/app/oracle/oradata/ORCL/onlinelog/ | Logs redo online | 
| /rdsdbdata/db/ORCL\_A/arch/ | /u01/app/oracle/oradata/ORCL/arch/ | Arquivar logs | 
| /rdsdbdata/admin/ORCL/adump | /u01/app/oracle/admin/ORCL/adump | Despejo de auditoria | 
| /rdsdbdata/log | /u01/app/oracle | Destino de diagnóstico | 


**Multilocatário**  

|  **Caminho personalizado do RDS**  |  **Caminho do EC2**  |  **Descrição**  | 
| --- | --- | --- | 
| /rdsdbbin | /u01/app/oracle | Base Oracle | 
| /rdsdbdata/db/cdb/RDSCDB/datafile/ | /u01/app/oracle/oradata/ORCL/cdb/datafile/ | Arquivos de dados raiz do CDB | 
| /rdsdbdata/db/cdb/pdbseed/ | /u01/app/oracle/oradata/ORCL/pdbseed/datafile/ | Arquivos de dados PDB$SEED | 
| /rdsdbdata/db/pdb/RDSCDB\_A/ | /u01/app/oracle/oradata/ORCL/pdb/datafile/ | Arquivos de dados PDB (OMF com GUID) | 
| /rdsdbdata/db/cdb/RDSCDB\_A/controlfile/ | /u01/app/oracle/oradata/ORCL/controlfile/ | Arquivos de controle | 
| /rdsdbdata/db/cdb/RDSCDB\_A/onlinelog/ | /u01/app/oracle/oradata/ORCL/onlinelog/ | Logs redo online | 
| /rdsdbdata/db/cdb/RDSCDB\_A/arch/redolog | /u01/app/oracle/oradata/ORCL/arch/ | Arquivar logs | 
| /rdsdbdata/admin/RDSCDB/adump | /u01/app/oracle/admin/ORCL/adump | Despejo de auditoria | 
| /rdsdbdata/log | /u01/app/oracle | Destino de diagnóstico | 

**Adicione parâmetros de conversão:**

**Example Não CDB:**  

```
*.DB_FILE_NAME_CONVERT='/rdsdbdata/db/ORCL_A/datafile/','/u01/app/oracle/oradata/ORCL/datafile/'
*.LOG_FILE_NAME_CONVERT='/rdsdbdata/db/ORCL_A/onlinelog/','/u01/app/oracle/oradata/ORCL/onlinelog/'
```

**Example **Multilocatário** (deve incluir mapeamentos para a raiz do CDB, `PDB$SEED`, e todos os caminhos do PDB):**  

```
*.DB_FILE_NAME_CONVERT='/rdsdbdata/db/cdb/RDSCDB/datafile/','/u01/app/oracle/oradata/ORCL/cdb/datafile/','/rdsdbdata/db/cdb/pdbseed/','/u01/app/oracle/oradata/ORCL/pdbseed/datafile/','/rdsdbdata/db/pdb/RDSCDB_A/','/u01/app/oracle/oradata/ORCL/pdb/datafile/'
 *.LOG_FILE_NAME_CONVERT='/rdsdbdata/db/cdb/RDSCDB_A/onlinelog/','/u01/app/oracle/oradata/ORCL/onlinelog/'
```

**Importante**: para multilocatário, `enable_pluggable_database` = `TRUE` deve estar presente no arquivo de parâmetro. O RDS Custom usa OMF para arquivos de dados PDB com subdiretórios baseados em GUID - o mapeamento de caminhos trata isso automaticamente.

 **Arquivos de parâmetro de exemplo completos:** 

**Example Exemplo de arquivo de parâmetro não CDB (`initORCL.ora`):**  

```
ORCL.__data_transfer_cache_size=0
ORCL.__db_cache_size=6039797760
ORCL.__inmemory_ext_roarea=0
ORCL.__inmemory_ext_rwarea=0
ORCL.__java_pool_size=0
ORCL.__large_pool_size=33554432
ORCL.__oracle_base='/u01/app/oracle'
ORCL.__pga_aggregate_target=4966055936
ORCL.__sga_target=7449083904
ORCL.__shared_io_pool_size=134217728
ORCL.__shared_pool_size=1207959552
ORCL.__streams_pool_size=0
ORCL.__unified_pga_pool_size=0
*.archive_lag_target=300
*.audit_file_dest='/u01/app/oracle/admin/ORCL/adump'
*.compatible='19.0.0'
*.control_files='/u01/app/oracle/oradata/ORCL/controlfile/control-01.ctl'
*.db_block_checking='MEDIUM'
*.db_create_file_dest='/u01/app/oracle/oradata/ORCL'
*.db_name='ORCL'
*.db_recovery_file_dest_size=1073741824
*.db_unique_name='ORCL'
*.dbfips_140=FALSE
*.diagnostic_dest='/u01/app/oracle'
*.filesystemio_options='setall'
*.heat_map='OFF'
*.job_queue_processes=50
*.local_listener='(address=(protocol=tcp)(host=)(port=1521))'
*.log_archive_dest_1='location="/u01/app/oracle/oradata/ORCL/arch", valid_for=(ALL_LOGFILES,ALL_ROLES)'
*.log_archive_format='-%s-%t-%r.arc'
*.max_string_size='STANDARD'
*.memory_max_target=12385852416
*.memory_target=12385852416
*.open_cursors=300
*.pga_aggregate_target=0
*.processes=1673
*.recyclebin='OFF'
*.sga_target=0
*.undo_tablespace='UNDO_T1'
*.use_large_pages='FALSE'
*.DB_FILE_NAME_CONVERT='/rdsdbdata/db/ORCL_A/datafile/','/u01/app/oracle/oradata/ORCL/datafile/'
*.LOG_FILE_NAME_CONVERT='/rdsdbdata/db/ORCL_A/onlinelog/','/u01/app/oracle/oradata/ORCL/onlinelog/'
```

**Example Exemplo de arquivo de parâmetro multilocatário (`initORCL.ora`):**  

```
ORCL.__data_transfer_cache_size=0
ORCL.__db_cache_size=6006243328
ORCL.__inmemory_ext_roarea=0
ORCL.__inmemory_ext_rwarea=0
ORCL.__java_pool_size=0
ORCL.__large_pool_size=33554432
ORCL.__oracle_base='/u01/app/oracle'
ORCL.__pga_aggregate_target=4966055936
ORCL.__sga_target=7415529472
ORCL.__shared_io_pool_size=134217728
ORCL.__shared_pool_size=1207959552
ORCL.__streams_pool_size=0
ORCL.__unified_pga_pool_size=0
*.archive_lag_target=300
*.audit_file_dest='/u01/app/oracle/admin/ORCL/adump'
*.compatible='19.0.0'
*.control_files='/u01/app/oracle/oradata/ORCL/controlfile/control-01.ctl'
*.db_block_checking='MEDIUM'
*.db_create_file_dest='/u01/app/oracle/oradata/ORCL/pdb/datafile'
*.db_create_online_log_dest_1='/u01/app/oracle/oradata/ORCL'
*.db_name='ORCL'
*.db_recovery_file_dest_size=1073741824
*.db_unique_name='ORCL'
*.dbfips_140=FALSE
*.diagnostic_dest='/u01/app/oracle'
*.enable_pluggable_database=TRUE
*.filesystemio_options='setall'
*.heat_map='OFF'
*.job_queue_processes=50
*.local_listener='(address=(protocol=tcp)(host=)(port=1521))'
*.log_archive_dest_1='location="/u01/app/oracle/oradata/ORCL/arch", valid_for=(ALL_LOGFILES,ALL_ROLES)'
*.log_archive_format='-%s-%t-%r.arc'
*.max_string_size='STANDARD'
*.memory_max_target=12361688064
*.memory_target=12361688064
*.noncdb_compatible=TRUE
*.open_cursors=300
*.pga_aggregate_target=0
*.processes=1670
*.recyclebin='OFF'
*.sga_target=0
*.undo_tablespace='UNDO_T1'
*.use_large_pages='FALSE'
*.DB_FILE_NAME_CONVERT='/rdsdbdata/db/cdb/RDSCDB/datafile/','/u01/app/oracle/oradata/ORCL/cdb/datafile/','/rdsdbdata/db/cdb/pdbseed/','/u01/app/oracle/oradata/ORCL/pdbseed/datafile/','/rdsdbdata/db/pdb/RDSCDB_A/','/u01/app/oracle/oradata/ORCL/pdb/datafile/'
*.LOG_FILE_NAME_CONVERT='/rdsdbdata/db/cdb/RDSCDB_A/onlinelog/','/u01/app/oracle/oradata/ORCL/onlinelog/'
```

**Explicações dos principais parâmetros:**
+ `enable_pluggable_database=TRUE`: obrigatório para CDB multilocatário. Esse parâmetro ativa o recurso de banco de dados conectável.
+ `noncdb_compatible=TRUE`: definido pelo RDS Custom para compatibilidade com versões anteriores. Pode ser mantido ou removido dependendo das suas necessidades.
+ `db_create_file_dest`: especifica o local padrão para o Oracle Managed Files (OMF). Para multilocatário, isso aponta para o diretório de arquivo de dados do PDB.
+ `db_create_online_log_dest_1`: especifica a localização dos logs redo online ao usar o OMF.
+ `DB_FILE_NAME_CONVERT`: essencial para a duplicação do RMAN. Mapeia os caminhos do arquivo de dados de origem para os caminhos de destino.
+ `LOG_FILE_NAME_CONVERT`: mapeia os caminhos de log redo de origem para os caminhos de destino.
+ `memory_target` e `memory_max_target`: ajuste-os com base na memória da instância do EC2. Os valores mostrados são exemplos.
+ `processes`: número máximo de processos do sistema operacional que podem se conectar ao Oracle. Ajuste com base no workload.

**Diretrizes de dimensionamento de memória:**

Ao ajustar os parâmetros de memória para a instância do EC2:


|  **Memória da instância do EC2**  |  **memory\_target recomendado**  |  **memory\_max\_target recomendado**  | 
| --- | --- | --- | 
| 16 GB | 12 GB (12884901888 bytes) | 14 GB (15032385536 bytes) | 
| 32 GB | 24 GB (25769803776 bytes) | 28 GB (30064771072 bytes) | 
| 64 GB | 48 GB (51539607552 bytes) | 56 GB (60129542144 bytes) | 
| 128 GB | 96 GB (103079215104 bytes) | 112 GB (120259084288 bytes) | 

Deixe aproximadamente 20% a 25% da memória do sistema para o sistema operacional e outros processos.

### Etapa 5: configurar o TNS e o receptor
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-5"></a>

Nas duas instâncias, adicione entradas TNS a `tnsnames.ora`:

**Example Não CDB:**  

```
DB_SOURCE = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<RDS_CUSTOM_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL)))
DB_TARGET = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<EC2_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL)))
```

**Example Multilocatário:**  

```
DB_SOURCE = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<RDS_CUSTOM_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = RDSCDB)))
DB_TARGET = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<EC2_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL)))
```

**Example Configurar o receptor no EC2 (`$ORACLE_HOME/network/admin/listener.ora`):**  

```
LISTENER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<EC2_IP>}})(PORT = 1521)))
SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = ORCL) (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1) (SID_NAME = ORCL)))
```

**Example Iniciar receptor:**  

```
lsnrctl start
```

**nota**  
Para duplicação ativa do RMAN, as entradas TNS se conectam à instância do banco de dados usando SID (não SERVICE\_NAME). Para multilocatário, isso se conecta ao CDB, e o RMAN duplica automaticamente todos os PDBs.

### Etapa 6: iniciar o banco de dados em `NOMOUNT` no EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-6"></a>

**Example**  

```
export ORACLE_SID=ORCL
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH

sqlplus / as sysdba

SQL> STARTUP NOMOUNT PFILE='$ORACLE_HOME/dbs/initORCL.ora';
```

**Example Verifique os parâmetros:**  

```
SQL> SHOW PARAMETER db_name
SQL> SHOW PARAMETER control_files
SQL> SHOW PARAMETER enable_pluggable_database -- For multitenant
```

### Etapa 7: executar a duplicação ativa do RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-7"></a>

A duplicação ativa do RMAN copia o banco de dados da origem ativa e em execução para o destino. O banco de dados de origem permanece online e acessível aos aplicativos durante todo esse processo.

Conecte o RMAN às instâncias de origem e de destino:

**Example**  

```
rman target sys/{{<password>}}@DB_SOURCE auxiliary sys/{{<password>}}@DB_TARGET
```

**Example Saída esperada para não CDB:**  

```
Recovery Manager: Release 19.0.0.0.0 - Production
connected to target database: ORCL (DBID=4089929259)
connected to auxiliary database: ORCL (not mounted)
```

**Example Saída esperada para multilocatário:**  

```
Recovery Manager: Release 19.0.0.0.0 - Production
connected to target database: RDSCDB (DBID=4089929259)
connected to auxiliary database: ORCL (not mounted)
```

**Example Execute o comando de duplicação ativa:**  

```
RMAN> DUPLICATE DATABASE TO 'ORCL' FROM ACTIVE DATABASE NOFILENAMECHECK;
```

**nota**  
**A origem permanece online**: o banco de dados de origem continua atendendo às solicitações do aplicativo durante a duplicação
**Para não CDB**: isso duplica todo o banco de dados enquanto ele permanece online
**Para multilocatário**: isso duplica todo o CDB, incluindo `CDB$ROOT`, `PDB$SEED` e todos os PDBs em uma única operação, enquanto a origem permanece online
**NOFILENAMECHECK**: permite que o RMAN continue mesmo que os nomes dos arquivos sejam diferentes entre a origem e o destino
**Duração**: depende do tamanho do banco de dados e da largura de banda da rede. Para um banco de dados de 100 GB, espere de 30 a 60 minutos
**Impacto na rede:** alto uso da largura de banda da rede durante a duplicação, mas o banco de dados de origem permanece acessível

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

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

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

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

1. Montagem do banco de dados de destino

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

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

1. Abertura do banco de dados de destino com `RESETLOGS`

**Durante a duplicação, o banco de dados de origem:**
+ Permanece no modo `READ WRITE`
+ Continua aceitando conexões
+ Processa transações normalmente
+ Gera logs redo normalmente
+ É totalmente acessível aos aplicativos

**Example Monitore o andamento em outra sessão:**  

```
SQL> SELECT sid, serial#, sofar, totalwork, ROUND(sofar/totalwork*100,2) pct_complete
FROM v$session_longops WHERE totalwork > 0 AND sofar <> totalwork;
```

 **Monitoramento detalhado e solução de problemas durante a duplicação do RMAN:** 

Enquanto a duplicação do RMAN está em execução, monitore o andamento usando vários métodos:

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
   ```  
**Example 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
   ```

1.  **Monitore operações de longa duração:**   
**Example 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

1. **Monitore os canais do RMAN:**  
**Example**  

   ```
   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;
   ```

1. **Verifique o log de alertas:**  
**Example 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`).

### Etapa 8: abrir PDBs (somente multilocatário)
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-8"></a>

Após a conclusão da duplicação do RMAN, o CDB no EC2 é aberto no modo `READ WRITE`, mas todos os PDBs estão no estado `MOUNTED`. Esse é o comportamento esperado: você deve abri-los manualmente.

Verifique o status atual do PDB:

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

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

```
CON_ID     NAME                           OPEN_MODE
---------- ------------------------------ ----------
2          PDB$SEED                       READ ONLY
3          ORCLDB                         MOUNTED
```

Abra todos os PDBs:

```
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
Pluggable database altered.
```

Verifique se todos os PDBs agora estão abertos no modo `READ WRITE`:

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

Saída esperada:

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

Configure a abertura automática na inicialização usando o método de salvamento de estado (recomendado para Oracle 19c):

```
SQL> ALTER PLUGGABLE DATABASE ALL SAVE STATE;
Pluggable database altered.
```

Isso faz com que o Oracle se lembre do estado de abertura atual dos PDBs e o restaure na inicialização do CDB.

Verifique o estado salvo:

```
SQL> SELECT con_name, instance_name, state FROM dba_pdb_saved_states;
```

Verifique se os serviços do PDB estão registrados com o receptor:

```
lsnrctl services
```

A saída esperada deve mostrar serviços para o CDB e para cada PDB. Se os serviços não estiverem sendo exibidos:

```
SQL> ALTER SYSTEM REGISTER;
```

Em seguida, verifique novamente com `lsnrctl services`.

### Etapa 9: remover objetos do RDS Custom
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-9"></a>

Como agora esse é um banco de dados autogerenciado no EC2, você deve remover usuários e objetos específicos do RDS Custom. O processo de limpeza difere entre arquiteturas não CDB e multilocatário.

**Importante**  
Antes de descartar usuários e espaços de tabela específicos do RDS, verifique se não há objetos de aplicativo nesses esquemas:

```
SQL> SELECT owner, object_type, COUNT(*)
FROM dba_objects
WHERE owner IN ('RDSADMIN', 'RDS_DATAGUARD')
  AND object_name NOT LIKE 'RDS%'
  AND object_name NOT LIKE 'SYS_%'
GROUP BY owner, object_type;
```

Se algum objeto do aplicativo for encontrado, migre-o para os esquemas apropriados do aplicativo antes de continuar.

**Example Não CDB:**  

```
SQL> DROP USER RDSADMIN CASCADE;
SQL> DROP USER RDS_DATAGUARD CASCADE;
SQL> DROP DIRECTORY OPATCH_INST_DIR;
SQL> DROP DIRECTORY OPATCH_LOG_DIR;
SQL> DROP DIRECTORY OPATCH_SCRIPT_DIR;
SQL> DROP TABLESPACE RDSADMIN INCLUDING CONTENTS AND DATAFILES;

-- Verify removal
SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%';
```

Saída esperada: `no rows selected`

**Multilocatário:**

Em um ambiente multilocatário, o RDS Custom cria usuários comuns em `CDB$ROOT` que são visíveis em todos os PDBs. Você deve apagar de `CDB$ROOT`.

```
-- Connect to CDB$ROOT
SQL> SHOW CON_NAME;
-- Check for RDS-specific common users (including C## prefixed users)
SQL> SELECT username, common, con_id FROM cdb_users
WHERE username LIKE '%RDS%' OR username LIKE 'C##RDS%'
ORDER BY username;

-- Drop non-common users
SQL> DROP USER RDSADMIN CASCADE;
SQL> DROP USER RDS_DATAGUARD CASCADE;

-- If any C## common users exist
-- SQL> DROP USER C##RDSADMIN CASCADE
;
-- Drop directories and tablespace
SQL> DROP DIRECTORY OPATCH_INST_DIR;
SQL> DROP DIRECTORY OPATCH_LOG_DIR;
SQL> DROP DIRECTORY OPATCH_SCRIPT_DIR;
SQL> DROP TABLESPACE RDSADMIN INCLUDING CONTENTS AND DATAFILES;

-- Verify removal from CDB$ROOT
SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%';

-- Verify removal from each PDB
SQL> ALTER SESSION SET CONTAINER = {{<PDB_NAME>}};
SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%';
```

Saída esperada para todas as consultas: `no rows selected`

### Etapa 10: configurar a inicialização automática
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-10"></a>

Create `SPFILE`:

```
SQL> CREATE SPFILE FROM PFILE='$ORACLE_HOME/dbs/initORCL.ora';
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
```

Para multilocatário, garanta que os PDBs estejam abertos:

```
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
```

Editar o `/etc/oratab`:

```
ORCL:/u01/app/oracle/product/19.0.0/dbhome_1:Y
```

### Etapa 11: validação final
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-11"></a>

**Example Não CDB:**  

```
SQL> SELECT name, open_mode, log_mode FROM v$database;
SQL> SELECT SUM(bytes)/1024/1024/1024 AS size_gb FROM dba_data_files;
SQL> SELECT COUNT(*) FROM dba_objects WHERE status = 'INVALID';
```

**Example Multilocatário:**  

```
SQL> SELECT name, open_mode, log_mode, cdb FROM v$database;
SQL> SELECT con_id, name, open_mode FROM v$pdbs;
SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM cdb_data_files;
SQL> SELECT con_id, COUNT(*) FROM cdb_objects WHERE status = 'INVALID' GROUP BY con_id;
```

```
Test application connectivity:
# Non-CDB
sqlplus {{<app_user>}}/{{<password>}}@{{<EC2_IP>}}:1521/ORCL

# Multitenant (connect to PDB)
sqlplus {{<app_user>}}/{{<password>}}@{{<EC2_IP>}}:1521/{{<PDB_NAME>}}
```

 **Etapa 12: retornar a automação do RDS Custom** 

```
aws rds modify-db-instance \
--db-instance-identifier my-custom-instance \
--automation-mode full \
--region us-east-1
```

 

## Opção 2: migração física usando o Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2"></a>



Esta seção fornece etapas detalhadas para migrar seu banco de dados Oracle do RDS Custom para Oracle para o EC2 usando o Oracle Data Guard. Esse método é adequado para migrações que exigem o tempo de inatividade mínimo.

### Quando usar o Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-when-use-odg"></a>

**Escolha o Oracle Data Guard quando:**
+ Você precisar de um tempo de inatividade mínimo (segundos a minutos para a transição)
+ Você estiver migrando bancos de dados de produção ou de missão crítica
+ Você precisar de sincronização contínua antes da substituição
+ Você quiser um recurso de fallback integrado
+ Você precisar testar o banco de dados de destino antes de se comprometer com a migração

### Visão geral do Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-odg-overview"></a>

O Oracle Data Guard mantém um banco de dados em espera sincronizado enviando e aplicando continuamente logs redo do banco de dados principal. Quando estiver tudo pronto para concluir a migração, você executa uma transição que promove o modo de espera do EC2 para o banco de dados principal com o tempo de inatividade mínimo (de segundos a minutos). Para bancos de dados multilocatário, o Data Guard protege automaticamente todo o CDB, incluindo todos os PDBs. O redo gerado por qualquer PDB é enviado para o modo de espera e aplicado ao PDB correspondente no modo de espera.

### Fluxo de trabalho de migração para o Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-odg-workflow"></a>

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

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

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

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

1. Criar um arquivo de senha

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

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

1. 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

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

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

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

1. 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

1. Configurar tnsnames.ora nas duas instâncias

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

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

1. Configurar fal\_server e fal\_client na instância em espera do EC2

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

1. Recuperar a instância em espera

1. Executar a transição manual

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

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

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

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

### Etapa 1: pausar a automação do Amazon RDS Custom
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-1"></a>

Pause o modo de automação na instância do RDS Custom. O parâmetro `--resume-full-automation-mode-minute` deve ser ajustado com base no tamanho do banco de dados e no tempo esperado de configuração do Data Guard.

```
aws rds modify-db-instance \
  --db-instance-identifier my-custom-instance \
  --automation-mode all-paused \
  --resume-full-automation-mode-minute 480 \
  --region us-east-1
```

Valide o status da automação:

```
aws rds describe-db-instances \
  --db-instance-identifier my-custom-instance \
  --region us-east-1 \
  --query 'DBInstances[0].AutomationMode'
```

Saída esperada: "`all-paused`"

### Etapa 2: confirmar o modo de log de arquivamento e `FORCE_LOGGING`
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-2"></a>

O Oracle Data Guard exige que o banco de dados principal esteja no modo de log de arquivamento com o registro forçado ativado:

```
sqlplus / as sysdba
SQL> SELECT log_mode, force_logging FROM v$database;
```

Saída esperada:

```
LOG_MODE     FORCE_LOGGING
------------ -------------
ARCHIVELOG   YES
```

Se o registro forçado não estiver ativado, execute:

```
SQL> ALTER DATABASE FORCE LOGGING;
```

### Etapa 3: criar arquivos de senha e parâmetro
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-3"></a>

Crie um arquivo de senha usando `orapwd`. Recupere a senha SYS do AWS Secrets Manager.

```
# Non-CDB
$ORACLE_HOME/bin/orapwd file=/rdsdbdata/config/orapwORCL password={{<SYS_PASSWORD>}} entries=10

# Multitenant
$ORACLE_HOME/bin/orapwd file=/rdsdbdata/config/orapwRDSCDB password={{<SYS_PASSWORD>}} entries=10
```

Crie um arquivo de parâmetro do banco de dados de origem:

```
sqlplus / as sysdba
SQL> CREATE PFILE='/tmp/initORCL.ora' FROM SPFILE; -- Non-CDB
SQL> CREATE PFILE='/tmp/initRDSCDB.ora' FROM SPFILE; -- Multitenant
```

### Etapa 4: executar o backup do RMAN ou usar a duplicação ativa
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4"></a>

Você tem duas opções para criar o banco de dados em espera:

#### Opção A: backup online do RMAN (recomendado para a maioria dos cenários)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4-a"></a>

Crie um diretório de backup e faça backup do banco de dados:

```
mkdir -p /rdsdbdata/backup
rman target /
RMAN> run {
  backup as compressed backupset
  filesperset 2
  format '/rdsdbdata/backup/db_%U'
  database;
  sql 'alter system archive log current';
  backup as compressed backupset
  filesperset 50
  format '/rdsdbdata/backup/arch_%U'
  archivelog all;
}

RMAN> backup current controlfile for standby format '/rdsdbdata/backup/standby.ctl';
```

**nota**  
Para multilocatário, a palavra-chave do banco de dados faz backup automático de todo o CDB, incluindo todos os PDBs.

#### Opção B: duplicação ativa (método alternativo)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4-b"></a>

Ignore a etapa de backup e use a duplicação ativa do RMAN para criar o modo de espera diretamente na rede. Isso elimina a necessidade de armazenamento de backup e transferência de arquivos. Depois de configurar o TNS e os receptores (veja abaixo), execute:

```
RMAN> DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DORECOVER;
```

Essa orientação se concentra na Opção A (baseada em backup), mas a Opção B é uma alternativa válida.

### Etapa 5: transferir arquivos para o EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-5"></a>

Escolha seu método preferido de transferência de arquivos. Esta orientação usa o Amazon S3 como exemplos.

**Usar o Amazon S3:**

**Example Para não CDB:**  

```
# Copy files to Amazon S3 from the RDS Custom instance
aws s3 cp /rdsdbdata/backup s3://{{<YOUR_BUCKET>}}/ --recursive
aws s3 cp /tmp/initORCL.ora s3://{{<YOUR_BUCKET>}}/
aws s3 cp /rdsdbdata/config/orapwORCL s3://{{<YOUR_BUCKET>}}/

# On EC2, download files
aws s3 cp s3://{{<YOUR_BUCKET>}}/backup /u01/app/oracle/backup/ --recursive
aws s3 cp s3://{{<YOUR_BUCKET>}}/initORCL.ora $ORACLE_HOME/dbs/
aws s3 cp s3://{{<YOUR_BUCKET>}}/orapwORCL $ORACLE_HOME/dbs/
```

**Example Para multilocatário:**  

```
# Copy files to Amazon S3 from the RDS Custom instance
aws s3 cp /rdsdbdata/backup s3://{{<YOUR_BUCKET>}}/ --recursive
aws s3 cp /tmp/initRDSCDB.ora s3://{{<YOUR_BUCKET>}}/
aws s3 cp /rdsdbdata/config/orapwRDSCDB s3://{{<YOUR_BUCKET>}}/

# On EC2, download and rename files to use ORCL naming
aws s3 cp s3://{{<YOUR_BUCKET>}}/backup /u01/app/oracle/backup/ --recursive
aws s3 cp s3://{{<YOUR_BUCKET>}}/initRDSCDB.ora $ORACLE_HOME/dbs/initORCL.ora
aws s3 cp s3://{{<YOUR_BUCKET>}}/orapwRDSCDB $ORACLE_HOME/dbs/orapwORCL
```

### Etapa 6: editar arquivo de parâmetro no EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-6"></a>

Edite `$ORACLE_HOME/dbs/initORCL.ora` na instância do EC2 e faça essas alterações essenciais:

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

1. **Alterar db\_unique\_name**: de `ORCL_A` (ou `RDSCDB_A`) para `ORCL_B`

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

1. 

****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

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

 **Mapeamentos de caminho:** 

**Não CDB:**
+ `/rdsdbdata/db/ORCL_A/datafile/` → `/u01/app/oracle/oradata/ORCL/datafile/`
+ `/rdsdbdata/db/ORCL_A/controlfile/` → `/u01/app/oracle/oradata/ORCL/controlfile/`
+ `/rdsdbdata/db/ORCL_A/onlinelog/` → `/u01/app/oracle/oradata/ORCL/onlinelog/`
+ `/rdsdbdata/admin/ORCL/adump` → `/u01/app/oracle/admin/ORCL/adump`

**Multilocatário:**
+ `/rdsdbdata/db/cdb/RDSCDB/datafile/` → `/u01/app/oracle/oradata/ORCL/cdb/datafile/`
+ `/rdsdbdata/db/cdb/pdbseed/` → `/u01/app/oracle/oradata/ORCL/pdbseed/datafile/`
+ `/rdsdbdata/db/pdb/RDSCDB_A/` → `/u01/app/oracle/oradata/ORCL/pdb/datafile/`
+ `/rdsdbdata/db/cdb/RDSCDB_A/controlfile/` → `/u01/app/oracle/oradata/ORCL/controlfile/`
+ `/rdsdbdata/admin/RDSCDB/adump` → `/u01/app/oracle/admin/ORCL/adump`

**Importante**: para multilocatário, `enable_pluggable_database` = `TRUE` deve estar presente no arquivo de parâmetro.

### Etapa 7: criar `SPFILE` e restaurar o banco de dados em espera
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-7"></a>

Inicie a instância e crie SPFILE:

```
sqlplus / as sysdba
SQL> STARTUP NOMOUNT PFILE='$ORACLE_HOME/dbs/initORCL.ora';
SQL> CREATE SPFILE='/u01/app/oracle/admin/ORCL/pfile/spfileORCL.ora' FROM PFILE='$ORACLE_HOME/dbs/initORCL.ora';
SQL> SHUTDOWN IMMEDIATE;
```

Crie um link simbólico:

```
ln -sfn /u01/app/oracle/admin/ORCL/pfile/spfileORCL.ora $ORACLE_HOME/dbs/spfileORCL.ora
```

Inicie a instância e restaure:

```
SQL> STARTUP NOMOUNT;
rman target /
```

Se os arquivos de backup estiverem em um caminho diferente do de origem, catalogue-os primeiro:

```
RMAN> catalog start with '/u01/app/oracle/backup/';
```

Restaure o arquivo de controle em espera e monte:

```
RMAN> restore standby controlfile from '/u01/app/oracle/backup/standby.ctl';
RMAN> alter database mount;
```

Se os caminhos do arquivo de dados forem diferentes (por exemplo, usando ASM), use `SET NEWNAME`:

```
RMAN> run {
set newname for database to '+DATA/%b';
restore database;
switch datafile all;
}
```

Caso contrário, basta restaurar:

```
RMAN> restore database;
```

Recupere o banco de dados até a última sequência disponível:

```
RMAN> list backup of archivelog all;
RMAN> recover database until sequence <LAST_SEQ + 1>;
```

**nota**  
Para multilocatário, o RMAN restaura e recupera automaticamente todos os PDBs. Você não precisa restaurar cada PDB separadamente.

### Etapa 8: configurar o TNS e os receptores
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-8"></a>

Nas duas instâncias, adicione entradas TNS a `tnsnames.ora`:

**Example Não CDB:**  

```
ORCL_A = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<RDS_CUSTOM_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL)))
ORCL_B = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<EC2_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL)))
```

**Example Multilocatário:**  

```
RDSCDB_A = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<RDS_CUSTOM_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = RDSCDB)))
ORCL_B = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = {{<EC2_IP>}})(PORT = 1521)) (CONNECT_DATA = (SID = ORCL)))
```

Configure receptores nas duas instâncias. No RDS Custom, anexe a `listener.ora`:

**Example Para não CDB:**  

```
SID_LIST_L_ORCL_DG=(SID_LIST = (SID_DESC = (SID_NAME = ORCL)(GLOBAL_DBNAME = ORCL) (ORACLE_HOME = /rdsdbbin/oracle.19.custom.r1.EE.1)))
L_ORCL_DG=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(PORT = 1521)(HOST = {{<RDS_CUSTOM_IP>}})))
```

**Example Para multilocatário:**  

```
SID_LIST_L_RDSCDB_DG=(SID_LIST = (SID_DESC = (SID_NAME = RDSCDB)(GLOBAL_DBNAME = RDSCDB) (ORACLE_HOME = /rdsdbbin/oracle.19.custom.r1.EE-CDB.1)))
L_RDSCDB_DG=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(PORT = 1521)(HOST = {{<RDS_CUSTOM_IP>}})))
```

Inicie o receptor:

```
$ORACLE_HOME/bin/lsnrctl start L_ORCL_DG # or L_RDSCDB_DG for multitenant
```

No EC2, crie `$ORACLE_HOME/network/admin/listener.ora`:

```
SID_LIST_L_ORCL_DG=(SID_LIST = (SID_DESC = (SID_NAME = ORCL)(GLOBAL_DBNAME = ORCL) (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1)))
L_ORCL_DG=(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(PORT = 1521)(HOST = {{<EC2_IP>}})))
```

Inicie o receptor:

```
$ORACLE_HOME/bin/lsnrctl start L_ORCL_DG
```

**nota**  
Você pode usar o receptor existente no RDS Custom, se preferir, mas criar um receptor separado do Data Guard fornece melhor isolamento.

**Importante**  
Se a conectividade `tnsping` ou `listener` falhar, verifique as regras `iptables` no EC2. Muitas instâncias do EC2 Linux têm regras `iptables` padrão que bloqueiam a porta 1521. Adicione uma regra: `sudo iptables -I INPUT 5 -p tcp --dport 1521 -j ACCEPT`

### Etapa 9: ativar o agente e a configuração do Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-9"></a>

Nas duas instâncias, ative o agente do Data Guard:

```
sqlplus / as sysdba
SQL> ALTER SYSTEM SET dg_broker_start=true;
```

No banco de dados principal do RDS Custom, conecte-se ao agente do Data Guard e crie a configuração:

```
dgmgrl /
```

**Example Para não CDB:**  

```
DGMGRL> CREATE CONFIGURATION my_dg_config AS PRIMARY DATABASE IS ORCL_A CONNECT IDENTIFIER IS ORCL_A;
DGMGRL> ADD DATABASE ORCL_B AS CONNECT IDENTIFIER IS ORCL_B MAINTAINED AS PHYSICAL;
```

 

**Example Para multilocatário:**  

```
DGMGRL> CREATE CONFIGURATION my_dg_config AS PRIMARY DATABASE IS RDSCDB_A CONNECT IDENTIFIER IS RDSCDB_A;
DGMGRL> ADD DATABASE ORCL_B AS CONNECT IDENTIFIER IS ORCL_B MAINTAINED AS PHYSICAL;
```

Defina identificadores de conexão estáticos e ative:

 

**Example Para não CDB:**  

```
DGMGRL> edit database orcl_a set property StaticConnectIdentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST=<RDS_CUSTOM_IP>))(CONNECT_DATA=(SID=ORCL)(SERVER=DEDICATED)))';
DGMGRL> edit database orcl_b set property StaticConnectIdentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST={{<EC2_IP>}}))(CONNECT_DATA=(SID=ORCL)(SERVER=DEDICATED)))';
DGMGRL> ENABLE CONFIGURATION;
```

 

**Example Para multilocatário:**  

```
DGMGRL> edit database rdscdb_a set property StaticConnectIdentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST=<RDS_CUSTOM_IP>))(CONNECT_DATA=(SID=RDSCDB)(SERVER=DEDICATED)))';
DGMGRL> edit database orcl_b set property StaticConnectIdentifier='(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(PORT=1521)(HOST={{<EC2_IP>}}))(CONNECT_DATA=(SID=ORCL)(SERVER=DEDICATED)))';
DGMGRL> ENABLE CONFIGURATION;
```

**nota**  
O agente do Data Guard é opcional, mas recomendado para facilitar o gerenciamento. Para migrações simples, você pode configurar o Data Guard manualmente sem o agente.

**nota**  
Quando você ativa o Data Guard para um CDB, ele protege automaticamente todos os PDBs. O redo gerado por qualquer PDB é enviado para o modo de espera e aplicado ao PDB correspondente no modo de espera.

### Etapa 10: configurar os logs redo em espera e iniciar a recuperação
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10"></a>

Na instância de espera do EC2, adicione arquivos de log redo em espera (n\+1 em que n é o número de grupos de log redo online):

```
ALTER DATABASE ADD STANDBY LOGFILE ('slog1.rdo') SIZE 128M;
ALTER DATABASE ADD STANDBY LOGFILE ('slog2.rdo') SIZE 128M;
ALTER DATABASE ADD STANDBY LOGFILE ('slog3.rdo') SIZE 128M;
ALTER DATABASE ADD STANDBY LOGFILE ('slog4.rdo') SIZE 128M;
ALTER DATABASE ADD STANDBY LOGFILE ('slog5.rdo') SIZE 128M;
```

**nota**  
Para multilocatário, os logs redo em espera são criados no nível do CDB e compartilhados por todos os PDBs.

Configure os parâmetros FAL no modo de espera:

 

**Example Para não CDB:**  

```
SQL> alter system set fal_server = 'ORCL_A';
SQL> alter system set fal_client = 'ORCL_B';
```

 

**Example Para multilocatário:**  

```
SQL> alter system set fal_server = 'RDSCDB_A';
SQL> alter system set fal_client = 'ORCL_B';
```

Inicie a recuperação gerenciada:

```
SQL> recover managed standby database disconnect from session;
```

Monitore o atraso de aplicação:

```
SQL> SELECT name, value FROM v$dataguard_stats WHERE name = 'apply lag';
```

**Monitoramento e gerenciamento detalhados da sincronização do Data Guard:**

O monitoramento do Data Guard é fundamental para garantir uma migração bem-sucedida. Confira as técnicas de monitoramento abrangentes:

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

1. **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;
   ```

1. **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;
   ```

1. **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;
   ```

1. **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';
   ```

1. **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;
   ```

#### Problemas comuns de sincronização do Data Guard:
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues"></a>



##### Problema 1: grande atraso na aplicação
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-1"></a>

Sintomas:

```
SQL> SELECT name, value FROM v$dataguard_stats WHERE name = 'apply lag';
NAME                             VALUE
-------------------------------- -----
apply lag                        +00 01:30:00
```

Causas e soluções:
+ **CPU/IO insuficiente em espera**: atualize o tipo de instância do EC2 ou aumente o IOPS do EBS
+ **Limitação de largura de banda da rede**: use redes aprimoradas ou tipos de instância com maior largura de banda
+ **Vários PDBs com alta taxa de transação**: aumente o paralelismo de aplicação de redo (requer a licença ativa do Data Guard)

```
-- Increase apply parallelism (requires Active 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;
```

##### Problema 2: lacuna no log de arquivamento
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-2"></a>

Sintomas:

```
SQL> SELECT * FROM v$archive_gap;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
------- ------------- --------------
      1          1234           1240
```

Solução:

```
-- FAL (Fetch Archive Log) will automatically fetch missing logs
-- Verify FAL parameters are set correctly
SQL> SHOW PARAMETER fal_server
SQL> SHOW PARAMETER fal_client

-- Manually register missing archive logs if needed
-- On primary, check if logs still exist
SQL> SELECT name FROM v$archived_log WHERE sequence# BETWEEN 1234 AND 1240;

-- If logs are missing on primary, you may need to rebuild the standby
```

##### Problema 3: falha no transporte de redo
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-3"></a>

Sintomas:

```
SQL> SELECT dest_id, status, error FROM v$archive_dest WHERE dest_id = 2;
DEST_ID STATUS    ERROR
------- --------- ----------------------------------------
2       ERROR     ORA-16191: Primary log shipping client not logged on standby
```

Solução:

```
-- Check network connectivity
-- Verify TNS configuration
-- Check listener status on standby
-- Restart log transport

SQL> ALTER SYSTEM SET log_archive_dest_state_2 = 'DEFER';
SQL> ALTER SYSTEM SET log_archive_dest_state_2 = 'ENABLE';
```

##### Problema 4: a recuperação gerenciada não aplica o redo
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-4"></a>

Sintomas:

```
SQL> SELECT process, status FROM v$managed_standby WHERE process = 'MRP0';
PROCESS   STATUS
--------- ------------
MRP0      WAIT_FOR_LOG
```

Solução:

```
# Check if archive logs are arriving
ls -ltr /u01/app/oracle/oradata/ORCL/arch/

# Check alert log for errors
tail -100 $ORACLE_BASE/diag/rdbms/orcl_b/ORCL/trace/alert_ORCL.log

# Restart managed recovery
sqlplus / as sysdba
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
```

**Para multilocatário**, você também pode verificar o status de cada PDB no banco de dados em espera:

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

Saída esperada (PDBs em estado `MOUNTED` no banco de dados em espera):

```
CON_ID     NAME                           OPEN_MODE  RES
---------- ------------------------------ ---------- ---
2          PDB$SEED                       MOUNTED
3          ORCLDB                         MOUNTED
```

**nota**  
Em um banco de dados em espera físico, os PDBs permanecem no estado `MOUNTED` durante a recuperação gerenciada.

### Etapa 11: executar a transição
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-11"></a>

Quando o banco de dados em espera estiver totalmente sincronizado e pronto, execute a transição. Para multilocatário, a transição mudará todo o CDB (todos os PDBs) do banco de dados principal do RDS Custom para o banco de dados em espera do EC2.

Na instância do banco de dados principal do RDS Custom, conecte-se ao agente do Data Guard e verifique se os dois bancos de dados estão prontos para a transição:

**Example Para não CDB:**  

```
DGMGRL> VALIDATE DATABASE ORCL_A;
DGMGRL> VALIDATE DATABASE ORCL_B;
```

 

**Example Para multilocatário:**  

```
DGMGRL> VALIDATE DATABASE RDSCDB_A;
DGMGRL> VALIDATE DATABASE ORCL_B;
```

Ambos devem mostrar `Ready for Switchover: Yes`

Mude do banco de dados principal do RDS Custom para o banco de dados em espera do EC2:

```
DGMGRL> SWITCHOVER TO ORCL_B;
```

Verifique se a transição foi bem-sucedida:

```
DGMGRL> SHOW CONFIGURATION VERBOSE;
```

A instância do EC2 (`ORCL_B`) agora é o banco de dados principal, e a instância do RDS Custom é o banco de dados em espera físico.

### Etapa 12: abrir PDBs (somente multilocatário)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-12"></a>

Após a transição, o CDB no EC2 é aberto no modo READ WRITE, mas todos os PDBs estão no estado MOUNTED. Você deve abri-los manualmente.

Conecte-se ao novo banco de dados principal no EC2:

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

Saída esperada:

```
NAME      OPEN_MODE            DATABASE_ROLE    CDB
--------- -------------------- ---------------- ---
ORCL      READ WRITE           PRIMARY          YES
```

Verifique o status atual do PDB:

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

Saída esperada (PDBs no estado `MOUNTED` - exemplo com um PDB chamado `ORCLDB`):

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

Abra todos os PDBs:

```
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
```

Banco de dados conectável alterado.

Verifique se todos os PDBs agora estão abertos no modo `READ WRITE`:

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

Saída esperada:

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

### Etapa 13: configurar a abertura automática do PDB na inicialização (somente multilocatário)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-13"></a>

Configure os PDBs para abrirem automaticamente quando o CDB começar a usar o método de salvamento do estado (recomendado para o Oracle 19c):

```
SQL> ALTER PLUGGABLE DATABASE ALL SAVE STATE;
Pluggable database altered.
```

Verifique o estado salvo:

```
SQL> SELECT con_name, instance_name, state FROM dba_pdb_saved_states;
```

Verifique se os serviços do PDB estão registrados com o receptor:

```
lsnrctl services
```

A saída esperada deve mostrar serviços para o CDB e para cada PDB. Se os serviços não estiverem sendo exibidos:

```
SQL> ALTER SYSTEM REGISTER;
```

Em seguida, verifique novamente com `lsnrctl services`.

### Etapa 14: remover objetos personalizados do RDS
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-14"></a>

Como agora esse é um banco de dados autogerenciado no EC2, você deve remover usuários e objetos específicos do RDS Custom. O processo de limpeza difere um pouco entre arquiteturas não CDB e multilocatário.

**Importante**  
Antes de descartar usuários e espaços de tabela específicos do RDS, verifique se não há objetos de aplicativo nesses esquemas:

```
SQL> SELECT owner, object_type, COUNT(*)
FROM dba_objects
WHERE owner IN ('RDSADMIN', 'RDS_DATAGUARD')
  AND object_name NOT LIKE 'RDS%'
  AND object_name NOT LIKE 'SYS_%'
GROUP BY owner, object_type;
```

Se algum objeto do aplicativo for encontrado, migre-o para os esquemas apropriados do aplicativo antes de continuar.

**Limpeza de não CDB:**

```
sqlplus / as sysdba

-- Drop RDS-specific users
SQL> DROP USER RDSADMIN CASCADE;
SQL> DROP USER RDS_DATAGUARD CASCADE;

-- Drop RDS-specific directories
SQL> DROP DIRECTORY OPATCH_INST_DIR;
SQL> DROP DIRECTORY OPATCH_LOG_DIR;
SQL> DROP DIRECTORY OPATCH_SCRIPT_DIR;

-- Drop the RDSADMIN tablespace
SQL> DROP TABLESPACE RDSADMIN INCLUDING CONTENTS AND DATAFILES;

-- Verify removal
SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%';
```

Saída esperada: `no rows selected`

**Limpeza de multilocatário:**

Em um ambiente multilocatário, o RDS Custom cria usuários comuns em `CDB$ROOT` que são visíveis em todos os PDBs. Você deve apagar de `CDB$ROOT`.

```
sqlplus / as sysdba

-- Verify you are in CDB$ROOT
SQL> SHOW CON_NAME;

-- Check for RDS-specific common users (including C## prefixed users)
SQL> SELECT username, common, con_id FROM cdb_users
WHERE username LIKE 'RDS%' OR username LIKE 'C##RDS%'
ORDER BY username;

-- Drop non-common users
SQL> DROP USER RDSADMIN CASCADE;
SQL> DROP USER RDS_DATAGUARD CASCADE;

-- If any C## common users exist
-- Example (adjust based on your findings):
-- SQL> DROP USER C##RDS_DATAGUARD CASCADE;
-- Drop RDS-specific directories
SQL> DROP DIRECTORY OPATCH_INST_DIR;
SQL> DROP DIRECTORY OPATCH_LOG_DIR;
SQL> DROP DIRECTORY OPATCH_SCRIPT_DIR;

-- Drop the RDSADMIN tablespace
SQL> DROP TABLESPACE RDSADMIN INCLUDING CONTENTS AND DATAFILES;

-- Verify removal from CDB$ROOT
SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%';

-- Verify removal from each PDB (example with one PDB named ORCLDB)
SQL> ALTER SESSION SET CONTAINER = ORCLDB;
SQL> SELECT username FROM dba_users WHERE username LIKE '%RDS%';
```

Saída esperada para todas as consultas: nenhuma linha selecionada

### Etapa 15: configurar inicialização automática
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-15"></a>

Verifique se o `SPFILE` está sendo usado:

```
sqlplus / as sysdba
SQL> SHOW PARAMETER spfile;
```

Se o caminho `spfile` estiver correto, nenhuma ação será necessária. Se não estiver, crie um:

```
SQL> CREATE SPFILE FROM MEMORY;
```

Reinicie o banco de dados:

```
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
```

Para multilocatário, abra todos os PDBs (eles devem abrir automaticamente se você tiver salvo o estado anteriormente):

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

Se os PDBs não estiverem abertos, abra-os manualmente:

```
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
```

Editar o `/etc/oratab`:

```
vi /etc/oratab
```

Altere a linha de `ORCL` de `N` para `Y`:

```
ORCL:/u01/app/oracle/product/19.0.0/dbhome_1:Y
```

### Etapa 16: validação final
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-16"></a>

Execute uma validação abrangente no banco de dados migrado.

**Example Para não CDB:**  

```
sqlplus / as sysdba

-- Verify database role and status
SQL> SELECT name, open_mode, log_mode, database_role FROM v$database;

-- Check database size
SQL> SELECT SUM(bytes)/1024/1024/1024 AS size_gb FROM dba_data_files;

-- Verify all objects are valid
SQL> SELECT owner, object_type, COUNT(*)
     FROM dba_objects
     WHERE status = 'INVALID'
     GROUP BY owner, object_type;

-- Verify data files
SQL> SELECT name, status FROM v$datafile;

-- Test application connectivity
SQL> SELECT username, machine, program FROM v$session WHERE username IS NOT NULL;
```

**Example Para multilocatário:**  

```
sqlplus / as sysdba

-- Verify CDB status
SQL> SELECT name, open_mode, log_mode, cdb, database_role FROM v$database;

-- Verify all PDBs are open
SQL> SELECT con_id, name, open_mode, restricted FROM v$pdbs;

-- Check total CDB size
SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM cdb_data_files;

-- Check 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;

-- Verify all objects are valid across all PDBs
SQL> SELECT con_id, owner, object_type, COUNT(*)
     FROM cdb_objects
     WHERE status = 'INVALID'
     GROUP BY con_id, owner, object_type;

-- Verify PDB services are registered
SQL> SELECT name FROM v$services ORDER BY name;

Test application connectivity:

# Non-CDB
sqlplus {{<app_user>}}/{{<password>}}@{{<EC2_IP>}}:1521/ORCL

# Multitenant (connect to PDB)
sqlplus {{<app_user>}}/{{<password>}}@{{<EC2_IP}}>:1521/{{<PDB_NAME>}}
```

Teste a conectividade do aplicativo:

```
# Non-CDB
sqlplus {{<app_user>}}/{{<password>}}@{{<EC2_IP>}}:1521/ORCL

# Multitenant (connect to PDB)
sqlplus {{<app_user>}}/{{<password>}}@{{<EC2_IP>}}:1521/{{<PDB_NAME>}}
```

### Etapa 17: apagar arquivos de backup
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-17"></a>

Após a validação bem-sucedida, remova os arquivos de backup e desanexe o volume de backup se estiver usando um volume do EBS separado:

```
rm -rf /u01/app/oracle/backup/*
```

Se estiver usando um volume do EBS separado para backups:

```
# Unmount the volume
sudo umount /u01/app/oracle/backup

# Detach and delete the EBS volume from AWS Console or CLI
aws ec2 detach-volume --volume-id {{<volume-id>}}
aws ec2 delete-volume --volume-id {{<volume-id>}}
```

### Etapa 18: retornar a automação do RDS Custom
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-18"></a>

Se você pretende manter a instância do RDS Custom em execução como alternativa durante um período de validação, retome a automação:

```
aws rds modify-db-instance \
  --db-instance-identifier my-custom-instance \
  --automation-mode full \
  --region us-east-1
```

## Solucionar problemas comuns
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting"></a>



Esta seção aborda problemas comuns que você pode encontrar durante a migração tanto para a duplicação do RMAN quanto para as abordagens do Oracle Data Guard, abrangendo arquiteturas não CDB e multilocatário.

### ORA-09925: não é possível criar arquivo de trilha de auditoria
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-09925"></a>

**Causa:** o diretório de auditoria especificado no parâmetro `audit_file_dest` não existe na instância do EC2 de destino.

 **Solução:** 

Verifique se o diretório de auditoria existe e tem as permissões adequadas:

```
mkdir -p /u01/app/oracle/admin/ORCL/adump
chown -R oracle:oinstall /u01/app/oracle/admin/ORCL
chmod -R 755 /u01/app/oracle/admin/ORCL
```

### ORA-01261: a string de destino do parâmetro `db_create_file_dest` não pode ser traduzida
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-01261"></a>

**Causa:** o diretório especificado no parâmetro `db_create_file_dest` não existe na instância do EC2 de destino.

 **Solução:** 

Para não CDB:

```
mkdir -p /u01/app/oracle/oradata/ORCL
chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL
chmod -R 755 /u01/app/oracle/oradata/ORCL
```

Para multilocatário:

```
mkdir -p /u01/app/oracle/oradata/ORCL/pdb/datafile
chown -R oracle:oinstall /u01/app/oracle/oradata/ORCL
chmod -R 755 /u01/app/oracle/oradata/ORCL
```

### ORA-01804: falha ao inicializar as informações de fuso horário
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-01804"></a>

Esse erro pode ocorrer ao descartar o usuário `RDSADMIN` se a origem do RDS tiver uma versão de fuso horário maior do que a instalada em seu EC2 $ORACLE\_HOME.

 **Solução:** 

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%';
   ```

1. 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.

1. Repita a entrega:

   ```
   sqlplus / as sysdba
   SQL> DROP USER RDSADMIN CASCADE;
   ```

### Problemas de migração entre RUs (diferentes atualizações de versão)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-cross-ru-migration"></a>

**Causa:** a instância do EC2 de destino tem uma atualização de versão (RU) Oracle ou patches únicos diferentes do que a instância do RDS Custom de origem, causando erros de compatibilidade durante ou após a migração.

**Erros comuns:**
+ ORA-00600 Erros internos durante a aplicação de redo (Data Guard)
+ ORA-39700 O banco de dados deve ser aberto com a opção `UPGRADE`
+ Inconsistências do dicionário após a migração
+ Objetos inválidos em `DBA_REGISTRY` ou `DBA_OBJECTS`

 **Solução:** 

 **Prática recomendada - Combine exatamente as versões do RU e os patches únicos:** 

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;
   ```

1. Verifique o nível do patch de $ORACLE\_HOME:

   ```
   # On both instances
   $ORACLE_HOME/OPatch/opatch lsinventory
   ```

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

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

   ```
   cd $ORACLE_HOME/OPatch
   ./datapatch -verbose
   ```

1. 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;
   ```

### Problemas de conectividade de rede
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-network-connectivity"></a>

 

**Causa:** grupos de segurança, ACLs de rede ou bloqueio `iptables` da porta do receptor Oracle.

 **Solução:** 

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

1. Verifique iptables no EC2:

   ```
   sudo iptables -L INPUT -n -v
   ```

1. 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
   ```

1. Teste de conectividade:

   ```
   telnet {{<EC2_instance_IP>}} 1521
   tnsping DB_SOURCE
   tnsping DB_TARGET
   ```

### Os PDBs não abrem após a migração (somente multilocatário)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdbs-not-opening"></a>

**Causa:** esse comportamento é esperado. Após a duplicação do RMAN ou a transição do Data Guard, o CDB está aberto, mas os PDBs estão no estado `MOUNTED`.

 **Solução:** 

Abra-os manualmente:

```
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
```

Se um PDB específico não for aberto, verifique se há erros no log de alertas:

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

As causas comuns incluem arquivos de dados ausentes ou problemas de mapeamento de caminhos.

### Arquivos de dados do PDB não encontrados ou incompatibilidade de caminhos (somente multilocatário)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdb-data-files-not-found"></a>

**Causa:** a migração não mapeou todos os caminhos de origem de maneira correta, especialmente para arquivos de dados do PDB baseados em OMF.

 **Solução:** 

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

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

1. 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';
   ```

1. 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.

### Serviços do PDB não registrados no receptor (somente multilocatário)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdb-services-not-registering"></a>

**Causa:** o receptor não conhece os serviços do PDB depois de abrir os PDBs.

 **Solução:** 

1. Force o registro do serviço:

   ```
   SQL> ALTER SYSTEM REGISTER;
   ```

1. 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;
   ```

1. Verifique com:

   ```
   lsnrctl services
   ```

### Os PDBs não abrem automaticamente após a reinicialização do CDB (somente multilocatário)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdbs-not-opening-after-cdb-restart"></a>

**Causa:** o estado de salvamento do PDB não foi configurado.

 **Solução:** 

Verifique se o estado de salvamento do PDB foi configurado:

```
SQL> SELECT con_name, instance_name, state FROM dba_pdb_saved_states;
```

Se nenhuma linha for retornada, salve o estado:

```
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
SQL> ALTER PLUGGABLE DATABASE ALL SAVE STATE;
```

### O transporte de redo do Data Guard não está funcionando
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-odg-redo-transport-failure"></a>

**Causa:** problemas de conectividade de rede, configuração incorreta do TNS ou parâmetros FAL não definidos.

 **Solução:** 

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

   ```
   SQL> SELECT status FROM v$instance;
   ```

1. 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
   ```

1. Verifique a conectividade de rede:

   ```
   tnsping ORCL_A # or RDSCDB_A for multitenant
   ```

1. 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).

 **O atraso de aplicação do Data Guard está aumentando com vários PDBs (somente multilocatário)** 

**Causa:** para CDBs com vários PDBs, a aplicação de redo pode ser mais lenta devido ao volume de alterações em todos os contêineres.

 **Solução:** 

1. Verifique a taxa de aplicação:

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

1. 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;
   ```

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

 **O backup do log de arquivamento do RMAN falha com o ORA-19625** 

**Causa:** a automação do RDS Custom limpou logs de arquivamento mais antigos do disco, mas o arquivo de controle do RMAN ainda tem registros deles.

 **Solução:** 

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;
   ```

1. 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;
   }
   ```

### A queda comum de usuários falha em multilocatário (somente multilocatário)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-multitenant-user-drop-fails"></a>

 

**Causa:** usuários comuns (com o prefixo C\#\#) devem ser eliminados com a cláusula `CONTAINER=ALL`.

 **Solução:** 

```
-- For common users
SQL> DROP USER C##RDS_DATAGUARD CASCADE CONTAINER=ALL;

-- For non-common users in CDB$ROOT
SQL> DROP USER RDSADMIN CASCADE;
```

Verifique se você está conectado a `CDB$ROOT`:

```
SQL> SHOW CON_NAME;
```

## Tarefas pós-migração
<a name="RDS-Custom-for-Oracle-end-of-support-post-migration"></a>

Após a migração bem-sucedida, conclua essas tarefas adicionais para garantir que seu banco de dados Oracle autogerenciado no EC2 esteja pronto para produção.

 **Atualização de strings de conexão da aplicação** 

**Para não CDB:**
+ Direcionar seus aplicativos para o novo endpoint da instância do EC2
+ Atualizar as strings de conexão para usar o IP ou o nome do host da instância do EC2
+ Testar minuciosamente todas as funcionalidades do aplicativo

**Para multilocatário:**
+ Direcionar seus aplicativos para os novos nomes de serviços de PDB da instância do EC2 (por exemplo, ORCLDB ou seus nomes de PDB específicos)
+ Garantir que os aplicativos se conectem ao PDB correto, não ao CDB
+ Atualizar strings de conexão para usar nomes de serviços de PDB
+ Testar todas as funcionalidades do aplicativo para cada PDB

Exemplo de strings de conexão:

```
# Non-CDB
jdbc:oracle:thin:@{{<EC2_IP>}}:1521/ORCL

# Multitenant (connect to PDB)
jdbc:oracle:thin:@{{<EC2_IP>}}:1521/ORCLDB
```

 **Configurar a estratégia de backup** 

Configure uma estratégia abrangente de backup para seu banco de dados autogerenciado:

**Backups do RMAN:**
+ Configurar scripts de backup automatizados do RMAN para backups completos, incrementais e de log de arquivamento
+ Configurar políticas de retenção de backup com base em seus objetivos de ponto de recuperação (RPO)
+ Armazenar backups no Amazon S3 para maior durabilidade e economia
+ Testar regularmente os procedimentos de restauração de backup

**AWS Backup:**
+ Usar o [AWS Backup](https://aws.amazon.com/backup/) para instantâneos de volume do EBS
+ Configurar programações de backup e políticas de retenção
+ Ativar cópias de backup entre regiões para recuperação de desastres

**Para multilocatário:**
+ Os backups do RMAN do CDB incluem automaticamente todos os PDBs
+ Também é possível fazer backup de PDBs individuais, se necessário
+ Considere programações de backup específicas do PDB com base nos requisitos dos negócios

Exemplo de script de backup do RMAN:

```
#!/bin/bash
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
export ORACLE_SID=ORCL
export PATH=$ORACLE_HOME/bin:$PATH
rman target / << EOF
run {
  backup as compressed backupset database plus archivelog;
  delete noprompt obsolete;
}
exit;
EOF
```

 **Configurar o monitoramento** 

Implemente um monitoramento abrangente para seu banco de dados Oracle hospedado no EC2:

**Amazon CloudWatch**
+ Configurar métricas do CloudWatch para integridade da instância do EC2, uso de disco e métricas personalizadas do Oracle
+ Criar alarmes do CloudWatch para limites críticos
+ Usar o CloudWatch Logs para monitorar o log de alertas do banco de dados

**Oracle Enterprise Manager (OEM):**
+ Se disponível, configurar o OEM para monitoramento de banco de dados
+ Configurar o monitoramento e o diagnóstico de desempenho
+ Configurar alertas automatizados para eventos críticos

**Ferramentas de terceiros:**
+ Considerar ferramentas como Datadog, New Relic ou Prometheus para monitoramento de banco de dados
+ Integrar-se à sua infraestrutura de monitoramento existente

**Principais métricas a serem monitoradas:**
+ Uso de espaço de tabela
+ Espaço de log do arquivo
+ Objetos inválidos
+ Contagens de sessões
+ Eventos de espera
+ Utilização de CPU e memória
+ Performance de E/S

**Para multilocatário:**
+ Monitorar métricas no nível do CDB e no nível do PDB
+ Configurar alertas para o uso de recursos e cotas do PDB
+ Acompanhar métricas de desempenho específicas do PDB

 **Configurar grupos de segurança e ACLs de rede** 

Revise e reforce a segurança da instância do EC2:

**Grupos de segurança:**
+ Restringir o acesso às portas do banco de dados somente aos servidores de aplicativos autorizados e aos bastion hosts
+ Remover todas as regras excessivamente permissivas criadas durante a migração
+ Documentar as regras do grupo de segurança e as finalidades

**ACLs de rede:**
+ Configurar ACLs de rede da VPC para camadas adicionais de segurança
+ Implementar uma estratégia de segurança completa

**Acesso a SSH:**
+ Limitar o acesso a SSH a intervalos de IP específicos ou usar o AWS Systems Manager Session Manager
+ Desativar a autenticação por senha e usar somente a autenticação baseada em chave
+ Implementar autenticação multifator (MFA) para acesso privilegiado

**Criptografia:**
+ Habilitar a criptografia em repouso para volumes do EBS
+ Ativar a criptografia em trânsito para conexões de banco de dados usando o Oracle Native Network Encryption ou TLS
+ Alternar chaves de criptografia regularmente

**Implementar alta disponibilidade**

Se o workload exigir alta disponibilidade, implemente:

**Oracle Data Guard:**
+ Configurar um novo banco de dados em espera em outra instância do EC2 para recuperação de desastres
+ Para multilocatário, o Data Guard protege todo o CDB, incluindo todos os PDBs
+ O modo de espera pode estar em uma zona de disponibilidade ou região diferente
+ Implementar mecanismos de failover automatizados usando scripts ou ferramentas de terceiros

**Implantação Multi-AZ da AWS:**
+ Implementar instâncias em espera em Zonas de Disponibilidade diferentes
+ Usar o Amazon Route 53 para failover de DNS
+ Implementar o pool de conexões no nível do aplicativo com suporte a failover

**Backup e recuperação:**
+ Manter backups regulares com procedimentos de restauração testados
+ Documentar objetivos de tempo de recuperação (RTO) e objetivos de ponto de recuperação (RPO)
+ Realizar exercícios regulares de recuperação de desastres

**Realizar testes completos de aplicativos**

Antes de desativar a instância do RDS Custom:

**Teste funcional:**
+ Verificar se todos os recursos do aplicativo funcionam corretamente
+ Testar todas as funcionalidades dependentes do banco de dados
+ Validar a integridade e a consistência dos dados

**Testes de desempenho:**
+ Comparar as métricas de desempenho com a linha de base do RDS Custom
+ Identificar e resolver regressões de desempenho
+ Otimizar consultas e índices conforme necessário

**Testes de carga:**
+ Testar o banco de dados com as cargas de pico esperadas
+ Verificar se a utilização dos recursos permanece dentro dos limites aceitáveis
+ Identificar e resolver gargalos

**Teste de failover (se HA estiver configurado):**
+ Testar cenários de failover
+ Verificar a lógica de reconexão do aplicativo
+ Medir o RTO e o RPO reais

**Teste de backup e restauração:**
+ Verificar se os procedimentos de backup e restauração funcionam corretamente
+ Testar a recuperação para um ponto no tempo
+ Validar a integridade do backup

**Para multilocatário:**
+ Testar cada PDB de forma independente
+ Verificar o isolamento do PDB e a alocação de recursos
+ Testar operações específicas do PDB (clonar, desconectar/conectar etc.)

**Desativar instância do RDS Custom**

Após um período de validação bem-sucedido (normalmente de 1 a 2 semanas):

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
   ```

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

1. **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
   ```

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

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

## Comparação: duplicação ativa do RMAN x Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-RMAN-vs-ODG"></a>

A tabela a seguir resume as principais diferenças entre as duas opções de migração:


|  **Aspecto**  |  **Duplicação ativa do RMAN**  |  **Oracle Data Guard**  | 
| --- | --- | --- | 
| **Disponibilidade do banco de dados de origem** | Online durante toda a duplicação | Online durante todo o processo | 
| **Tempo de inatividade** | Minutos (somente a substituição final) | Segundos em minutos (transição) | 
| **Complexidade** | Menor | Mais alto | 
| **Duração da migração** | Operação de duplicação única | Configuração inicial \+ sincronização contínua | 
| **Sincronização contínua** | Não | Sim | 
| **Capacidade de fallback** | Manual (mantenha a origem funcionando) | Integrado (automático) | 
| **Teste antes da substituição** | Limitado (teste após duplicação) | Teste completo possível (o modo de espera pode ser testado) | 
| **Largura de banda de rede** | Alto durante a duplicação | Moderado (contínuo) | 
| **Impacto do banco de dados de origem** | Mínimo (operações de leitura) | Mínimo (reenvio) | 
| **Melhor para** | A maioria das migrações, substituição simples | É necessário um tempo de inatividade de missão crítica quase zero | 
| **Suporte não CDB** | Sim | Sim | 
| **Suporte multilocatário** | Sim (CDB inteiro) | Sim (CDB inteiro) | 
| **Estado do PDB pós-migração** | CDB aberto, PDBs MONTADOS | CDB aberto, PDBs MONTADOS | 
| **Requer RMAN** | Sim | Sim (para backup inicial na abordagem baseada em backup) | 
| **Requer o Data Guard** | Não | Sim | 
| **Nível de habilidade necessário** | Intermediário | Advanced (Avançado) | 
| **Processo de substituição** | Redirecionar aplicativos para o EC2 | Comando de transição \+ redirecionar aplicativos | 

## Comparação: migração de não CDB x multilocatário
<a name="RDS-Custom-for-Oracle-end-of-support-non-cdb-va-multitenant"></a>

 

A tabela a seguir resume as principais diferenças entre a migração de bancos de dados não CDB e multilocatário:


|  **Aspecto**  |  **Migração de não CDB**  |  **Migração de multilocatário (CDB com PDBs)**  | 
| --- | --- | --- | 
| **Tipo de banco de dados** | Instância única de não CDB (por exemplo, ORCL) | CDB (origem: RDSCDB, destino: ORCL) com CDB$ROOT \+ PDB$SEED \+ um ou mais PDBs | 
| **Escopo da migração** | Banco de dados único | CDB inteiro (todos os PDBs incluídos automaticamente) | 
| **Escopo de duplicação do RMAN** | Duplica um banco de dados único | Duplica o CDB inteiro (todos os contêineres) | 
| **Escopo do Data Guard** | Protege um banco de dados único | Protege o CDB inteiro (todos os PDBs incluídos automaticamente) | 
| **Arquivo de parâmetro** | Parâmetros de inicialização padrão | Deve incluir enable\_pluggable\_database = TRUE | 
| **Estado do banco de dados pós-migração** | O banco de dados é aberto no modo READ WRITE | O CDB abre no modo READ WRITE; os PDBs permanecem no estado MOUNTED | 
| **Abertura do PDB** | N/D | É necessário abrir manualmente todos os PDBs com ALTER PLUGGABLE DATABASE ALL OPEN | 
| **Abertura automática do PDB na inicialização** | N/D | É necessário configurar o estado de salvamento do PDB ou o gatilho de inicialização | 
| **Validação** | Verificações de banco de dados único | Deve validar o CDB e cada PDB individualmente | 
| **Limpeza específica do RDS** | Eliminar usuários/objetos de um banco de dados único | Eliminar usuários comuns de CDB$ROOT (em cascata para PDBs); manipular usuários de C\#\# | 
| **Configuração do TNS/receptor** | Serviço único para banco de dados | Serviço do CDB \+ serviços do PDB individuais registrados dinamicamente | 
| **Strings de conexão de aplicativo** | Conectar-se ao banco de dados único | Conectar-se a serviços do PDB individuais (não CDB) | 
| **Estratégia de backup** | Backup de banco de dados único | Fazer backup de CDB inteiro (inclui todos os PDBs) ou PDBs individuais | 
| **Gerenciamento de recursos** | Gerenciamento de recursos no nível do banco de dados | Gerenciamento de recursos no nível do CDB e do PDB com o Resource Manager | 
| **Complexidade** | Menor complexidade | Maior complexidade devido a vários contêineres e caminhos OMF | 

## Práticas recomendadas e orientações
<a name="RDS-Custom-for-Oracle-end-of-support-best-practices"></a>

Esta seção fornece as práticas recomendadas abrangentes para uma migração bem-sucedida do RDS Custom para Oracle para o EC2.

### Planejamento pré-migração
<a name="RDS-Custom-for-Oracle-end-of-support-best-practices-pre-migration"></a>

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

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

   Selecione um tipo de instância do EC2 com base nas características do workload:    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/RDS-Custom-for-Oracle-end-of-support.html)

    **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

1. Projete sua arquitetura de armazenamento:

   **Tipos de volume do EBS:**    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/UserGuide/RDS-Custom-for-Oracle-end-of-support.html)

   **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

1.  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)

### Práticas recomendadas para execução da migração
<a name="RDS-Custom-for-Oracle-end-of-support-migration-best-practices"></a>

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

1. **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

1. **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;
   ```

1. **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

### Otimização pós-migração
<a name="RDS-Custom-for-Oracle-end-of-support-best-practices-post-migration-optimization"></a>

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;
      ```

   1. 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)
      );
      ```

   1. 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
      ```

   1. 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
   ```

### Otimização de custos
<a name="RDS-Custom-for-Oracle-end-of-support-cost-optimization"></a>

 **1. Dimensionamento correto:** 

Após a migração, monitore e otimize os custos:
+ **Usar o AWS Cost Explorer** para analisar os custos do EC2 e do EBS
+ **Habilitar o AWS Compute Optimizer** para recomendações de tipo de instância
+ **Analisar as métricas do CloudWatch** para identificar recursos subutilizados
+ **Considerar as instâncias reservadas** ou os Savings Plans para workloads previsíveis

 **2. Otimização de armazenamento:** 
+ **Implementar políticas de ciclo de vida** para backups do S3 (mude para o Glacier após 30 dias)
+ **Excluir regularmente snapshots não utilizados do EBS**
+ **Usar gp3 em vez de gp2** para reduzir custos com o mesmo desempenho
+ **Separar e excluir volumes de backup** após a conclusão da migração

 **3. Automação do:** 
+ **Automatizar início/parada** de bancos de dados que não são de produção fora do horário comercial
+ **Usar o AWS Systems Manager** para gerenciamento de patches
+ **Implementar o ajuste de escala automático** para réplicas de leitura se estiver usando o Data Guard

## Conclusão
<a name="RDS-Custom-for-Oracle-end-of-support-conclusion"></a>

Essa orientação prescritiva forneceu estratégias detalhadas de migração para mover seus bancos de dados Oracle do Amazon RDS Custom para Oracle para bancos de dados Oracle autogerenciados no Amazon EC2. Com a suspensão do serviço do RDS Custom para Oracle em vigor em 31 de março de 2027, é importante planejar e executar sua migração com bastante antecedência.

 **Principais conclusões** 

 **Opções de migração:** 
+ **Duplicação ativa do RMAN**: ideal para a maioria das migrações, mantém o banco de dados de origem online durante a duplicação, requer apenas uma breve janela de substituição para o redirecionamento do aplicativo
+ **Oracle Data Guard**: ideal para workloads de missão crítica que exigem tempo de inatividade quase zero, fornecendo sincronização contínua e capacidade de transição integrada

 **Suporte compatível:** 
+ As duas opções de migração oferecem suporte a arquiteturas de não CDB (instância única tradicional) e multilocatário (CDB com PDBs)
+ Para multilocatário, os dois métodos lidam automaticamente com o CDB inteiro, incluindo todos os PDBs, em uma única operação
+ Os PDBs exigem abertura manual e configuração de abertura automática após a migração

 **Fatores críticos de sucesso:** 
+ Configuração de rede e conectividade adequadas entre origem e destino
+ Compatibilidade exata da versão (versão principal, versão secundária, atualização de lançamento e patches únicos)
+ Largura de banda da rede adequada para transferência de dados (RMAN) ou reenvio (Data Guard)
+ Compreensão de que a duplicação ativa do RMAN mantém a origem online - é necessária apenas uma breve substituição
+ Teste e validação completos antes de desativar a origem
+ Tarefas abrangentes pós-migração, incluindo backup, monitoramento e configuração de segurança

 **Próximas etapas:** 

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

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

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

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

1. Realizar validação e testes completos

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

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

 **Recursos adicionais** 
+ [Guia de usuário do Amazon RDS Custom para Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom.html)
+ [Documentação do Oracle Database](https://docs.oracle.com/en/database/)
+ [Documentação do Oracle RMAN](https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/)
+ [Documentação do Oracle Data Guard](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/)
+ [AWS Database Migration Service](https://aws.amazon.com/dms/)
+ [AWS Recomendações da](https://aws.amazon.com/prescriptive-guidance/)

 **Suporte a** 

Para obter ajuda com sua migração:
+ Entre em contato com o AWS Support por meio do AWS Management Console
+ Consulte o suporte da Oracle para perguntas específicas do banco de dados

## **Informações do documento**
<a name="RDS-Custom-for-Oracle-end-of-support-document-information"></a>

**Última atualização:** março de 2026

**Colaboradores:**
+ Sharath Chandra Kampili, arquiteto especialista em soluções de banco de dados, Amazon Web Services
+ Ibrahim Emara, arquiteto especialista em soluções de banco de dados, Amazon Web Services
+ Vetrivel Subramani, arquiteto especialista em soluções de banco de dados, Amazon Web Services