Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Fin du support de RDS Custom pour Oracle
<a name="RDS-Custom-for-Oracle-end-of-support"></a>

**Note**  
Avis de fin de support : le 31 mars 2027, le support d'Amazon RDS Custom pour Oracle AWS prendra fin. Après le 31 mars 2027, vous ne pourrez plus accéder à la console RDS Custom pour Oracle ni aux ressources RDS Custom pour Oracle. Pour de plus amples informations, veuillez consulter [Fin du support de RDS Custom pour Oracle](#RDS-Custom-for-Oracle-end-of-support).

## Présentation de
<a name="RDS-Custom-for-Oracle-end-of-support-overview"></a>

Après mûre réflexion, AWS a pris la décision de mettre fin au service Amazon RDS Custom for Oracle. Le service sera obsolète à compter du **31 mars 2027**. Ce guide prescriptif fournit des stratégies de migration détaillées pour vous aider à migrer de RDS Custom for Oracle vers des bases de données Oracle autogérées sur Amazon Elastic Compute Cloud (Amazon EC2).

### Principaux délais
<a name="RDS-Custom-for-Oracle-end-of-support-key_timelines"></a>
+ **Du 31 mars 2026 au 31 mars 2027** : nous vous recommandons de passer de RDS Custom for Oracle à Oracle on EC2. Pendant cette période, vous pouvez continuer à utiliser RDS Custom pour Oracle avec les fonctionnalités et le support existants.
+ **Après le 31 mars 2027** : vous ne pourrez plus utiliser le service RDS Custom for Oracle.

### Public cible
<a name="RDS-Custom-for-Oracle-end-of-support-target_audience"></a>

Ce guide est destiné aux personnes suivantes :
+ Administrateurs de base de données responsables des migrations de bases de données Oracle
+ Les architectes du cloud planifient des stratégies de migration
+ DevOps ingénieurs gérant l'infrastructure de base de données
+ Responsables informatiques supervisant le processus de migration

### Conditions préalables
<a name="RDS-Custom-for-Oracle-end-of-support-prerequisites"></a>

Avant de commencer, assurez-vous de disposer des éléments suivants :
+ Une instance Amazon RDS Custom for Oracle active exécutant Oracle 19c Enterprise Edition
+ Autorisations de gestion des AWS identités et des accès (IAM) appropriées pour créer et gérer des instances EC2
+ Compréhension de l'architecture de votre base de données (CDB non CDB ou CDB multilocataire avec PDB)
+ Planification de la connectivité réseau entre les instances source et cible
+ Stratégie de sauvegarde et de restauration pour votre migration

## Options de migration
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options"></a>

Dans le cadre du processus de migration, vous pouvez choisir l'une des deux options de migration en fonction des besoins de votre entreprise et de votre cas d'utilisation :

### Option 1 : Duplication active RMAN (Online/Offline migration)
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-RMAN"></a>

**Le mieux adapté pour**
+ Charges de travail pouvant entraîner des temps d'arrêt planifiés lors du passage final
+ Simplification des exigences de migration avec moins de pièces mobiles
+ Bases de données pour lesquelles vous souhaitez une migration simple et unique
+ Scénarios dans lesquels vous n'avez pas besoin d'une synchronisation continue avant le passage

**Principales caractéristiques**
+ Temps **d'arrêt** : temps d'arrêt minimal lors du passage final (la base de données reste en ligne pendant la duplication, bref temps d'arrêt pour le passage final)
+ **Complexité** : réduction de la complexité grâce à la duplication directe des bases de données
+ **Durée** : le temps de migration dépend de la taille de la base de données et de la bande passante du réseau
+ **Solution de rechange** : nécessite de maintenir la base de données source jusqu'à ce que la validation soit terminée
+ **Fonctionnalité en ligne** : la base de données source reste en ligne et accessible pendant le processus de duplication

**Approche de migration :** la duplication active RMAN crée une copie exacte de la base de données source sur la cible en copiant les fichiers de base de données sur le réseau à partir de la base de données source active en cours d'exécution. La base de données source reste en ligne et accessible aux applications pendant le processus de duplication. Pour les bases de données mutualisées, RMAN duplique automatiquement l'intégralité du CDB, y compris`CDB$ROOT`, ainsi que toutes les bases de données enfichables`PDB$SEED`, en une seule opération. Seule une brève fenêtre de transition est nécessaire pour rediriger les applications vers la nouvelle instance EC2.

### Option 2 : Oracle Data Guard (migration en ligne)
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-Oracle-Data-Guard"></a>

**Le mieux adapté pour**
+ Charges de travail de production nécessitant des temps d'arrêt minimaux
+ Mission-critical bases de données qui doivent rester disponibles
+ Scénarios dans lesquels vous avez besoin d'une synchronisation continue avant le passage
+ Migrations nécessitant une fonctionnalité de repli intégrée

**Principales caractéristiques**
+ **Temps d'arrêt** : Near-zero temps d'arrêt (de quelques secondes à quelques minutes pour le passage au numérique)
+ **Complexité** : complexité accrue grâce à la configuration Data Guard
+ **Durée** : temps de configuration initial plus synchronisation continue jusqu'au passage au numérique
+ Solution de **secours** : capacité de Built-in repli en conservant la source en mode veille

**Approche de migration :** Oracle Data Guard gère une base de données de secours synchronisée en expédiant et en appliquant en permanence des journaux redo à partir de la base de données principale. Lorsque vous êtes prêt à terminer la migration, vous effectuez une transition qui fait passer le mode veille de l'EC2 au mode principal avec un temps d'arrêt minimal. Pour les bases de données mutualisées, Data Guard protège automatiquement l'ensemble de la CDB, y compris toutes les PDB.

 **Matrice de décision** 

Utilisez la matrice suivante pour vous aider à choisir l'option de migration appropriée :


|  **Aspect**  |  **Duplication active RMAN**  |  **Oracle Data Guard**  | 
| --- | --- | --- | 
| **Disponibilité de la base de données source** | En ligne pendant la duplication | En ligne pendant tout le processus | 
| **Temps d'arrêt acceptable** | Minutes à heures (coupure finale) | Quelques secondes à quelques minutes (commutation) | 
| **Complexité des migrations** | Inférieur | Supérieur | 
| **Synchronisation continue** | Non | Oui | 
| **Capacité de repli** | Manuel (conserver la source) | Built-in (automatique) | 
| **Tests avant le passage** | Limité | Possibilité de tests complets | 
| **Besoins en bande passante réseau** | Élevé lors de la duplication | Modéré (continu) | 
| **Idéal pour** | La plupart des migrations dev/test, transition planifiée | Production, activité critique, temps d'arrêt quasi nul | 

### Considérations concernant l'architecture
<a name="RDS-Custom-for-Oracle-end-of-support-migration_options-architecture-considerations"></a>

Les deux options de migration prennent en charge deux architectures de base de données Oracle :

 **Non-CDB** 

Bases de données Oracle à instance unique traditionnelles sans architecture mutualisée. Ces bases de données :
+ Disposer d'une seule instance de base de données
+ N'utilisez pas de bases de données enfichables (PDB)
+ Sont plus simples à gérer et à migrer
+ Généralement nommé ORCL dans RDS Custom pour Oracle

 **Multitenant (CDB avec PDB)** 

Bases de données conteneurs (CDB) hébergeant plusieurs bases de données enfichables (PDB), introduites dans Oracle 12c. Ces bases de données :
+ Disposer d'une base de données de conteneurs (CDB) avec et `CDB$ROOT` `PDB$SEED`
+ Héberger une ou plusieurs bases de données enfichables (PDB)
+ Assure la consolidation des bases de données et l'isolation des ressources
+ Généralement nommé RDSCDB dans RDS Custom pour Oracle
+ Utiliser Oracle Managed Files (OMF) avec des GUID-based sous-répertoires pour les fichiers de données PDB

**Remarque importante pour les migrations mutualisées** : la base de données cible sera renommée ORCL au cours du processus de migration (source : RDSCDB → cible : ORCL). Cela simplifie la configuration de la cible et s'aligne sur les conventions de dénomination standard.

 **Principales différences dans l'approche de la migration** 


|  **Aspect**   |  **Non-CDB**  |  **Multitenant (CDB avec PDB)**  | 
| --- | --- | --- | 
| **Étendue de la migration** | Base de données unique | CDB entier avec tous les PDB | 
| **Post-migration state**  | Base de données ouverte READ WRITE | CDB ouvert READ WRITE ; PDB à l'état MOUNTÉ | 
| **Gestion du PDB** | N/A | Doit ouvrir les PDB et configurer l'ouverture automatique | 
| **Nettoyage** | Base de données unique | CDB$ROOT(cascades vers des PDB) ; gérez les utilisateurs courants en C\#\# | 
| **Connexions aux applications** | Service de base de données | Services PDB (pas CDB) | 
| **Fichier de paramètres** | Paramètres standard | Nécessite ENABLE\_PLUGGABLE\_DATABASE=True | 
| **Complexité** | Inférieur | Plus élevé en raison de la présence de plusieurs conteneurs | 

## Conditions préalables communes aux deux options de migration
<a name="RDS-Custom-for-Oracle-end-of-support-common-prerequisites"></a>

Avant de démarrer l'une ou l'autre des options de migration, effectuez les étapes préalables suivantes :

1. Lancer et configurer l'instance EC2

   Lancez une instance EC2 en tenant compte des considérations suivantes :
   + **Type d'instance** : choisissez un type d'instance EC2 qui répond aux besoins en ressources de votre charge de travail. L'utilisation de la même classe d'instance que votre instance RDS Custom constitue un bon point de départ. Tenez compte des exigences en matière de mémoire, de processeur et de bande passante réseau.
   + **Système d'exploitation** : Oracle Linux ou Red Hat Enterprise Linux (correspondant ou compatible avec votre version de système d'exploitation personnalisée RDS)
   + **Logiciel Oracle** : installez le logiciel de base de données Oracle (même version majeure, version mineure, mise à jour et, idéalement, mêmes correctifs ponctuels que RDS Custom). Assurez-vous que le logiciel Oracle est installé dans u01/app /oracle/ ou à l'emplacement de votre choix.
   + **Stockage** : configurez les volumes Amazon EBS avec une taille et des IOPS appropriées pour répondre aux exigences de votre charge de travail. Envisagez d'utiliser des volumes gp3 pour des performances économiques ou io2 Block Express pour des charges de travail à hautes performances.

