Fin du support de RDS Custom pour Oracle

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.

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

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

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

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

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

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

5. 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 :

   Exemple 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

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

6. Vérifier la configuration de la 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 :

   Exemple

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

2. Connectez-vous à la base de données et vérifiez l'architecture :

   Exemple

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

   Exemple Pour Non-CDB, résultat attendu

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

   Exemple Pour Multitenant (CDB), résultat attendu :

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

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

   Exemple

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

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

   Exemple

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

4. Vérifiez la taille totale de la base de données :

   Exemple Pour Non-CDB :

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

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

Chronologie typique

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

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

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

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

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

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

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

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

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

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

2. Configurer tnsnames.ora sur EC2

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

4. Configuration d'Oracle Listener sur EC2

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

Étapes de duplication RMAN :

1. Réaliser une duplication active RMAN

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

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

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

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

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

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

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

3. Supprimer les paramètres RDS Custom-specific

   • dg_broker_config_file1et 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)

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

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

Le processus de duplication active RMAN comprend plusieurs phases :

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

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

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

4. Montage de la base de données cible

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

6. Restauration de la base de données cible

7. Ouverture de la base de données cible avec RESETLOGS

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

   Exemple 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

2. Surveillez les opérations de longue durée :

   Exemple 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

3. Surveillez les canaux RMAN :

   Exemple

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

4. Vérifiez le journal des alertes :

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Configurez tnsnames.ora sur les deux instances

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

4. Activer la configuration d'Oracle Data Guard

5. Configurer fal_server et fal_client sur l'instance de secours EC2

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

7. Restaurez l'instance de secours

8. Procéder à la commutation manuelle

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

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

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

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

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

2. Modifiez db_unique_name : de (ou) à ORCL_A RDSCDB_A ORCL_B

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

4. Supprimer les paramètres RDS Custom-specific

   • dg_broker_config_file1et 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

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

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

2. 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;

3. 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;

4. 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;

5. 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';

6. 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;

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

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

3. Réessayez le drop :

   sqlplus / as sysdba
   SQL> DROP USER RDSADMIN CASCADE;

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;

2. Vérifiez le niveau du correctif $ORACLE_HOME :

   # On both instances
   $ORACLE_HOME/OPatch/opatch lsinventory

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

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

   cd $ORACLE_HOME/OPatch
   ./datapatch -verbose

5. 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;

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

2. Vérifiez iptables sur EC2 :

   sudo iptables -L INPUT -n -v

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

4. Testez la connectivité :

   telnet <EC2_instance_IP> 1521
   tnsping DB_SOURCE
   tnsping DB_TARGET

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

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

2. 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';

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

1. Forcer l'enregistrement du service :

   SQL> ALTER SYSTEM REGISTER;

2. 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;

3. Vérifiez auprès de :

   lsnrctl services

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

   SQL> SELECT status FROM v$instance;

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

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

   tnsping ORCL_A # or RDSCDB_A for multitenant

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

1. Vérifiez le taux applicable :

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

2. 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;

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

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;

2. 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;
   }

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

2. Documenter la migration : mettre à jour les runbooks et la documentation avec la nouvelle configuration EC2

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

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

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

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

2. Choisissez le bon type d'instance EC2 :

   Sélectionnez un type d'instance EC2 en fonction des caractéristiques de votre charge de travail :

   Type de charge de travail	Famille d'instances recommandée	Caractéristiques principales
   OLTP à usage général	M6i, M6a, M7i	Calcul, mémoire et réseau équilibrés
   Memory-intensive	R6i, R6a, R7i, X2idn	Rapport mémoire/processeur élevé
   Compute-intensive	C6i, C6a, C7i	Performances élevées du processeur
   I/O-intensive	i4I, IM4GN	Stockage SSD NVMe local élevé
   Charges de travail mixtes	M5, M5a, M5n	Cost-effective performance équilibrée

   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

3. Concevez votre architecture de stockage :

   Types de volumes EBS :

   Type de volume	Cas d'utilisation	Performances	Coût
   gp3	Usage général, plupart des charges de travail	Jusqu'à 16 000 IOPS, 1 000 MB/s	Faible
   io2 Block Express	Mission-critical, haute performance	Jusqu'à 256 000 IOPS, 4 000 MB/s	Élevée
   Io1	High-performance bases de données	Jusqu'à 64 000 IOPS, 1 000 MB/s	Medium-High
   gp2	Usage général de Legacy	Jusqu'à 16 000 IOPS	Faible

   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

4. É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)

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

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

3. 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;

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

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;

   2. 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)
      );

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

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

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

2. 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é

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

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

5. Effectuez une validation et des tests approfondis

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

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