Résolution de problèmes de point de terminaison Oracle - AWS Service de Migration de Base de Données
Lecture source interrompueHaute génération de journaux redo

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.

Résolution de problèmes de point de terminaison Oracle

Cette section contient des scénarios de réplication spécifiques à Oracle.

Lecture source interrompue

AWS DMS interrompt la lecture à partir d'une source Oracle dans les scénarios suivants. Ce comportement est intégré à la conception. Vous pouvez en rechercher les causes à l’aide du journal des tâches. Recherchez les messages similaires aux suivants dans le journal des tâches. Pour en savoir plus sur l’utilisation du journal des tâches, consultez Affichage et gestion des journaux des tâches AWS DMS.

  • SORTERmessage : Cela indique que les transactions DMS sont mises en cache sur l'instance de réplication. Pour plus d'informations, consultez SORTERmessage dans le journal des tâches, ci-après.

  • Journaux des tâches de débogage : si le DMS processus de lecture est interrompu, votre tâche écrit à plusieurs reprises le message suivant dans les journaux des tâches de débogage, sans modifier le champ de contexte ni l'horodatage :

    • Binary Reader : 

      [SOURCE_CAPTURE  ]T:  Produce CTI event: 
context '00000020.f23ec6e5.00000002.000a.00.0000:190805.3477731.16' 
xid [00000000001e0018] timestamp '2021-07-19 06:57:55' 
thread 2  (oradcdc_oralog.c:817)

    • Logminer : 

      [SOURCE_CAPTURE  ]T:  Produce INSERT event: 
object id 1309826 context '000000000F2CECAA010000010005A8F500000275016C0000000000000F2CEC58' 
xid [000014e06411d996] timestamp '2021-08-12 09:20:32' thread 1  (oracdc_reader.c:2269)

  • AWS DMS enregistre le message suivant pour chaque nouvelle opération de restauration ou de journalisation archivée.

    00007298: 2021-08-13T22:00:34 [SOURCE_CAPTURE ]I: Start processing archived Redo log sequence 14850 thread 2 name XXXXX/XXXXX/ARCHIVELOG/2021_08_14/thread_2_seq_14850.22977.1080547209 (oradcdc_redo.c:754)

    Si la source dispose de nouvelles opérations de rétablissement ou d'archivage des opérations de journalisation, et qu'elle AWS DMS n'écrit pas ces messages dans le journal, cela signifie que la tâche ne traite pas les événements.

Haute génération de journaux redo

Si votre tâche traite des journaux redo ou d’archivage, mais que la latence source reste élevée, essayez d’identifier le taux de génération de journaux redo et les modèles de génération. Si le niveau de génération de journaux redo est élevé, cela augmente la latence source, car votre tâche lit tous les journaux redo et d’archivage afin d’extraire les modifications relatives aux tables répliquées.

Pour déterminer le taux de génération de journaux redo, utilisez les requêtes suivantes.

  • Taux de génération de journaux redo par jour :

    select trunc(COMPLETION_TIME,'DD') Day, thread#, 
round(sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024) GB,
count(*) Archives_Generated from v$archived_log 
where completion_time > sysdate- 1
group by trunc(COMPLETION_TIME,'DD'),thread# order by 1;

  • Taux de génération de journaux redo par heure :

    Alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS';
select trunc(COMPLETION_TIME,'HH') Hour,thread# , 
round(sum(BLOCKS*BLOCK_SIZE)/1024/1024) "REDO PER HOUR (MB)",
count(*) Archives from v$archived_log 
where completion_time > sysdate- 1
group by trunc(COMPLETION_TIME,'HH'),thread#  order by 1 ;

Pour résoudre les problèmes de latence dans ce scénario, procédez aux vérifications suivantes :

  • Vérifiez la bande passante du réseau et les performances mono-thread de la réplication pour vous assurer que votre réseau sous-jacent peut prendre en charge le taux de génération de journaux redo de la source. Pour en savoir plus sur la manière dont la bande passante du réseau peut affecter les performances de réplication, consultez Vitesse et bande passante du réseau précédemment.

  • Vérifiez si vous avez correctement configuré la journalisation supplémentaire. Évitez une journalisation supplémentaire sur la source, comme l’activation de la journalisation sur toutes les colonnes d’une table. Pour en savoir plus sur la configuration d’une journalisation supplémentaire, consultez Configurez une journalisation supplémentaire.

  • Vérifiez que vous utilisez la bonne méthode API pour lire les journaux restaurés ou archivés. Vous pouvez utiliser Oracle LogMiner ou AWS DMS Binary Reader. Tout en LogMiner lisant les journaux de journalisation en ligne et les fichiers de journalisation archivés, Binary Reader lit et analyse directement les fichiers de journalisation bruts. Par conséquent, Binary Reader est plus performant. Nous vous recommandons d’utiliser Binary Reader si votre génération de journaux redo dépasse 10 Go/heure. Pour de plus amples informations, veuillez consulter Utilisation d'Oracle LogMiner ou de AWS DMS Binary Reader pour le CDC.

  • Vérifiez si vous avez défini ArchivedLogsOnly sur Y. Si ce paramètre de point de terminaison est défini, AWS DMS lit les journaux redo archivés. Cela augmente la latence de la source, car il AWS DMS attend que le journal de restauration en ligne soit archivé avant de le lire. Pour plus d'informations, consultez ArchivedLogsOnly.

  • Si votre source Oracle utilise la gestion automatique du stockage (ASM), consultez Stockage de REDO sur Oracle ASM lors de l'utilisation d'Oracle comme source pour AWS DMS pour savoir comment configurer correctement votre magasin de données. Vous pouvez également optimiser davantage les performances de lecture en utilisant l'attribut de connexion asmUsePLSQLArray supplémentaire (). ECA Pour obtenir des informations sur l'utilisation d'asmUsePLSQLArray, veuillez consulter Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS.