Pourquoi apparaît le message d'erreur « Sequence doesn't exist » (La séquence n'existe pas) lors de l'exécution de ma tâche de CDC AWS DMS utilisant Oracle comme source ?

Brève description

Lorsque vous utilisez une base de données Oracle comme source pour votre tâche de migration, AWS DMS extrait les données de la table pendant la phase de chargement complet. Au cours de la phase de CDC, AWS DMS lit les journaux archived redo logs. Ensuite, AWS DMS les capture depuis la base de données Oracle source, puis applique uniquement à la base de données cible les modifications validées.

Il est possible qu'une erreur de journal de séquence ressemblant à la suivante apparaisse :

« 03980512: 2022-05-23T12:33:11 [SOURCE_CAPTURE ]E: Archived Redo log with the sequence 232488 does not exist, thread 1 [1022318] (oradcdc_thread.c:624 » (Le journal archived redo log avec la séquence 232488 n'existe pas)

Afin de résoudre cette erreur, procédez comme suit :

1.    Exécutez cette requête sur la base de données Oracle source afin de vérifier si la séquence archive log est présente sur la source. Par exemple, cette requête vérifie la séquence redo log 232488 :

select name, dest_id, thread#,
sequence#, archived, applied, deleted, status, first_time, next_time, 
completion_time  from v$archived_log where sequence# =232488;

2.    Exécutez cette commande à l'emplacement des fichiers archive log sur le serveur source. Cette commande vérifie si le fichier archive log est physiquement présent :

ls -l * 232488*

3.    Vérifiez la destination du fichier archivelog (log_archive_dest) sur la base de données Oracle source.

Cet article traitent deux différentes causes pouvant être à l'origine de cette erreur :

• AWS DMS recherche le journal redo log dans le mauvais DEST_ID
• La colonne DEL indique YES (OUI) et la séquence archivelog n'existe pas sur la base de données Oracle source

Solution

Exemple 1 : AWS DMS recherche le journal redo log dans le mauvais DEST_ID

L'erreur indique que la séquence archived redo log 232488 n'existe pas dans la base de données Oracle source. Cela peut se produire si le journal est supprimé de la base de données Oracle source. Cela entraîne l'échec de la tâche.

01788702: 2022-06-07T17:10:31:206453 [SOURCE_CAPTURE  ]D:  Going to 
prepare the statement 'select supplemental_log_data_min, DATABASE_ROLE, 
SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_ALL from v$database'  
(oracle_endpoint_conn.c:114)

01788702: 2022-06-07T17:10:31:209648 [SOURCE_CAPTURE  ]I:  Database role is 'PHYSICAL STANDBY'  (oracle_endpoint_conn.c:139)

1.    Exécutez cette requête sur la base de données source afin de vérifier si la séquence archive log 232488 existe dans la source :

select name, dest_id, thread#, sequence#, archived, applied, deleted, 
status, first_time, next_time, completion_time  from v$archived_log 
where sequence# in (232488);

Sortie :

NAME                                             DEST_ID    THREAD#  SEQUENCE# ARC APPLIED   DEL S FIRST_TIM NEXT_TIME COMPLETIO

--------------------------------------------- ---------- ---------- ---------- --- --------- --- - --------- --------- ---------

/orafra/prdsvbo/arc/1_232488_950180179.arc             2          1     232488 YES YES       NO  A 07-JUN-22 07-JUN-22 07-JUN-22

2.    Vérifiez la colonne DEL. Si cette colonne indique NO (NON), la séquence archivedlog existe dans la base de données source. Si elle indique YES (OUI), la séquence archiveredlog n'existe pas. Il est possible qu'elle ait été purgée de la source en raison du paramétrage de la période de conservation.

Dans cet exemple, la sortie indique que la séquence archivelog existe dans la source. Cependant, un message d'erreur indiquant que la séquence n'existe pas continue à apparaître lors de l'exécution de la tâche AWS DMS. Afin de résoudre les problèmes apparaissant lorsque la colonne DEL indique YES (OUI), consultez l'exemple 2.

3.    Ensuite, vérifiez la colonne DEST_ID. Par défaut, AWS DMS capture les journaux redo logs sur DEST_ID 1. Dans cet exemple, l'extrait suivant apparaît dans les journaux :

01788702: 2022-06-07T17:10:31:658376 [SOURCE_CAPTURE  ]I:  Used Oracle archived Redo log destination id is '1'  (oracdc_merger.c:639)

01788702: 2022-06-07T17:10:31:658420 [SOURCE_CAPTURE  ]I:  Oracle instance uses more than one archived Redo log destination id. Please configure the correct destination id, if Redo logs of '1' destination cannot be accessed  (oracdc_merger.c:642)

Par conséquent, la tâche AWS DMS échoue car elle recherche le journal redo log dans DEST_ID 1, alors que celui-ci se trouve dans DEST_ID 2.

4.    Afin de contourner cette erreur, utilisez cet attribut de connexion supplémentaire (ECA) dans le point de terminaison source :

additionalArchivedLogDestId=2

Pour plus d'informations sur additionalArchivedLogDestID, veuillez consulter la section Types de données sources pour Oracle.

5.    Après avoir configuré l'ECA, exécutez de nouveau la tâche AWS DMS. Dans cet exemple, les journaux indiquent qu'AWS DMS peut désormais capturer la séquence redo log 232488 disponible depuis DEST_ID 2.

01898667: 2022-06-08T05:45:08:535588 [SOURCE_CAPTURE  ]D:  Going to retrieve archived REDO log with sequence 232488, thread 1  (oradcdc_thread.c:510)

01898667: 2022-06-08T05:45:08:535607 [SOURCE_CAPTURE  ]T:  Use a prepared statement to access v$archived_log, thread 1  (oradcdc_thread.c:587)

01898667: 2022-06-08T05:45:08:598396 [SOURCE_CAPTURE  ]D:  Going to open Redo Log with original name '/orafra/prdsvbo/arc/1_232488_950180179.arc', thread id '1'  (oradcdc_redo.c:492)

01898667: 2022-06-08T05:45:08:599614 [SOURCE_CAPTURE  ]D:  archived Redo log '/orafra/prdsvbo/arc/1_232488_950180179.arc' with sequence 232488 is opened, thread id '1'  (oradcdc_redo.c:747)

Exemple 2 : la colonne DEL indique YES (OUI) et la séquence archivelog n'existe pas sur la base de données Oracle source

Comme indiqué précédemment à l'étape 2, si la colonne DEL indique YES (OUI), il est possible que la séquence archivelog ait été purgée de la base de données Oracle source.

Remarque : les instances Oracle suppriment les fichiers archive log afin de réduire l'espace occupé.

Étapes à suivre pour les cas d'utilisation sur site ou Amazon Elastic Compute Cloud (Amazon EC2)

Si vous avez programmé le Recovery Manager (RMAN) avec la commande « delete noprompt archivelog until time SYSDATE-1 », cela supprime l'ensemble des fichiers archive logs datant de plus d'un jour. Si vous voulez augmenter cette période, modifiez cette commande en remplaçant SYSDATE-1 par SYSDATE-2 ou désactivez la planification.

Suivez ces étapes afin de vérifier et augmenter la période de conservation.

1.    Connectez-vous au RMAN.

2.    Afficher tout :

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

Remarque : la valeur par défaut de la politique de suppression Archivelog est NONE (AUCUNE).

3.    Remplacez la valeur de la politique de suppression par une valeur suffisante pour conserver les journaux archivelogs sur la base de données sur site source :

CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP integer TIMES TO DEVICE TYPE

  CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO SBT;

Étapes pour Amazon RDS

Amazon RDS supprime les fichiers archive log toutes les cinq minutes et en conserve une copie dans un compartiment Amazon Simple Storage Solution (Amazon S3). Vous pouvez utiliser cette copie afin d'effectuer une restauration à un point antérieur.    

1.    Augmentez la période de conservation des fichiers archive log en suivant les étapes de la section Exécution des tâches courantes liées au journal pour les instances de base de données Oracle.    

2.    Vérifiez la période de conservation définie pour les fichiers archive logs :

exec RDSADMIN.RDSADMIN_UTIL.SHOW_CONFIGURATION;

3.    Vérifiez si le fichier archive log que vous avez extrait dans la requête précédente est physiquement disponible sur le serveur de base de données source.

SQL>select name, archived, deleted, status, sequence# from v$archived_log where sequence# = 232488;

Remarque : dans Amazon RDS, la colonne supprimée indique NO (NON), même si elle a été purgée. Cette information provient du fichier de contrôle.

4.    Afin de vérifier si le journal redo log existe dans Amazon RDS, exécutez la requête suivante :

select * from table(RDSADMIN.RDS_FILE_UTIL.LISTDIR('ARCHIVELOG_DIR')) where filename='redolog-5924417-1-1013939085.arc' order by mtime desc;

Remarque : AWS DMS ne contrôle pas la purge des fichiers archive redo logs. Les journaux archive redo logs sont purgés par la base de données source sur site ou RDS for Oracle. Au lieu de cela, AWS DMS confirme qu'il ne trouve pas le journal lorsqu'il essaie de traiter le LSN suivant.

5.    S'il est disponible, restaurez le journal archive log manquant de la séquence 232488 dans la destination source, puis exécutez de nouveau la tâche. L'ensemble des journaux redo logs suivant 232488 doivent être présents sur la source afin que vous puissiez exécutez de nouveau la tâche AWS DMS avec succès.

Si vous ne parvenez pas à restaurer la séquence archive log manquante, essayez de redémarrer la tâche à partir de la phase de chargement complet, puis recommencez la migration.

---

Informations connexes

Attributs de connexion supplémentaires lors de l'utilisation d'Oracle comme source pour AWS DMS

Utilisation d'une base de données Oracle comme source pour AWS DMS

Exécution des tâches courantes liées au journal pour les instances de base de données Oracle