1. Configuration de l'architecture de stockage

   1. Stockage du système de fichiers (recommandé pour la plupart des scénarios)
      + Utiliser des répertoires de système de fichiers standard pour les fichiers de données Oracle
      + Plus simple à gérer et adapté à la plupart des charges de travail
      + Ce guide utilise des exemples de stockage de systèmes de fichiers

   1. Gestion automatique du stockage Oracle (ASM)
      + Si votre charge de travail nécessite ASM, installez et configurez ASM autonome sur l'instance EC2
      + Ajustez tous les paramètres de chemin dans le fichier d'initialisation en conséquence pour utiliser les groupes de disques ASM (par exemple, \+DATA, \+FRA)
      + Le processus de migration est similaire pour ASM, avec des ajustements de trajectoire

1. Configurer le mécanisme de transfert de fichiers

   Créez un mécanisme pour transférer des fichiers entre les instances RDS Custom et EC2. Vous avez plusieurs options:

   1. Option A : Amazon S3 (recommandé pour la plupart des scénarios)
      + Créez un compartiment Amazon S3 ou utilisez un compartiment existant
      + Installation et configuration de la AWS CLI sur les deux instances
      + Pour obtenir des instructions, voir [Commencer avec le AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html).

   1. Option B : directe SCP/SFTP
      + Si les ports SSH sont ouverts entre les instances, vous pouvez transférer des fichiers directement
      + Convient aux petits fichiers tels que les fichiers de paramètres et les fichiers de mots de passe

   1. Option C : Amazon EFS
      + Si Amazon EFS est déjà monté sur les deux instances, vous pouvez l'utiliser comme système de fichiers partagé
      + Adapté aux environnements dotés d'une infrastructure EFS existante

      Ce guide utilise Amazon S3 à titre d'exemple, mais vous pouvez adapter les commandes à la méthode que vous avez choisie.

1. Configuration de la connectivité réseau

   Garantissez la connectivité réseau entre les instances RDS Custom et EC2 :
   + **Même VPC** : les groupes de sécurité doivent autoriser le trafic bidirectionnel sur le port du récepteur Oracle (par défaut 1521, ou votre port personnalisé)
   + **Différents VPC (même compte)** : configurez le peering VPC et configurez les tables de routage et les groupes de sécurité
   + **Différents comptes** : configurez le peering VPC entre les comptes ou utilisez Transit Gateway AWS 
   + **Vérifier la connectivité** : utilisez le ping et le telnet pour tester la connectivité sur le port de base de données

1. Création d'une structure de répertoire sur EC2

   La structure du répertoire dépend de l'architecture de votre base de données :  
**Example Pour Non-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 Pour le multilocataire (CDB avec PDB)**  

   ```
   # 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
   ```
**Note**  
RDS Custom for Oracle utilise Oracle Managed Files (OMF) pour les fichiers de données PDB avec des GUID-based sous-répertoires (par exemple,). `/rdsdbdata/db/pdb/RDSCDB_A/{{{GUID}}}/datafile/` Le processus de migration créera automatiquement la structure de sous-répertoires nécessaire sur la cible. Il vous suffit de créer les répertoires parents.

   **Stratégie de stockage** : envisagez d'utiliser un volume EBS distinct pour/u01/app/oracle/backup afin de le détacher et de le supprimer facilement une fois la migration terminée, afin de réduire les coûts de stockage.

1. Vérifier la configuration de la base de données source

Avant de commencer la migration, vérifiez la configuration de votre base de données source :

1. Connectez-vous à l'hôte de base de données RDS Custom en tant qu'utilisateur rdsdb et définissez l'environnement :  
**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. Connectez-vous à la base de données et vérifiez l'architecture :  
**Example**  

   ```
   sqlplus / as sysdba
   SQL> SELECT name, cdb, open_mode, log_mode FROM v$database;
   ```  
**Example Pour Non-CDB, résultat attendu**  

   ```
   NAME CDB OPEN_MODE                 LOG_MODE
   --------- --- -------------------- ------------
   ORCL NO  READ  WRITE               ARCHIVELOG
   ```  
**Example Pour Multitenant (CDB), résultat attendu :**  

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

1. **Si vous avez une CDB à locataires multiples, listez toutes les PDB** et leur statut :  
**Example**  

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

   Résultat attendu (exemple avec 1 PDB nommé ORCLDB) :  
**Example**  

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

1. Vérifiez la taille totale de la base de données :  
**Example Pour Non-CDB :**  

   ```
   SQL> SELECT SUM(bytes)/1024/1024/1024 AS total_size_gb FROM dba_data_files;
   ```  
**Example Pour le multilocataire :**  

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

## Option 1 : Migration physique à l'aide de RMAN Active Duplication
<a name="RDS-Custom-for-Oracle-end-of-support-option-1"></a>

**Topics**
+ [Quand utiliser la duplication active RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-when-to-use)
+ [Vue d'ensemble de la duplication active RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-overview)
+ [Flux de travail de migration pour la duplication active RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-migration-workflow)
+ [Étape 1 : Suspendre l'automatisation personnalisée d'Amazon RDS](#RDS-Custom-for-Oracle-end-of-support-option-1-step-1)
+ [Étape 2 : Création de fichiers de mots de passe et de paramètres](#RDS-Custom-for-Oracle-end-of-support-option-1-step-2)
+ [Étape 3 : Transférer des fichiers vers EC2](#RDS-Custom-for-Oracle-end-of-support-option-1-step-3)
+ [Étape 4 : Modifier le fichier de paramètres sur EC2](#RDS-Custom-for-Oracle-end-of-support-option-1-step-4)
+ [Étape 5 : Configuration du TNS et de l'écouteur](#RDS-Custom-for-Oracle-end-of-support-option-1-step-5)
+ [Étape 6 : démarrer la base de données `NOMOUNT` sur EC2](#RDS-Custom-for-Oracle-end-of-support-option-1-step-6)
+ [Étape 7 : effectuer une duplication active RMAN](#RDS-Custom-for-Oracle-end-of-support-option-1-step-7)
+ [Étape 8 : Ouvrez les PDB (multitenant uniquement)](#RDS-Custom-for-Oracle-end-of-support-option-1-step-8)
+ [Étape 9 : Supprimer les objets personnalisés RDS](#RDS-Custom-for-Oracle-end-of-support-option-1-step-9)
+ [Étape 10 : Configuration du démarrage automatique](#RDS-Custom-for-Oracle-end-of-support-option-1-step-10)
+ [Étape 11 : Validation finale](#RDS-Custom-for-Oracle-end-of-support-option-1-step-11)

Cette section fournit des étapes détaillées pour migrer votre base de données Oracle de RDS Custom for Oracle vers EC2 à l'aide de la duplication active RMAN. Cette méthode est dupliquée à partir d'une base de données active et active, en gardant la source en ligne et accessible pendant le processus de migration.

### Quand utiliser la duplication active RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-when-to-use"></a>

Choisissez la duplication active RMAN lorsque :
+ Vous souhaitez que la base de données source reste en ligne et accessible pendant la migration
+ Vous pouvez vous permettre une brève période de transition pour la redirection finale de l'application
+ Vous souhaitez un processus de migration simple avec moins de pièces mobiles
+ La taille de votre base de données et la bande passante de votre réseau permettent un temps de duplication raisonnable
+ Vous n'avez pas besoin d'une synchronisation continue avant le passage
+ Vous migrez des bases de données de production, de développement ou de test

### Vue d'ensemble de la duplication active RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-overview"></a>

La duplication active RMAN ne nécessite pas de sauvegarde de la base de données source ni de mise hors ligne de la base de données source. Il duplique la base de données source active et active vers la destination en copiant les fichiers de base de données sur le réseau alors que la source reste en ligne et accessible aux applications.

**Principaux avantages :**
+ **La source reste en ligne** : les applications peuvent continuer à accéder à la base de données source pendant la duplication
+ **Aucune sauvegarde requise** : élimine le besoin de stockage de sauvegarde intermédiaire
+ **Transfert réseau direct** : les fichiers de base de données sont copiés directement de la source vers la cible
+ **Cohérence automatique : RMAN garantit la cohérence** de la base de données dupliquée
+ **Opération unique** : pour le multitenant, duplique l'intégralité du CDB, y compris tous les PDB, en une seule opération

Le processus de duplication crée une copie exacte de la base de données source sur la cible, y compris tous les fichiers de données, les fichiers de contrôle et les journaux de restauration. La base de données source continue de répondre aux demandes des applications tout au long du processus de duplication. Seule une brève fenêtre de transition est nécessaire à la fin pour rediriger les applications de la source vers la cible.

**Chronologie typique**

1. **Phase de duplication (la** source reste en ligne) : 30 minutes à plusieurs heures selon la taille de la base de données

1. **Phase de validation (la** source reste en ligne) : plusieurs heures, voire plusieurs jours, selon les besoins

1. **Phase de** transition (bref temps d'arrêt) : quelques minutes pour rediriger les applications vers EC2

### Flux de travail de migration pour la duplication active RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-migration-workflow"></a>

**Étapes de l'instance de base de données personnalisée RDS (source) :**

1. Suspendre l'automatisation personnalisée d'Amazon RDS

1. Vérifier l'architecture de la base de données (non CDB ou CDB avec PDB)

1. Création d'un fichier de mots de passe et d'un fichier de paramètres à partir de la base de données source

1. Copiez le fichier de mot de passe et le fichier de paramètres sur l'instance EC2 cible

1. Vérifiez que la base de données source s'exécute en mode journal d'archivage

1. Configurer tnsnames.ora sur le serveur de base de données personnalisé RDS

**Étapes de l'instance de base de données EC2 (cible) :**

1. Modifier le fichier de paramètres pour EC2 (spécifique à l'architecture)

1. Configurer tnsnames.ora sur EC2

1. Configuration de l'environnement pour l'instance EC2

1. Configuration d'Oracle Listener sur EC2

1. Démarrez la base de données sur EC2 dans l'état NOMOUNT

**Étapes de duplication RMAN :**

1. Réaliser une duplication active RMAN

1. Ouvrez la base de données (et les PDB pour le multitenant)

1. Configurer l'ouverture automatique de PDB (multitenant uniquement)

1. Supprimer des utilisateurs et des objets spécifiques à RDS Custom

1. Création d'un fichier SPFILE et configuration du démarrage automatique

1. Reprendre l'automatisation personnalisée d'Amazon RDS à la source (si vous la maintenez active)

### Étape 1 : Suspendre l'automatisation personnalisée d'Amazon RDS
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-1"></a>

Interrompez le mode d'automatisation sur votre instance RDS Custom avant de poursuivre les étapes de migration afin de vous assurer que l'automatisation n'interfère pas avec l'activité RMAN. Le paramètre --resume-full-automation-mode-minute (240 minutes = 4 heures dans cet exemple) doit être ajusté en fonction de la taille de votre base de données et du temps de duplication prévu.

**Important** : La suspension de l'automatisation n'affecte pas la disponibilité de la base de données. La base de données reste en ligne et accessible aux applications pendant le processus de duplication.

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

Validez l'état de l'automatisation :

**Example**  

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

Résultat attendu : "`all-paused`»

### Étape 2 : Création de fichiers de mots de passe et de paramètres
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-2"></a>

Créez un fichier de mots de passe à l'aide de`orapwd`. Récupérez le mot de passe SYS dans AWS Secrets Manager (stocké lors de la création de l'instance personnalisée RDS).

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

Créez un fichier de paramètres à partir de la base de données source :

**Example**  

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

Le fichier de paramètres généré contiendra les Custom-specific chemins et les paramètres RDS. Pour le multilocataire, les principaux paramètres sont les suivants :
+ `enable_pluggable_database`= `TRUE` (essentiel pour le multilocataire)
+ `noncdb_compatible`= `TRUE` (pour la rétrocompatibilité)
+ Chemins de fichiers de données pour `CDB$ROOT``PDB$SEED`, et toutes les PDB
+ `db_create_file_dest`et `db_create_online_log_dest_1` pour OMF

### Étape 3 : Transférer des fichiers vers EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-3"></a>

Choisissez votre méthode de transfert de fichiers préférée. Ce guide utilise Amazon S3 à titre d'exemple.

 **À l'aide d'Amazon S3 :** 

#### À l'aide d'Amazon S3 :
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-3-ec2"></a>

**Example Pour Non-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 Pour les locataires multiples**  

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

Validez les fichiers sur EC2 :

**Example**  

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

### Étape 4 : Modifier le fichier de paramètres sur EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-4"></a>

Le fichier de paramètres doit être modifié avec soin pour garantir la réussite de la migration. Il s'agit de l'une des étapes les plus critiques du processus de migration.

Modifiez `$ORACLE_HOME/dbs/initORCL.ora` l'instance EC2 et apportez les modifications essentielles suivantes :

1. **Mettre à jour le nom de la base** de données : pour le multitenant, remplacez toutes les occurrences de RDSCDB par ORCL

1. **Convertissez les chemins personnalisés RDS en chemins EC2 : remplacez /rdsdbdata/** par /oracle/ u01/app

1. 

**Supprimer les paramètres RDS Custom-specific**
   + `dg_broker_config_file1`et `dg_broker_config_file2` (si présent, indique l'existence d'une réplique)
   + `standby_file_management`(si présent)
   + `spfile`(nous créerons un nouveau SPFILE ultérieurement)
   + Tous `log_archive_dest` les paramètres pointant vers des destinations de secours (à conserver uniquement `log_archive_dest_1` pour l'archivage local)

1. **Ajouter des paramètres de conversion de nom de fichier** (voir ci-dessous)

1. **Ajustez les paramètres de mémoire** en fonction de la taille de votre instance EC2 (facultatif mais recommandé)

**Comprendre les paramètres de conversion des noms de fichiers :** 

Les `LOG_FILE_NAME_CONVERT` paramètres `DB_FILE_NAME_CONVERT` et sont essentiels pour la duplication RMAN. Ils indiquent à RMAN comment mapper les chemins des fichiers source aux chemins des fichiers cibles pendant le processus de duplication. Sans ces paramètres, RMAN tentera de créer des fichiers dans les mêmes chemins que la source, ce qui échouera sur EC2.

**Considérations clés :**
+ Chaque paramètre accepte des paires de chaînes : chemin source suivi du chemin cible
+ Plusieurs paires peuvent être spécifiées dans un seul paramètre
+ Pour le multitenant, vous devez mapper les chemins pour `CDB$ROOT``PDB$SEED`, et toutes les PDB
+ L'ordre des paires est important : RMAN les traite dans l'ordre indiqué
+ Les chemins distinguent les majuscules et minuscules et doivent correspondre exactement

**Mappages de chemins :**


**Non-CDB:**  

|  **Chemin personnalisé RDS**  |  **chemin EC2**  |  **Description**  | 
| --- | --- | --- | 
| /rdsdbbin | /u01/app/oracle | Base Oracle | 
| /rdsdbdata/db/ORCL\_A/datafile/ | /u01/app/oracle/oradata/ORCL/datafile/ | Fichiers de données | 
| /rdsdbdata/db/ORCL\_A/controlfile/ | /u01/app/oracle/oradata/ORCL/controlfile/ | Fichiers de contrôle | 
| /rdsdbdata/db/ORCL\_A/onlinelog/ | /u01/app/oracle/oradata/ORCL/onlinelog/ | Redo logs en ligne | 
| /rdsdbdata/db/ORCL\_A/arch/ | /u01/app/oracle/oradata/ORCL/arch/ | Journaux d'archivage | 
| /rdsdbdata/admin/ORCL/adump | /u01/app/oracle/admin/ORCL/adump | Dump d'audit | 
| /rdsdbdata/log | /u01/app/oracle | Destination diagnostique | 


**Locataires multiples**  

|  **Chemin personnalisé RDS**  |  **chemin EC2**  |  **Description**  | 
| --- | --- | --- | 
| /rdsdbbin | /u01/app/oracle | Base Oracle | 
| /rdsdbdata/db/cdb/RDSCDB/datafile/ | /u01/app/oracle/oradata/ORCL/cdb/datafile/ | fichiers de données racine CDB | 
| /rdsdbdata/db/cdb/pdbseed/ | /u01/app/oracle/oradata/ORCL/pdbseed/datafile/ | PDB$SEEDfichiers de données | 
| /rdsdbdata/db/pdb/RDSCDB\_A/ | /u01/app/oracle/oradata/ORCL/pdb/datafile/ | Fichiers de données PDB (OMF avec GUID) | 
| /rdsdbdata/db/cdb/RDSCDB\_A/controlfile/ | /u01/app/oracle/oradata/ORCL/controlfile/ | Fichiers de contrôle | 
| /rdsdbdata/db/cdb/RDSCDB\_A/onlinelog/ | /u01/app/oracle/oradata/ORCL/onlinelog/ | Redo logs en ligne | 
| /rdsdbdata/db/cdb/RDSCDB\_A/arch/redolog | /u01/app/oracle/oradata/ORCL/arch/ | Journaux d'archivage | 
| /rdsdbdata/admin/RDSCDB/adump | /u01/app/oracle/admin/ORCL/adump | Dump d'audit | 
| /rdsdbdata/log | /u01/app/oracle | Destination diagnostique | 

**Ajoutez des paramètres de conversion :**

**Example Non-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 **Multitenant** (doit inclure les mappages pour la racine CDB et tous les `PDB$SEED` chemins 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/'
```

**Important** : pour le multitenant, assurez-vous que `enable_pluggable_database` = `TRUE` est présent dans le fichier de paramètres. RDS Custom utilise OMF pour les fichiers de données PDB contenant des GUID-based sous-répertoires. Le mappage des chemins gère cela automatiquement.

 **Fichiers d'exemple complets de paramètres :** 

**Example Exemple de fichier de Non-CDB paramètres (`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 Exemple de fichier de paramètres multitenant (`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/'
```

**Explications des paramètres clés :**
+ `enable_pluggable_database=TRUE`: Obligatoire pour le CDB multitenant. Ce paramètre active la fonctionnalité de base de données enfichable.
+ `noncdb_compatible=TRUE`: défini par RDS Custom à des fins de rétrocompatibilité. Peut être conservé ou retiré en fonction de vos besoins.
+ `db_create_file_dest`: Spécifie l'emplacement par défaut pour Oracle Managed Files (OMF). Pour le multitenant, cela pointe vers le répertoire des fichiers de données PDB.
+ `db_create_online_log_dest_1`: Spécifie l'emplacement des journaux de restauration en ligne lors de l'utilisation d'OMF.
+ `DB_FILE_NAME_CONVERT`: essentiel pour la duplication de RMAN. Fait correspondre les chemins des fichiers de données source aux chemins cibles.
+ `LOG_FILE_NAME_CONVERT`: mappe les chemins du journal redo source vers les chemins cibles.
+ `memory_target`et `memory_max_target` : ajustez-les en fonction de la mémoire de votre instance EC2. Les valeurs indiquées sont des exemples.
+ `processes`: nombre maximum de processus du système d'exploitation qui peuvent se connecter à Oracle. Ajustez en fonction de votre charge de travail.

**Consignes relatives au dimensionnement de la mémoire :**

Lorsque vous ajustez les paramètres de mémoire de votre instance EC2 :


|  **Mémoire d'instance EC2**  |  **Memory\_target recommandé**  |  **Memory\_max\_target recommandé**  | 
| --- | --- | --- | 
| 16 Go | 12 Go (12884901888 octets) | 14 Go (15032385536 octets) | 
| 32 GO | 24 Go (25769803776 octets) | 28 Go (30064771072 octets) | 
| 64 Go | 48 Go (51539607552 octets) | 56 Go (60129542144 octets) | 
| 128 Go | 96 Go (103079215104 octets) | 112 Go (120259084288 octets) | 

Laissez environ 20 à 25 % de la mémoire système pour le système d'exploitation et les autres processus.

### Étape 5 : Configuration du TNS et de l'écouteur
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-5"></a>

Dans les deux cas, ajoutez des entrées TNS à `tnsnames.ora` :

**Example Non-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 Multilocataire :**  

```
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 Configurer l'écouteur sur 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 Démarrez l'écouteur :**  

```
lsnrctl start
```

**Note**  
Pour la duplication active RMAN, les entrées TNS se connectent à l'instance de base de données à l'aide du SID (et non de SERVICE\_NAME). Pour le multilocataire, cela se connecte à la CDB, et RMAN duplique automatiquement toutes les PDB.

### Étape 6 : démarrer la base de données `NOMOUNT` sur 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 Vérifiez les paramètres :**  

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

### Étape 7 : effectuer une duplication active RMAN
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-7"></a>

RMAN Active Duplication copie la base de données de la source active et en cours d'exécution vers la cible. La base de données source reste en ligne et accessible aux applications tout au long de ce processus.

Connectez RMAN aux instances source et cible :

**Example**  

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

**Example Résultat attendu pour les produits non 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 Résultat attendu pour le multitenant :**  

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

**Example Exécutez la commande de duplication active :**  

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

**Note**  
La **source reste en ligne** : la base de données source continue de répondre aux demandes des applications pendant la duplication
**Pour les non-CDB** : cela duplique l'intégralité de la base de données tant qu'elle reste en ligne
**Pour le multitenant** : cela permet de dupliquer l'intégralité du CDB`CDB$ROOT`, y compris`PDB$SEED`, et tous les PDB en une seule opération, tandis que la source reste en ligne
**NOFILENAMECHECK** : permet à RMAN de continuer même si les noms de fichiers diffèrent entre la source et la cible
**Durée** : dépend de la taille de la base de données et de la bande passante du réseau. Pour une base de données de 100 Go, comptez 30 à 60 minutes
**Impact sur le réseau :** utilisation élevée de la bande passante réseau pendant la duplication, mais la base de données source reste accessible

**Le processus de duplication active RMAN comprend plusieurs phases :**

1. Connexion aux bases de données source et cible

1. Création d'une mémoire `SPFILE` à partir de la cible

1. Restauration du fichier de contrôle sur la cible

1. Montage de la base de données cible

1. Copier tous les fichiers de données de la source vers la cible via le réseau (la source reste en ligne)

1. Restauration de la base de données cible

1. Ouverture de la base de données cible avec `RESETLOGS`

**Lors de la duplication, la base de données source :**
+ Reste en `READ WRITE` mode
+ Continue d'accepter les connexions
+ Traite les transactions normalement
+ Génère des journaux de redo normalement
+ Est entièrement accessible aux applications

**Example Suivez les progrès lors d'une autre session :**  

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

 **Surveillance détaillée et résolution des problèmes lors de la duplication RMAN :** 

Lorsque la duplication RMAN est en cours d'exécution, vous pouvez suivre sa progression à l'aide de plusieurs méthodes :

1. **Sortie RMAN du moniteur :**

   La session RMAN affichera des informations de progression détaillées, notamment :
   + Allocation de chaînes
   + Progression de la copie du fichier de données
   + Temps de réalisation estimé
   + Octets traités

   ```
   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 Exemple de sortie :**  

   ```
   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.  **Surveillez les opérations de longue durée :**   
**Example Dans une session SQL\*Plus distincte sur l'instance EC2 cible :**  

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

**Cette requête indique :**
   + `opname`: nom de l'opération (par exemple, « RMAN : restauration complète des fichiers de données »)
   + `sofar`: Blocs traités jusqu'à présent
   + `totalwork`: nombre total de blocs à traiter
   + `pct_complete`: Pourcentage terminé
   + `time_remaining`: nombre estimé de secondes restantes
   + `elapsed_seconds`: Temps écoulé jusqu'à présent

1. **Surveillez les canaux 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. **Vérifiez le journal des alertes :**  
**Example Sur l'instance EC2 cible, surveillez le journal des alertes pour détecter toute erreur ou tout avertissement :**  

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

**Problèmes courants lors de la duplication RMAN :**
   + **Délai d'expiration du réseau**

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

     **Solution** : augmentez les valeurs de délai d'expiration du réseau dans `sqlnet.ora` les deux instances :

     ```
     SQLNET.RECV_TIMEOUT=600
     SQLNET.SEND_TIMEOUT=600
     ```
   + **Espace insuffisant sur la cible**

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

     **Solution** : Vérifiez l'espace disponible et augmentez la capacité du volume EBS :

     ```
     df -h /u01/app/oracle/oradata
     ```
   + **Erreurs dans les fichiers de paramètres**

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

     **Solution** : Vérifiez que tous les répertoires du fichier de paramètres existent et disposent des autorisations appropriées.
   + **Incompatibilité du fichier de mots de passe**

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

     **Solution** : assurez-vous que le fichier de mots de passe de la cible correspond à la source et porte le nom correct (`orapwORCL`).

### Étape 8 : Ouvrez les PDB (multitenant uniquement)
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-8"></a>

Une fois la duplication RMAN terminée, le CDB sur EC2 est ouvert en `READ WRITE` mode, mais tous les PDB sont en état. `MOUNTED` C'est un comportement attendu : vous devez les ouvrir manuellement.

Vérifiez l'état actuel du PDB :

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

Résultat attendu (exemple avec un PDB nommé`ORCLDB`) :

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

Ouvrez tous les PDB :

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

Vérifiez que tous les PDB sont désormais ouverts en `READ WRITE` mode :

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

Sortie attendue :

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

Configurez l'ouverture automatique au démarrage à l'aide de la méthode d'enregistrement de l'état (recommandée pour Oracle 19c) :

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

Cela indique à Oracle de mémoriser l'état ouvert actuel des PDB et de le restaurer au démarrage de la CDB.

Vérifiez l'état enregistré :

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

Vérifiez que les services PDB sont enregistrés auprès de l'écouteur :

```
lsnrctl services
```

Le résultat attendu doit indiquer les services fournis au CDB et à chaque PDB. Si les services ne s'affichent pas :

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

Vérifiez ensuite à nouveau avec`lsnrctl services`.

### Étape 9 : Supprimer les objets personnalisés RDS
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-9"></a>

Comme il s'agit désormais d'une base de données autogérée sur EC2, vous devez supprimer les Custom-specific utilisateurs et les objets RDS. Le processus de nettoyage diffère entre les architectures non CDB et les architectures multilocataires.

**Important**  
Avant de supprimer RDS-specific des utilisateurs et des tablespaces, vérifiez qu'aucun objet d'application n'existe dans les schémas suivants :

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

Si des objets d'application sont trouvés, migrez-les vers les schémas d'application appropriés avant de continuer.

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

Résultat attendu : `no rows selected`

**Multilocataire :**

Dans un environnement mutualisé, RDS Custom crée des utilisateurs communs visibles sur toutes les PDB. `CDB$ROOT` Vous devez nettoyer 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%';
```

Résultat attendu pour toutes les requêtes : `no rows selected`

### Étape 10 : Configuration du démarrage automatique
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-10"></a>

Créez `SPFILE` :

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

Pour le multitenant, assurez-vous que les PDB sont ouverts :

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

Modifier `/etc/oratab` :

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

### Étape 11 : Validation finale
<a name="RDS-Custom-for-Oracle-end-of-support-option-1-step-11"></a>

**Example Non-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 Multilocataire :**  

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

 **Étape 12 : Reprendre l'automatisation personnalisée de RDS** 

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

 

## Option 2 : migration physique à l'aide d'Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2"></a>



Cette section fournit des étapes détaillées pour migrer votre base de données Oracle de RDS Custom for Oracle vers EC2 à l'aide d'Oracle Data Guard. Cette méthode convient aux migrations nécessitant un temps d'arrêt minimal.

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

**Choisissez Oracle Data Guard lorsque :**
+ Vous avez besoin d'un temps d'arrêt minimal (de quelques secondes à quelques minutes pour le passage au numérique)
+ Vous migrez des bases de données de production ou critiques
+ Vous avez besoin d'une synchronisation continue avant le passage
+ Vous voulez une fonctionnalité de repli intégrée
+ Vous devez tester la base de données cible avant de procéder à la migration

### Présentation d'Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-odg-overview"></a>

Oracle Data Guard gère une base de données de secours synchronisée en expédiant et en appliquant en permanence des journaux de rétablissement à partir de la base de données principale. Lorsque vous êtes prêt à terminer la migration, vous effectuez une transition qui fait passer le mode veille de l'EC2 au mode principal avec un temps d'arrêt minimal (de quelques secondes à quelques minutes). Pour les bases de données mutualisées, Data Guard protège automatiquement l'ensemble de la CDB, y compris toutes les PDB. Le redo généré par n'importe quel PDB est expédié vers le support de secours et appliqué au PDB correspondant en mode veille.

### Flux de travail de migration pour Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-odg-workflow"></a>

**Étapes (principales) de l'instance de base de données personnalisée RDS :**

1. Suspendre l'automatisation personnalisée d'Amazon RDS

1. Vérifier l'architecture de la base de données (non CDB ou CDB avec PDB)

1. Vérifiez que la base de données principale s'exécute en mode journal d'archivage et `FORCE_LOGGING` qu'elle est activée

1. Création d'un fichier de mots de passe

1. Effectuez une sauvegarde en ligne RMAN de la base de données principale (ou utilisez la duplication active)

1. Création d'un fichier de paramètres à partir de la base de données source

1. Copiez les ensembles de sauvegarde, le fichier de paramètres et le fichier de mots de passe sur l'instance EC2 cible

**Étapes de l'instance de base de données EC2 (veille) :**

1. Copiez tous les fichiers de la source vers l'instance EC2

1. Copiez le fichier de mot de passe sur l'instance EC2

1. Modifier le fichier de paramètres pour EC2 (spécifique à l'architecture)

1. Créez le fichier de paramètres du serveur à partir du fichier de paramètres

1. Restaurer le fichier de contrôle de secours et la base de données

**Étapes de configuration de Data Guard :**

1. Configurer les écouteurs Oracle sur les deux instances

1. Configurez tnsnames.ora sur les deux instances

1. Démarrez le courtier Oracle Data Guard sur les deux instances (facultatif mais recommandé)

1. Activer la configuration d'Oracle Data Guard

1. Configurer fal\_server et fal\_client sur l'instance de secours EC2

1. Configurer les fichiers de journalisation de secours sur les deux instances

1. Restaurez l'instance de secours

1. Procéder à la commutation manuelle

1. Ouvrez la base de données (et les PDB pour le multitenant)

1. Configurer l'ouverture automatique de PDB (multitenant uniquement)

1. Supprimer des utilisateurs et des objets spécifiques à RDS Custom

1. Création d'un fichier SPFILE et configuration du démarrage automatique

### Étape 1 : Suspendre l'automatisation personnalisée d'Amazon RDS
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-1"></a>

Suspendez le mode d'automatisation sur votre instance RDS Custom. Le `--resume-full-automation-mode-minute` paramètre doit être ajusté en fonction de la taille de votre base de données et du temps de configuration prévu de 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
```

Validez l'état de l'automatisation :

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

Résultat attendu : "`all-paused`»

### Étape 2 : Confirmer le mode journal des archives et `FORCE_LOGGING`
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-2"></a>

Oracle Data Guard nécessite que la base de données principale soit en mode journal d'archivage avec enregistrement forcé activé :

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

Sortie attendue :

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

Si la journalisation forcée n'est pas activée, exécutez :

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

### Étape 3 : Création de fichiers de mots de passe et de paramètres
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-3"></a>

Créez un fichier de mots de passe à l'aide de`orapwd`. Récupérez le mot de passe SYS dans 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
```

Créez un fichier de paramètres à partir de la base de données source :

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

### Étape 4 : effectuer une sauvegarde RMAN ou utiliser la duplication active
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4"></a>

Deux options s'offrent à vous pour créer la base de données de secours :

#### Option A : sauvegarde en ligne RMAN (recommandée pour la plupart des scénarios)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4-a"></a>

Créez un répertoire de sauvegarde et sauvegardez la base de données :

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

**Note**  
Pour le multitenant, le mot clé de base de données sauvegarde automatiquement l'intégralité du CDB, y compris tous les PDB.

#### Option B : Duplication active (méthode alternative)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-4-b"></a>

Ignorez l'étape de sauvegarde et utilisez la duplication active RMAN pour créer le système de secours directement sur le réseau. Cela élimine le besoin de stockage de sauvegarde et de transfert de fichiers. Après avoir configuré le TNS et les écouteurs (voir ci-dessous), exécutez :

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

Ce guide se concentre sur l'option A (basée sur la sauvegarde), mais l'option B est une alternative valable.

### Étape 5 : Transférer des fichiers vers EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-5"></a>

Choisissez votre méthode de transfert de fichiers préférée. Ce guide utilise Amazon S3 à titre d'exemple.

**À l'aide d'Amazon S3 :**

**Example Pour Non-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 Pour le multilocataire :**  

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

### Étape 6 : Modifier le fichier de paramètres sur EC2
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-6"></a>

Modifiez `$ORACLE_HOME/dbs/initORCL.ora` l'instance EC2 et apportez les modifications essentielles suivantes :

1. **Mettre à jour le nom de la base** de données : pour le multitenant, remplacez toutes les occurrences de par `RDSCDB` `ORCL`

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

1. **Convertir les chemins personnalisés RDS en chemins EC2 : remplacer** par `/rdsdbdata/` `/u01/app/oracle/`

1. 

****Supprimer les paramètres RDS Custom-specific****
   + `dg_broker_config_file1`et `dg_broker_config_file2` (le cas échéant)
   + `standby_file_management`(si présent)
   + `spfile`(nous en créerons un nouveau `SPFILE` plus tard)
   + Tous `log_archive_dest` les paramètres pointant vers des destinations d'attente

1. **Ajustez les paramètres de mémoire** en fonction de la taille de votre instance EC2 (facultatif mais recommandé)

 **Mappages de chemins :** 

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

**Multilocataire :**
+ `/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`

**Important** : pour le multitenant, assurez-vous que `enable_pluggable_database` = `TRUE` est présent dans le fichier de paramètres.

### Étape 7 : Création `SPFILE` et restauration de la base de données de secours
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-7"></a>

Démarrez l'instance et créez 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;
```

Créez un lien symbolique :

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

Démarrez l'instance et restaurez :

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

Si les fichiers de sauvegarde se trouvent dans un chemin différent de celui de la source, cataloguez-les d'abord :

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

Restaurez le fichier de contrôle de veille et montez :

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

Si les chemins des fichiers de données diffèrent (par exemple, en utilisant ASM), utilisez `SET NEWNAME` :

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

Sinon, restaurez simplement :

```
RMAN> restore database;
```

Restaurez la base de données selon la dernière séquence disponible :

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

**Note**  
Pour le multilocataire, RMAN restaure et récupère automatiquement toutes les PDB. Il n'est pas nécessaire de restaurer chaque PDB séparément.

### Étape 8 : Configuration du TNS et des écouteurs
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-8"></a>

Dans les deux cas, ajoutez des entrées TNS à `tnsnames.ora` :

**Example Non-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 Multilocataire :**  

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

Configurez les écouteurs sur les deux instances. Sur RDS Custom, ajoutez à : `listener.ora`

**Example Pour Non-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 Pour le multilocataire :**  

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

Démarrez l'écouteur :

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

Sur EC2, créez `$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>}})))
```

Démarrez l'écouteur :

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

**Note**  
Vous pouvez utiliser l'écouteur existant sur RDS Custom si vous le souhaitez, mais la création d'un écouteur Data Guard distinct permet une meilleure isolation.

**Important**  
En cas `tnsping` de défaillance de la `listener` connectivité, vérifiez `iptables` les règles sur EC2. De nombreuses instances Linux EC2 ont des `iptables` règles par défaut qui bloquent le port 1521. Ajoutez une règle : `sudo iptables -I INPUT 5 -p tcp --dport 1521 -j ACCEPT`

### Étape 9 : activer le broker Data Guard et sa configuration
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-9"></a>

Dans les deux cas, activez le broker Data Guard :

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

Sur le serveur principal RDS Custom, connectez-vous au courtier Data Guard et créez la configuration :

```
dgmgrl /
```

**Example Pour Non-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 Pour le multilocataire :**  

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

Définissez des identifiants de connexion statiques et activez :

 

**Example Pour Non-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 Pour le multilocataire :**  

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

**Note**  
Le courtier Data Guard est facultatif mais recommandé pour faciliter la gestion. Pour les migrations simples, vous pouvez configurer Data Guard manuellement sans le broker.

**Note**  
Lorsque vous activez Data Guard pour un CDB, il protège automatiquement tous les PDB. Le redo généré par n'importe quel PDB est expédié vers le support de secours et appliqué au PDB correspondant en mode veille.

### Étape 10 : configurer les journaux de restauration de secours et démarrer la restauration
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10"></a>

Sur l'instance de secours EC2, ajoutez des fichiers de journalisation de secours (n\+1 où n est le nombre de groupes de journalisation en ligne) :

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

**Note**  
Pour le multitenant, les journaux de rétablissement de secours sont créés au niveau de la CDB et sont partagés par toutes les PDB.

Configurez les paramètres FAL en mode veille :

 

**Example Pour Non-CDB :**  

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

 

**Example Pour le multilocataire :**  

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

Démarrez la restauration gérée :

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

Surveillez le délai d'application :

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

**Surveillance et gestion détaillées de la synchronisation Data Guard :**

La surveillance de Data Guard est essentielle pour garantir une migration réussie. Voici des techniques de surveillance complètes :

1. **Surveillez les statistiques de Data Guard :**

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

   Principaux indicateurs à surveiller :
   + délai de transport : différence de temps entre le moment où le rétablissement a été généré sur le serveur principal et le moment où il a été reçu en mode veille
   + appliquer le décalage : différence de temps entre le moment où le rétablissement a été généré et le moment où le rétablissement a été appliqué en mode veille
   + taux d'application : taux auquel le redo est appliqué () MB/sec
   + redo reçu : nombre total de redo reçus en mode veille
   + rétablissement appliqué : rétablissement total appliqué par mode veille

1. **Surveillez l'expédition des journaux d'archives :**

   Sur le 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';
   ```

   En veille (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. **Surveillez le processus de restauration géré :**

   ```
   -- 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. **Surveillez le taux de réapplication pour les multilocataires :**

   Pour les bases de données mutualisées, surveillez le taux d'application par 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. **Surveillez les journaux de restauration en veille :**

   ```
   -- 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. **Estimation de l'achèvement de la synchronisation :**

   Calculez le temps restant en fonction du taux d'application :

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

#### Problèmes courants de synchronisation avec Data Guard :
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues"></a>



##### Problème 1 : délai d'application élevé
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-1"></a>

Symptômes :

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

Causes et solutions :
+ **Insuffisant en mode CPU/IO veille** : mettez à niveau le type d'instance EC2 ou augmentez les IOPS EBS
+ **Limitation de la bande passante réseau** : utilisez un réseau amélioré ou des types d'instances à bande passante plus élevée
+ **Plusieurs PDB avec un taux de transactions élevé** : envisagez d'augmenter le parallélisme Redo Apply (nécessite une licence Active 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;
```

##### Problème 2 : écart dans le journal d'archivage
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-2"></a>

Symptômes :

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

Solution :

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

##### Problème 3 : échec du transport Redo
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-3"></a>

Symptômes :

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

Solution :

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

##### Problème 4 : la restauration gérée n'applique pas la restauration
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-10-common-issues-4"></a>

Symptômes :

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

Solution :

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

**Pour Multitenant**, vous pouvez également vérifier l'état de chaque PDB en veille :

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

Sortie attendue (PDB en `MOUNTED` état de veille) :

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

**Note**  
En mode veille physique, les PDB restent en `MOUNTED` état pendant la restauration gérée.

### Étape 11 : Effectuez le changement
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-11"></a>

Une fois que vous êtes certain que le mode veille est complètement synchronisé et prêt, effectuez le changement. Pour le multilocataire, le basculement fera passer l'ensemble du CDB (tous les PDB) du serveur principal RDS Custom au module de secours EC2.

Sur l'instance principale RDS Custom, connectez-vous au courtier Data Guard et vérifiez que les deux bases de données sont prêtes pour le basculement :

**Example Pour Non-CDB :**  

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

 

**Example Pour le multilocataire :**  

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

Les deux devraient montrer `Ready for Switchover: Yes`

Passez du serveur principal personnalisé RDS au mode de secours EC2 :

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

Vérifiez que le basculement est réussi :

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

L'instance EC2 (`ORCL_B`) est désormais la base de données principale et l'instance RDS Custom est la base de données de secours physique.

### Étape 12 : Ouvrez les PDB (multitenant uniquement)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-12"></a>

Après le basculement, le CDB sur EC2 est ouvert en mode READWRITE, mais tous les PDB sont à l'état MONTÉ. Vous devez les ouvrir manuellement.

Connectez-vous au nouveau serveur principal sur EC2 :

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

Sortie attendue :

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

Vérifiez l'état actuel du PDB :

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

Sortie attendue (PDB en `MOUNTED` état - exemple avec un PDB nommé`ORCLDB`) :

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

Ouvrez tous les PDB :

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

Base de données enfichable modifiée.

Vérifiez que tous les PDB sont désormais ouverts en `READ WRITE` mode :

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

Sortie attendue :

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

### Étape 13 : Configurer l'ouverture automatique de PDB au démarrage (multitenant uniquement)
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-13"></a>

Configurez les PDB pour qu'elles s'ouvrent automatiquement lorsque le CDB démarre en utilisant la méthode d'enregistrement de l'état (recommandée pour Oracle 19c) :

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

Vérifiez l'état enregistré :

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

Vérifiez que les services PDB sont enregistrés auprès de l'écouteur :

```
lsnrctl services
```

Le résultat attendu doit indiquer les services fournis au CDB et à chaque PDB. Si les services ne s'affichent pas :

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

Vérifiez ensuite à nouveau avec`lsnrctl services`.

### Étape 14 : Supprimer les objets personnalisés RDS
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-14"></a>

Comme il s'agit désormais d'une base de données autogérée sur EC2, vous devez supprimer les utilisateurs et les objets spécifiques à RDS Custom. Le processus de nettoyage diffère légèrement entre les architectures non CDB et les architectures multilocataires.

**Important**  
Avant de supprimer RDS-specific des utilisateurs et des tablespaces, vérifiez qu'aucun objet d'application n'existe dans les schémas suivants :

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

Si des objets d'application sont trouvés, migrez-les vers les schémas d'application appropriés avant de continuer.

**Non-CDB nettoyage :**

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

Résultat attendu : `no rows selected`

**Nettoyage multilocataire :**

Dans un environnement mutualisé, RDS Custom crée des utilisateurs communs visibles sur toutes les PDB. `CDB$ROOT` Vous devez nettoyer 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%';
```

Résultat attendu pour toutes les requêtes : aucune ligne sélectionnée

### Étape 15 : Configuration du démarrage automatique
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-15"></a>

Vérifiez que le `SPFILE` est utilisé :

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

Si le `spfile` chemin est correct, aucune action n'est nécessaire. Si ce n'est pas le cas, créez-en un :

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

Redémarrez la base de données :

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

Pour le multitenant, ouvrez toutes les PDB (elles devraient s'ouvrir automatiquement si vous avez enregistré l'état plus tôt) :

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

Si les PDB ne sont pas ouverts, ouvrez-les manuellement :

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

Modifier `/etc/oratab` :

```
vi /etc/oratab
```

Changez la ligne `ORCL` de `N` à `Y` :

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

### Étape 16 : Validation finale
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-16"></a>

Effectuez une validation complète de la base de données migrée.

**Example Pour Non-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 Pour le multilocataire :**  

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

Testez la connectivité des applications :

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

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

### Étape 17 : Nettoyer les fichiers de sauvegarde
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-17"></a>

Une fois la validation réussie, supprimez les fichiers de sauvegarde et détachez le volume de sauvegarde si vous utilisez un volume EBS distinct :

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

Si vous utilisez un volume EBS distinct pour les sauvegardes :

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

### Étape 18 : Reprendre l'automatisation personnalisée de RDS
<a name="RDS-Custom-for-Oracle-end-of-support-option-2-step-18"></a>

Si vous prévoyez de continuer à exécuter l'instance RDS Custom en tant que solution de secours pendant une période de validation, reprenez l'automatisation :

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

## Dépannage des problèmes courants
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting"></a>



Cette section couvre les problèmes courants que vous pouvez rencontrer lors de la migration en ce qui concerne à la fois les approches de duplication RMAN et d'Oracle Data Guard, couvrant à la fois les architectures non CDB et mutualisées.

### ORA-09925: Impossible de créer le fichier de journal d'audit
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-09925"></a>

**Cause :** Le répertoire d'audit spécifié en `audit_file_dest` paramètre n'existe pas sur l'instance EC2 cible.

 **Solution :** 

Assurez-vous que le répertoire d'audit existe et dispose des autorisations appropriées :

```
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: la chaîne de `db_create_file_dest` destination du paramètre ne peut pas être traduite
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-01261"></a>

**Cause :** Le répertoire spécifié en `db_create_file_dest` paramètre n'existe pas sur l'instance EC2 cible.

 **Solution :** 

Pour les non-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
```

Pour les locataires multiples :

```
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: échec de l'initialisation des informations de fuseau horaire
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-ora-01804"></a>

Cette erreur peut se produire lors de la suppression de l'`RDSADMIN`utilisateur si la source RDS possède une version de fuseau horaire supérieure à celle installée dans votre fichier EC2 $ORACLE\_HOME.

 **Solution :** 

1. Vérifiez les versions des fuseaux horaires :

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

1. Pour contourner le problème, définissez la variable d'environnement du fichier de fuseau horaire pour qu'elle corresponde à ce dont dispose votre fichier $ORACLE\_HOME :

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

   Ajustez le numéro pour qu'il corresponde à la version disponible dans votre installation.

1. Réessayez le drop :

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

### Cross-RU problèmes de migration (différentes mises à jour de version)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-cross-ru-migration"></a>

**Cause :** L'instance EC2 cible possède un Oracle Release Update (RU) ou des correctifs ponctuels différents de ceux de l'instance RDS Custom source, ce qui entraîne des erreurs de compatibilité pendant ou après la migration.

**Erreurs courantes :**
+ ORA-00600 erreurs internes lors de la réinitialisation de l'application (Data Guard)
+ ORA-39700 la base de données doit être ouverte avec `UPGRADE` l'option
+ Incohérences du dictionnaire après la migration
+ Objets non valides dans `DBA_REGISTRY` ou `DBA_OBJECTS`

 **Solution :** 

 **Bonne pratique - Faites correspondre exactement les versions RU aux correctifs ponctuels :** 

1. Vérifiez la version exacte de RU à la fois sur la source et sur la cible :

   ```
   -- 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. Vérifiez le niveau du correctif $ORACLE\_HOME :

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

1. Si les versions ne correspondent pas, alignez-les avant la migration en appliquant ou en annulant des correctifs selon les besoins.

1. Si vous devez continuer avec des RU incompatibles, exécutez le datapatch après la migration :

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

1. Vérifiez la présence d'objets non valides et recompilez :

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

### Problèmes liés à la connectivité réseau
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-network-connectivity"></a>

 

**Cause :** groupes de sécurité, ACL réseau ou `iptables` blocage du port du récepteur Oracle.

 **Solution :** 

1. Vérifiez que les groupes de sécurité autorisent le port de manière bidirectionnelle

1. Vérifiez iptables sur EC2 :

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

1. Ajoutez une règle si nécessaire :

   ```
   # 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. Testez la connectivité :

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

### Les PDB ne s'ouvrent pas après la migration (multitenant uniquement)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdbs-not-opening"></a>

**Cause :** Il s'agit d'un comportement attendu. Après la duplication de RMAN ou le passage à Data Guard, le CDB est ouvert mais les PDB sont en état. `MOUNTED`

 **Solution :** 

Ouvrez-les manuellement :

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

Si un PDB spécifique ne s'ouvre pas, vérifiez la présence d'erreurs dans le journal des alertes :

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

Les causes courantes incluent des fichiers de données manquants ou des problèmes de mappage de chemins.

### Fichiers de données PDB introuvables ou chemins non concordants (multitenant uniquement)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdb-data-files-not-found"></a>

**Cause :** La migration n'a pas mappé correctement tous les chemins source, en particulier pour les fichiers de données OMF-based PDB.

 **Solution :** 

1. Vérifiez quels fichiers de données sont manquants :

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

1. Si les fichiers ont été placés dans le mauvais répertoire, renommez-les dans le fichier de contrôle :

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

1. Pour éviter cela, vérifiez toujours les chemins du fichier de données source avec `SELECT con_id, name FROM v$datafile ORDER BY con_id;` avant de configurer le fichier de paramètres.

### Les services PDB ne s'enregistrent pas auprès de l'écouteur (multitenant uniquement)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdb-services-not-registering"></a>

**Cause :** Le récepteur n'est pas conscient de l'existence des services PDB après avoir ouvert les PDB.

 **Solution :** 

1. Forcer l'enregistrement du service :

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

1. Si les services n'apparaissent toujours pas, vérifiez le `local_listener` paramètre :

   ```
   SQL> SHOW PARAMETER local_listener;
   ```

   Assurez-vous qu'il pointe vers la bonne adresse de l'auditeur. Si nécessaire, mettez-le à jour :

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

1. Vérifiez auprès de :

   ```
   lsnrctl services
   ```

### Les PDB ne s'ouvrent pas automatiquement après le redémarrage de la CDB (multitenant uniquement)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-pdbs-not-opening-after-cdb-restart"></a>

**Cause :** L'état de sauvegarde PDB n'a pas été configuré.

 **Solution :** 

Vérifiez que l'état de sauvegarde PDB a été configuré :

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

Si aucune ligne n'est renvoyée, enregistrez l'état :

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

### Le transport Data Guard Redo ne fonctionne pas
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-odg-redo-transport-failure"></a>

**Cause :** problèmes de connectivité réseau, configuration TNS incorrecte ou paramètres FAL non définis.

 **Solution :** 

1. Vérifiez que le mode veille est en mode MOUNT :

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

1. Vérifiez que fal\_server et fal\_client sont correctement configurés en mode veille :

   ```
   SQL> SHOW PARAMETER fal_server
   SQL> SHOW PARAMETER fal_client
   ```

1. Vérifiez la connectivité réseau :

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

1. Vérifiez le paramètre log\_archive\_dest\_2 sur les points principaux vers le serveur de secours (s'il est configuré manuellement sans broker).

 **Data Guard applique le délai d'application qui augmente avec plusieurs PDB (multitenant uniquement)** 

**Cause :** Pour les CDB comportant plusieurs PDB, l'application de rétablissement peut être plus lente en raison du volume de modifications dans tous les conteneurs.

 **Solution :** 

1. Vérifiez le taux applicable :

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

1. Envisagez d'augmenter le parallélisme pour Redo Apply (nécessite une licence 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;
   ```

1. Vérifiez qu'il n'y a aucune contrainte de ressources (CPU I/O) sur l'instance de secours.

 **La sauvegarde du journal des archives RMAN échoue avec ORA-19625** 

**Cause :** L'automatisation personnalisée RDS a purgé les anciens journaux d'archive du disque, mais le fichier de contrôle de RMAN en contient toujours des enregistrements.

 **Solution :** 

1. Vérifiez et nettoyez les entrées du journal d'archives périmées :

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

1. Re-run juste la sauvegarde du journal des archives :

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

### La suppression courante d'un utilisateur échoue en mode multitenant (multitenant uniquement)
<a name="RDS-Custom-for-Oracle-end-of-support-troubleshoting-multitenant-user-drop-fails"></a>

 

**Cause :** les utilisateurs courants (préfixés par C\#\#) doivent être supprimés avec la clause. `CONTAINER=ALL`

 **Solution :** 

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

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

Vérifiez que vous êtes connecté à `CDB$ROOT` :

```
SQL> SHOW CON_NAME;
```

## Post-migration tâches
<a name="RDS-Custom-for-Oracle-end-of-support-post-migration"></a>

Une fois la migration réussie, effectuez ces tâches supplémentaires pour vous assurer que votre base de données Oracle autogérée sur EC2 est prête pour la production.

 **Mettre à jour les chaînes de connexion des applications** 

**Pour Non-CDB :**
+ Dirigez vos applications vers le nouveau point de terminaison de l'instance EC2
+ Mettre à jour les chaînes de connexion pour utiliser l'adresse IP ou le nom d'hôte de l'instance EC2
+ Testez minutieusement toutes les fonctionnalités de l'application

**Pour le multilocataire :**
+ Dirigez vos applications vers les nouveaux noms de service PDB de l'instance EC2 (par exemple, ORCLDB ou vos noms PDB spécifiques)
+ Assurez-vous que les applications se connectent au PDB approprié, et non au CDB
+ Mettre à jour les chaînes de connexion pour utiliser les noms de service PDB
+ Testez toutes les fonctionnalités de l'application pour chaque PDB

Exemples de chaînes de connexion :

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

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

 **Configuration de la stratégie de sauvegarde** 

Configurez une stratégie de sauvegarde complète pour votre base de données autogérée :

**Sauvegardes RMAN :**
+ Configuration de scripts de sauvegarde RMAN automatisés pour des sauvegardes complètes, incrémentielles et des journaux d'archivage
+ Configurez des politiques de conservation des sauvegardes en fonction de vos objectifs de point de restauration (RPO)
+ Stockez les sauvegardes sur Amazon S3 pour une durabilité et une rentabilité accrues
+ Testez régulièrement les procédures de restauration des sauvegardes

**AWS Backup:**
+ À utiliser [AWS Backup](https://aws.amazon.com/backup/)pour les instantanés de volumes EBS
+ Configuration des plannings de sauvegarde et des politiques de conservation
+ Activez les copies de sauvegarde interrégionales pour la reprise après sinistre

**Pour le multilocataire :**
+ Les sauvegardes RMAN de la CDB incluent automatiquement toutes les PDB
+ Vous pouvez également sauvegarder des PDB individuels si nécessaire
+ Envisagez des plannings de PDB-specific sauvegarde en fonction des besoins de l'entreprise

Exemple de script de sauvegarde 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
```

 **Configuration de la surveillance** 

Mettez en œuvre une surveillance complète de votre base de données EC2-hosted Oracle :

**Amazon CloudWatch**
+ Configuration de CloudWatch mesures relatives à l'état de santé de l'instance EC2, à l'utilisation du disque et à des mesures Oracle personnalisées
+ Créez des CloudWatch alarmes pour les seuils critiques
+ Utiliser CloudWatch les journaux pour surveiller les journaux d'alertes de base de données

**Oracle Enterprise Manager (OEM) :**
+ Si disponible, configurez l'OEM pour la surveillance des bases de données
+ Configuration de la surveillance et du diagnostic des performances
+ Configurer des alertes automatisées pour les événements critiques

**Third-party outils :**
+ Envisagez des outils tels que Datadog, New Relic ou Prometheus pour la surveillance des bases de données
+ Intégrez votre infrastructure de surveillance existante

**Principaux indicateurs à surveiller :**
+ Utilisation du tablespace
+ Espace journal d'archivage
+ Objets non valides
+ Nombre de sessions
+ Événements d’attente
+ Utilisation de l’UC et de la mémoire
+ I/O performance

**Pour le multilocataire :**
+ Surveillez à la fois CDB-level les PDB-level indicateurs
+ Configurer des alertes pour l'utilisation des ressources PDB et les quotas
+ Suivez les indicateurs PDB-specific de performance

 **Configuration des groupes de sécurité et des ACL réseau** 

Vérifiez et renforcez la sécurité de l'instance EC2 :

**Groupes de sécurité :**
+ Restreindre l'accès aux ports de base de données aux seuls serveurs d'applications et hôtes bastion autorisés
+ Supprimez toutes les règles trop permissives créées lors de la migration
+ Documenter les règles des groupes de sécurité et leurs objectifs

**ACL réseau :**
+ Configurer les ACL du réseau VPC pour des couches de sécurité supplémentaires
+ Mettre en œuvre une stratégie de sécurité axée sur la défense en profondeur

**Accès SSH :**
+ Limitez l'accès SSH à des plages d'adresses IP spécifiques ou utilisez le gestionnaire de session AWS Systems Manager
+ Désactiver l'authentification par mot de passe et utiliser uniquement l'authentification par clé
+ Mettre en œuvre l'authentification multifactorielle (MFA) pour un accès privilégié

**Chiffrement :**
+ Activer le chiffrement au repos pour les volumes EBS
+ Activez le chiffrement en transit pour les connexions aux bases de données à l'aide d'Oracle Native Network Encryption ou de TLS
+ Effectuez une rotation régulière des clés de chiffrement

**Mettre en œuvre la haute disponibilité**

Si votre charge de travail nécessite une haute disponibilité, envisagez de mettre en œuvre :

**Oracle Data Guard :**
+ Configuration d'une nouvelle base de données de secours sur une autre instance EC2 pour la reprise après sinistre
+ Pour le multitenant, Data Guard protège l'ensemble de la CDB, y compris toutes les PDB
+ Le mode veille peut se trouver dans une zone de disponibilité ou une région différente
+ Mettre en œuvre des mécanismes de basculement automatisés à l'aide de scripts ou d'outils tiers

**AWS Multi-AZ déploiement :**
+ Déployez des instances de secours dans différentes zones de disponibilité
+ Utiliser Amazon Route 53 pour le basculement du DNS
+ Mettre en œuvre le regroupement des connexions au niveau de l'application avec prise en charge du basculement

**Backup et restauration :**
+ Maintenez des sauvegardes régulières grâce à des procédures de restauration testées
+ Documentez les objectifs de temps de restauration (RTO) et de point de restauration (RPO)
+ Mener régulièrement des exercices de reprise après sinistre

**Effectuez des tests approfondis des applications**

Avant de mettre hors service l'instance RDS Custom :

**Tests fonctionnels :**
+ Vérifiez que toutes les fonctionnalités de l'application fonctionnent correctement
+ Testez toutes les fonctionnalités dépendantes de la base de données
+ Valider l'intégrité et la cohérence des données

**Tests de performance :**
+ Comparez les indicateurs de performance avec la base de référence personnalisée RDS
+ Identifiez et corrigez les éventuelles régressions de performance
+ Optimisez les requêtes et les index selon les besoins

**Test de charge :**
+ Testez la base de données sous les pics de charge attendus
+ Vérifiez que l'utilisation des ressources reste dans les limites acceptables
+ Identifiez et corrigez les éventuels goulots d'étranglement

**Test de basculement (si HA est configuré) :**
+ Testez les scénarios de basculement
+ Vérifier la logique de reconnexion des applications
+ Mesurez le RTO et le RPO réels

**Tests de sauvegarde et de restauration :**
+ Vérifiez que les procédures de sauvegarde et de restauration fonctionnent correctement
+ Récupération ponctuelle
+ Valider l'intégrité des sauvegardes

**Pour le multilocataire :**
+ Testez chaque PDB indépendamment
+ Vérifiez l'isolation du PDB et l'allocation des ressources
+  PDB-specific Opérations de test (clonage unplug/plug, etc.)

**Démanteler une instance personnalisée RDS**

Après une période de validation réussie (généralement 1 à 2 semaines) :

1. **Sauvegarde finale : effectuez** une sauvegarde finale de l'instance personnalisée RDS à des fins d'archivage

   ```
   # 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. **Documenter la migration** : mettre à jour les runbooks et la documentation avec la nouvelle configuration EC2

1. **Supprimer l'instance personnalisée RDS** : utilisez la AWS console ou la CLI pour supprimer l'instance

   ```
   # 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. **Nettoyer les ressources** : supprimez les instantanés, les groupes de paramètres et les groupes d'options associés s'ils ne sont plus nécessaires

1. **Mettre à jour la documentation** : assurez-vous que toute la documentation opérationnelle reflète la nouvelle EC2-based architecture

## Comparaison entre RMAN Active Duplication et Oracle Data Guard
<a name="RDS-Custom-for-Oracle-end-of-support-RMAN-vs-ODG"></a>

Le tableau suivant récapitule les principales différences entre les deux options de migration :


|  **Aspect**  |  **Duplication active RMAN**  |  **Oracle Data Guard**  | 
| --- | --- | --- | 
| **Disponibilité de la base de données source** | En ligne pendant toute la durée de la duplication | En ligne pendant tout le processus | 
| **Temps d'arrêt** | Minutes (découpe finale uniquement) | Quelques secondes à quelques minutes (commutation) | 
| **Complexité** | Inférieur | Supérieur | 
| **Durée de la migration** | Opération de duplication unique | Configuration initiale et synchronisation continue | 
| **Synchronisation continue** | Non | Oui | 
| **Capacité de repli** | Manuel (maintenez le code source actif) | Built-in (automatique) | 
| **Tests avant le passage** | Limité (test après duplication) | Test complet possible (le mode veille peut être testé) | 
| **Bande passante réseau** | Élevé lors de la duplication | Modéré (continu) | 
| **Impact sur la base de données source** | Minimale (opérations de lecture) | Minimum (refaire l'expédition) | 
| **Idéal pour** | La plupart des migrations, un transfert simple | Mission-critical, presque aucun temps d'arrêt requis | 
| **Non-CDB soutien** | Oui | Oui | 
| **Assistance multilocataire** | Oui (CDB entier) | Oui (CDB entier) | 
| **Post-migration État du PDB** | CDB ouvert, PDB MONTÉ | CDB ouvert, PDB MONTÉ | 
| **Nécessite RMAN** | Oui | Oui (pour la sauvegarde initiale dans le cadre d'une approche basée sur la sauvegarde) | 
| **Nécessite Data Guard** | Non | Oui | 
| **Niveau de compétence requis** | Intermédiaire | Advanced (Avancé) | 
| **Processus de transition** | Rediriger les applications vers EC2 | Commande de basculement et redirection des applications | 

## Comparaison entre la migration Non-CDB multilocataire et la migration
<a name="RDS-Custom-for-Oracle-end-of-support-non-cdb-va-multitenant"></a>

 

Le tableau suivant récapitule les principales différences entre la migration de bases de données non CDB et de bases de données mutualisées :


|  **Aspect**  |  **Non-CDB migration**  |  **Migration multilocataire (CDB avec PDB)**  | 
| --- | --- | --- | 
| **Type de base de données** | Single-instance Non CDB (par exemple,) ORCL | CDB (source :RDSCDB, cible :ORCL) avec CDB$ROOT \+ PDB$SEED \+ un ou plusieurs PDB | 
| **Étendue de la migration** | Base de données unique | CDB entier (tous les PDB inclus automatiquement) | 
| **Étendue de duplication RMAN** | Duplique une seule base de données | Duplique l'intégralité du CDB (tous les conteneurs) | 
| **Portée Data Guard** | Protège une base de données unique | Protège l'ensemble du CDB (tous les PDB sont inclus automatiquement) | 
| **Fichier de paramètres** | Paramètres d'initialisation standard | Doit inclure enable\_pluggable\_database = TRUE | 
| **Post-migration état de base de données** | La base de données s'ouvre en mode READ/WRITE | Le CDB s'ouvre en READ WRITE mode ; les PDB restent en état MOUNTED | 
| **Ouverture du PDB** | N/A | Vous devez ouvrir manuellement tous les PDB avec ALTER PLUGGABLE DATABASE ALL OPEN | 
| **Ouverture automatique du PDB au démarrage** | N/A | Doit configurer l'état de sauvegarde ou le déclencheur de démarrage PDB | 
| **Validation** | Contrôles de base de données uniques | Doit valider le CDB et chaque PDB individuellement | 
| **RDS-specific nettoyage** | Supprimer d'une base users/objects de données unique | Supprimer les utilisateurs courants CDB$ROOT (des cascades vers les PDB) ; gérer les utilisateurs C\#\# | 
| **TNS/Listener configuration** | Service unique pour la base de données | Service CDB \+ services PDB individuels enregistrés dynamiquement | 
| **Chaînes de connexion aux applications** | Connect à une seule base de données | Connect à des services PDB individuels (pas CDB) | 
| **Stratégie de sauvegarde** | Backup d'une base de données unique | Backup l'intégralité du CDB (inclut tous les PDB) ou des PDB individuels | 
| **Gestion des ressources** | Database-level gestion des ressources | CDB-level et gestion PDB-level des ressources avec Resource Manager | 
| **Complexité** | Complexité réduite | Complexité accrue en raison de la multiplicité des conteneurs et des chemins OMF | 

## Meilleures pratiques et recommandations
<a name="RDS-Custom-for-Oracle-end-of-support-best-practices"></a>

Cette section fournit des meilleures pratiques complètes pour une migration réussie de RDS Custom for Oracle vers EC2.

### Pre-migration planification
<a name="RDS-Custom-for-Oracle-end-of-support-best-practices-pre-migration"></a>

1. Procéder à une évaluation approfondie :

   Avant de commencer la migration, effectuez une évaluation complète de votre environnement :
   + **Inventaire des bases** de données : documentez toutes les bases de données, leurs tailles, leurs architectures (non CDB ou mutualisées) et leurs dépendances
   + **Dépendances des applications** : identifiez toutes les applications qui se connectent à la base de données et leurs méthodes de connexion
   + **Base de référence en matière** de performances : capturez les indicateurs de performance (processeur, mémoire I/O, réseau) à des fins de comparaison après la migration
   + **Exigences en matière de sauvegarde et de restauration** : document RPO (objectif de point de restauration) et RTO (objectif de temps de restauration)
   + **Exigences de conformité** : identifiez les exigences réglementaires ou de conformité susceptibles d'affecter la migration

1. Choisissez le bon type d'instance EC2 :

   Sélectionnez un type d'instance EC2 en fonction des caractéristiques de votre charge de travail :    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/RDS-Custom-for-Oracle-end-of-support.html)

    **Directives relatives au dimensionnement des instances :** 
   + Commencez avec la même classe d'instance que votre instance RDS Custom
   + Surveiller l'utilisation des ressources lors d'un test de migration
   + Envisagez d'utiliser AWS Compute Optimizer pour obtenir des recommandations
   + Prévoyez une marge de 20 à 30 % pour faire face à la croissance et aux pics de charge

1. Concevez votre architecture de stockage :

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

   **Recommandations relatives à l'aménagement du stockage :**

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

    **Avantages des volumes séparés :** 
   + Allocation indépendante d'IOPS
   + Gestion des capacités simplifiée
   + Stratégies de sauvegarde et de capture d'écran simplifiées
   + Meilleure isolation des performances

1.  Établissez un plan de réduction :

   Ayez toujours une stratégie de rollback :
   + **Maintenir l'instance RDS Custom en cours d'exécution** pendant la période de validation (1 à 2 semaines recommandées)
   + **Maintenez des sauvegardes régulières** de la source et de la cible
   + **Procédures de restauration des documents, y compris les** modifications des chaînes de connexion
   + **Tester le processus d'annulation** dans un environnement hors production
   + **Définissez les critères d'annulation** (dégradation des performances, incohérence des données, erreurs d'application)

### Bonnes pratiques d'exécution de la migration
<a name="RDS-Custom-for-Oracle-end-of-support-migration-best-practices"></a>

1. **Chronométrage de votre migration :**

   Choisissez le créneau horaire optimal :
   + **Low-traffic périodes** : week-ends, jours fériés ou heures creuses
   + **Fenêtres de maintenance** : alignez-vous sur la maintenance planifiée si possible
   + **Évitez les fins de end/quarter mois** : ces périodes sont généralement caractérisées par des volumes de transactions élevés
   + **Tenez compte des fuseaux horaires** : pour les applications internationales, choisissez une heure qui minimise l'impact entre les régions

1. **Plan de communication :**

   Établissez une communication claire :
   + **Notification des parties prenantes** : Informez toutes les parties prenantes au moins 2 semaines à l'avance
   + **Équipes d'application** : coordination avec les équipes d'application pour les mises à jour des chaînes de connexion
   + **Mises à jour du statut** : fournissez des mises à jour régulières pendant la migration
   + Procédure d'**escalade** : définissez des procédures d'escalade claires pour les problèmes
   + **Post-migration communication** : Confirmez l'achèvement réussi et toute action de suivi

1. **Points de contrôle de validation :**

   Mettez en œuvre la validation à chaque étape :

    **Pre-migration validation :** 

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

    **Post-migration validation :** 

   ```
   -- 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. **Validation des performances :**

   Comparez les indicateurs de performance avant et après la migration :

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

   Principaux indicateurs à comparer :
   + Sessions actives en moyenne
   + Durée de base de données par transaction
   + Lectures physiques par seconde
   + Lectures logiques par seconde
   + Rétablir la taille par seconde
   + Appels de l'utilisateur par seconde
   + Temps d'analyse par exécution

### Post-migration optimisation
<a name="RDS-Custom-for-Oracle-end-of-support-best-practices-post-migration-optimization"></a>

1. Après la migration, optimisez les performances de la base de données :

   1. **Réglage des performances des bases de données :**

       **Recueillez des statistiques :** 

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

      **Optimisez les paramètres de mémoire :**

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

      **Configurez le cache des résultats :**

      ```
      -- 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. Optimisation du stockage :

      **Activez la compression :**

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

      **Implémenter le partitionnement :**

      ```
      -- 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. Mettre en œuvre la surveillance et les alertes :

      **CloudWatch métriques personnalisées :**

      Créez un script pour publier les métriques Oracle pour 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.)
      ```

      **Configurez les CloudWatch alarmes :**

      ```
      # 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. Renforcement de la sécurité :

      **Sécurité des bases de données :**

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

      **Sécurité du réseau :**

      ```
      # 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. Stratégie de sauvegarde et de restauration :

   **Mettez en œuvre une stratégie de sauvegarde complète :**

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

   **Planifiez des sauvegardes avec 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
   ```

### Optimisation des coûts
<a name="RDS-Custom-for-Oracle-end-of-support-cost-optimization"></a>

 **1. Right-sizing**: 

Après la migration, surveillez et optimisez les coûts :
+ **Utilisez AWS Cost Explorer** pour analyser les coûts EC2 et EBS
+ **Activez AWS Compute Optimizer** pour obtenir des recommandations sur les types d'instance
+ Passez en **revue CloudWatch les indicateurs** pour identifier les ressources sous-utilisées
+ **Envisagez les instances réservées ou les** Savings Plans pour des charges de travail prévisibles

 **2. Optimisation du stockage :** 
+ **Mettre en œuvre des politiques de cycle** de vie pour les sauvegardes S3 (migration vers Glacier après 30 jours)
+ **Supprimez régulièrement les instantanés EBS inutilisés**
+ **Utilisez gp3 au lieu de gp2** pour réaliser des économies avec les mêmes performances
+ **Détachez et supprimez les volumes de sauvegarde une** fois la migration terminée

 **3. Automatisation :** 
+ **Automatisation start/stop** des bases de données hors production en dehors des heures de bureau
+ **Utiliser AWS Systems Manager** pour la gestion des correctifs
+ **Implémenter l'auto-scaling** pour les répliques de lecture si vous utilisez Data Guard

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

Ce guide prescriptif fournit des stratégies de migration détaillées pour déplacer vos bases de données Oracle d'Amazon RDS Custom for Oracle vers des bases de données Oracle autogérées sur Amazon EC2. Le service RDS Custom for Oracle étant devenu obsolète à compter du 31 mars 2027, il est important de planifier et d'exécuter votre migration bien à l'avance.

 **Principaux points à retenir** 

 **Options de migration :** 
+ **Duplication active RMAN** : idéale pour la plupart des migrations, permet de maintenir la base de données source en ligne pendant la duplication, ne nécessite qu'une brève fenêtre de transition pour la redirection des applications
+ **Oracle Data Guard : idéal** pour les charges de travail critiques ne nécessitant pratiquement aucune interruption de service, offrant une synchronisation continue et une fonctionnalité de commutation intégrée

 **Support d'architecture :** 
+ Les deux options de migration prennent en charge les architectures non CDB (instance unique traditionnelle) et multilocataires (CDB avec PDB)
+ Pour le multitenant, les deux méthodes gèrent automatiquement l'ensemble du CDB, y compris tous les PDB, en une seule opération
+ Les PDB nécessitent une ouverture manuelle et une configuration d'ouverture automatique après la migration

 **Facteurs de réussite essentiels :** 
+ Configuration réseau et connectivité appropriées entre la source et la cible
+ Compatibilité exacte des versions (version majeure, version mineure, mise à jour et correctifs ponctuels)
+ Bande passante réseau adéquate pour le transfert de données (RMAN) ou le redo shipping (Data Guard)
+ Comprendre que la duplication active RMAN permet de maintenir la source en ligne : seule une brève transition est nécessaire
+ Tests et validation approfondis avant la mise hors service de la source
+ Tâches complètes après la migration, y compris la sauvegarde, la surveillance et la configuration de sécurité

 **Prochaines étapes :** 

1. Évaluez l'architecture de votre base de données (non CDB ou mutualisée)

1. Choisissez l'option de migration appropriée en fonction de votre tolérance aux interruptions de service et de vos exigences en matière de complexité

1. Effectuez toutes les étapes préalables, y compris la configuration de l'instance EC2 et la configuration réseau

1. Suivez les étapes de migration détaillées pour l'option que vous avez choisie

1. Effectuez une validation et des tests approfondis

1. Effectuez les tâches post-migration pour garantir la disponibilité de la production

1. Mettez hors service l'instance personnalisée RDS après une validation réussie

 **Ressources supplémentaires** 
+ [Guide de l'utilisateur d'Amazon RDS Custom pour Oracle](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom.html)
+ [Documentation de base de données Oracle](https://docs.oracle.com/en/database/)
+ [Documentation Oracle RMAN](https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/)
+ [Documentation d'Oracle Data Guard](https://docs.oracle.com/en/database/oracle/oracle-database/19/sbydb/)
+ [AWS Service de Migration de Base de Données](https://aws.amazon.com/dms/)
+ [AWS Directives prescriptives](https://aws.amazon.com/prescriptive-guidance/)

 **Support** 

Pour obtenir de l'aide lors de votre migration :
+ Contacter AWS le support via la console AWS de gestion
+ Consultez le support Oracle pour les questions spécifiques à la base de données

## **Informations sur le document**
<a name="RDS-Custom-for-Oracle-end-of-support-document-information"></a>

**Dernière mise à jour :** mars 2026

**Contributeurs :**
+ Sharath Chandra Kampili, architecte de solutions spécialiste des bases de données, Amazon Web Services
+ Ibrahim Emara, architecte de solutions spécialisé dans les bases de données, Amazon Web Services
+ Vetrivel Subramani, architecte de solutions spécialisé dans les bases de données, Amazon Web Services