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 des problèmes de latence dans AWS Database Migration Service
Cette section fournit une vue d'ensemble des causes courantes de latence des AWS DMS tâches pendant la phase de réplication en cours (CDC). AWS DMS réplique les données de manière asynchrone. La latence est le délai entre le moment où une modification est validée sur la source et le moment où la modification est répliquée sur la cible. La latence peut être due à une mauvaise configuration des composants de réplication, tels que :
+ Point de terminaison source ou source de données
+ Point de terminaison cible ou source de données
+ Instances de réplication
+ Le réseau entre ces composants
Nous vous recommandons d’utiliser un test de migration comme preuve de concept, afin de recueillir des informations sur la réplication. Vous pouvez ensuite utiliser ces informations pour ajuster votre configuration de réplication afin de réduire au maximum la latence. Pour en savoir plus sur l’exécution d’une migration faisant office de preuve de concept, consultez [Exécution d’une preuve de concept](CHAP_BestPractices.md#CHAP_BestPractices.RunPOC).
**Topics**
+ [Types de latence de CDC](#CHAP_Troubleshooting_Latency_Types)
+ [Causes courantes de la latence de CDC](#CHAP_Troubleshooting_Latency_Causes)
+ [Résolution des problèmes de latence](CHAP_Troubleshooting_Latency_Troubleshooting.md)
## Types de latence de CDC
Cette section décrit les types de latence de réplication qui peuvent survenir pendant la CDC.
### Latence source
Retard, en secondes, entre l’instant de validation du dernier événement capturé à partir du point de terminaison source et l’horodatage système actuel de l’instance de réplication. Vous pouvez surveiller la latence entre la source de données et votre instance de réplication à l'aide de la `CDCLatencySource` CloudWatch métrique. Une métrique `CDCLatencySource` élevée indique que le processus de capture des modifications depuis la source est retardé. Par exemple, si votre application valide une insertion dans la source à 10 h 00 et AWS DMS prend en compte la modification à 10 h 02, la `CDCLatencySource` métrique est de 120 secondes.
Pour plus d'informations sur CloudWatch les métriques pour AWS DMS, voir[Métriques de tâches de réplication](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task).
### Latence cible
Retard, en secondes, entre l’instant de validation sur la source du dernier événement en attente d’être validé sur la cible et l’horodatage actuel de l’instance de réplication DMS. Vous pouvez surveiller la latence entre les validations sur la source de données et votre cible de données à l'aide de la `CDCLatencyTarget` CloudWatch métrique. Cela signifie que `CDCLatencyTarget` inclut chaque retard de lecture depuis la source. Par conséquent, `CDCLatencyTarget` est toujours supérieur ou égal à `CDCLatencySource`.
Par exemple, si votre application valide une insertion dans la source à 10 h 00, qu'elle la AWS DMS consomme à 10 h 02 et qu'elle l'écrit sur la cible à 10 h 05, la `CDCLatencyTarget` métrique est de 300 secondes.
## Causes courantes de la latence de CDC
Cette section décrit les causes de latence que la réplication peut rencontrer pendant la CDC.
**Topics**
+ [Ressources des points de terminaison](#CHAP_Troubleshooting_Latency_Causes_Endpoint)
+ [Ressources d’instance de réplication](#CHAP_Troubleshooting_Latency_Causes_Replication_Instance)
+ [Vitesse et bande passante du réseau](#CHAP_Troubleshooting_Latency_Causes_Replication_Network)
+ [Configuration DMS](#CHAP_Troubleshooting_Latency_Causes_Replication_DMS_Config)
+ [Scénarios de réplication](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios)
### Ressources des points de terminaison
Les facteurs suivants ont une incidence significative sur les performances et la latence de réplication :
+ Configurations des bases de données source et cible
+ Taille d’instance
+ Magasins de données source ou cible sous-provisionnés ou mal configurés
Pour identifier les causes de latence causées par des problèmes de point de AWS terminaison pour les sources et les cibles hébergées, surveillez les CloudWatch indicateurs suivants :
+ `FreeMemory`
+ `CPUUtilization`
+ Débit et I/O indicateurs, tels que `WriteIOPS``WriteThroughput`, ou `ReadLatency`
+ Métriques de volume de transactions telles que `CDCIncomingChanges`.
Pour plus d'informations sur CloudWatch les métriques de surveillance, consultez[AWS Database Migration Service métriques](CHAP_Monitoring.md#CHAP_Monitoring.Metrics).
### Ressources d’instance de réplication
Les ressources d’instance de réplication sont essentielles à la réplication, et vous devez vous assurer qu’il n’y a pas de goulots d’étranglement liés aux ressources, car ils peuvent entraîner une latence source et cible également.
Pour identifier les goulots d’étranglement de ressources pour votre instance de réplication, vérifiez les points suivants :
+ CloudWatch Les indicateurs critiques tels que le processeur, la mémoire, le débit I/O par seconde et le stockage ne connaissent pas de pics ou de valeurs constamment élevées.
+ La taille de l’instance de réplication est adaptée à la charge de travail. Pour en savoir plus sur la détermination de la taille correcte d’une instance de réplication, consultez [Sélection de la meilleure taille pour une instance de réplication](CHAP_BestPractices.SizingReplicationInstance.md).
### Vitesse et bande passante du réseau
La bande passante du réseau est un facteur qui affecte la transmission des données. Pour analyser les performances réseau de la réplication, effectuez l’une des opérations suivantes :
+ Vérifiez les métriques `ReadThroughput` et `WriteThroughput` au niveau de l’instance. Pour plus d'informations sur CloudWatch les métriques de surveillance, consultez[AWS Database Migration Service métriques](CHAP_Monitoring.md#CHAP_Monitoring.Metrics).
+ Utilisez l'AMI AWS DMS Diagnostic Support. Si l’AMI d’assistance au diagnostic n’est pas disponible dans votre région, vous pouvez la télécharger depuis n’importe quelle région prise en charge et la copier dans votre région pour effectuer l’analyse de votre réseau. Pour en savoir plus sur l’AMI d’assistance au diagnostic, consultez [Utilisation de l'AMI d'assistance au AWS DMS diagnostic](CHAP_SupportAmi.md).
Le CDC in AWS DMS est mono-thread pour garantir la cohérence des données. Par conséquent, vous pouvez déterminer le volume de données que votre réseau peut prendre en charge en calculant votre taux de transfert de données à thread unique. Par exemple, si votre tâche se connecte à sa source via un réseau de 100 Mbits/s (mégabits par seconde), votre réplication dispose d'une allocation de bande passante maximale théorique de 12,5 MBps (mégaoctets par seconde). Cela équivaut à 45 gigabits par heure. Si le taux de génération de journaux de transactions sur la source est supérieur à 45 gigabits par heure, cela signifie que la tâche a une latence de CDC. Pour un MBps réseau 100 %, ces débits sont des maximums théoriques ; d'autres facteurs tels que le trafic réseau et la surcharge de ressources sur la source et la cible réduisent la bande passante réellement disponible.
### Configuration DMS
Cette section contient des configurations de réplication recommandées qui peuvent contribuer à réduire la latence.
+ **Paramètres des points de terminaison** : les paramètres des points de terminaison sources et cibles peuvent nuire aux performances de votre instance de réplication. Les paramètres de point de terminaison qui activent des fonctionnalités gourmandes en ressources auront un impact sur les performances. Par exemple, pour un point de terminaison Oracle, la désactivation LogMiner et l'utilisation de Binary Reader améliorent les performances, car cela demande beaucoup LogMiner de ressources. Le paramètre de point de terminaison suivant améliore les performances d’un point de terminaison Oracle :
```
useLogminerReader=N;useBfile=Y
```
Pour plus d’informations sur les paramètres de point de terminaison, consultez la documentation relative au moteur des points de terminaison sources et cibles dans la rubrique [Utilisation des points de AWS terminaison DMS](CHAP_Endpoints.md).
+ **Paramètres des tâches** : certains paramètres de tâche pour votre scénario de réplication spécifique peuvent nuire aux performances de votre instance de réplication. Par exemple, AWS DMS utilise le mode d’application transactionnel par défaut (`BatchApplyEnabled=false`) pour la CDC pour tous les points de terminaison à l’exception d’Amazon Redshift. Toutefois, pour les sources comportant un grand nombre de modifications, le réglage de `BatchApplyEnabled` sur `true` peut améliorer les performances.
Pour plus d'informations sur les paramètres de tâche, consultez [Spécification des paramètres des tâches pour les tâches du AWS Database Migration Service](CHAP_Tasks.CustomizingTasks.TaskSettings.md).
+ **Position de départ d’une tâche de CDC uniquement** : le démarrage d’une tâche de CDC uniquement à partir d’une position ou d’un horodatage antérieurs entraîne le démarrage de la tâche avec une latence source de CDC accrue. En fonction du volume des modifications apportées à la source, la latence des tâches mettra du temps à s’atténuer.
+ **Paramètres LOB : les** types de données d'objets de grande taille peuvent entraver les performances de réplication en raison de la manière dont les données binaires volumineuses sont AWS DMS répliquées. Pour plus d’informations, consultez les rubriques suivantes :
+ [Configuration du support LOB pour les bases de données sources dans une tâche AWS DMS](CHAP_Tasks.LOBSupport.md)
+ [Migration d'objets binaires de grande taille () LOBs](CHAP_BestPractices.md#CHAP_BestPractices.LOBS).
### Scénarios de réplication
Cette section décrit des scénarios de réplication spécifiques et la manière dont ils peuvent affecter la latence.
**Topics**
+ [Arrêt d’une tâche pour une période de temps prolongée](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Stoptask)
+ [Modifications mises en cache](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Cachedchanges)
+ [Réplication entre régions](#CHAP_Troubleshooting_Latency_Causes_Replication_Scenarios_Crossregion)
#### Arrêt d’une tâche pour une période de temps prolongée
Lorsque vous arrêtez une tâche, AWS DMS enregistre la position du dernier journal de transactions lu depuis la source. Lorsque vous reprenez la tâche, DMS essaie de poursuivre la lecture à partir de la même position dans le journal des transactions. La reprise d’une tâche après plusieurs heures ou plusieurs jours entraîne l’augmentation de la latence source de CDC jusqu’à ce que DMS ait fini de consommer le backlog des transactions.
#### Modifications mises en cache
Les **modifications mises en cache** sont des modifications que votre application écrit dans la source de données lors de l' AWS DMS exécution de la phase de réplication à chargement complet. DMS n’applique pas ces modifications tant que la phase de chargement complet n’est pas terminée et que la phase de CDC ne démarre pas. Pour une source comportant un grand nombre de transactions, les modifications mises en cache mettent plus de temps à s’appliquer, de sorte que la latence source augmente lorsque la phase de CDC démarre. Nous vous recommandons d’exécuter la phase de chargement complet lorsque les volumes de transactions sont faibles afin de minimiser le nombre de modifications mises en cache.
#### Réplication entre régions
La localisation de vos points de terminaison DMS ou de votre instance de réplication dans différentes AWS régions augmente la latence du réseau. Cela augmente la latence de réplication. Pour des performances optimales, localisez votre point de terminaison source, votre point de terminaison cible et votre instance de réplication dans la même AWS région.
# Résolution des problèmes de latence
Cette section contient les étapes de résolution des problèmes de latence de réplication.
Pour résoudre un problème de latence, procédez comme suit :
+ Commencez par déterminer le type et le degré de latence de la tâche. Consultez la section Statistiques de table de la tâche dans la console ou l’interface de ligne de commande DMS. Si les compteurs changent, la transmission des données est en cours. Vérifiez les métriques `CDCLatencySource` et `CDCLatencyTarget` ensemble pour déterminer s’il y a un goulot d’étranglement pendant la CDC.
+ Si des métriques `CDCLatencySource` ou `CDCLatencyTarget` élevées indiquent la présence d’un goulot d’étranglement dans la réplication, vérifiez les points suivants :
+ Si la valeur `CDCLatencySource` est élevée et `CDCLatencyTarget` égale à`CDCLatencySource`, cela indique qu'il existe un goulot d'étranglement dans votre point de terminaison source et que l'écriture des données vers la cible AWS DMS se fait de manière fluide. Consultez [Résolution des problèmes de latence source](CHAP_Troubleshooting_Latency_Source.md) ci-dessous.
+ Si la `CDCLatencySource` valeur est faible ou `CDCLatencyTarget` élevée, cela indique qu'il existe un goulot d'étranglement dans votre point de terminaison cible et que la lecture des données depuis la source AWS DMS se fait de manière fluide. Consultez [Résolution des problèmes de latence cible](CHAP_Troubleshooting_Latency_Target.md) ci-dessous.
+ Si la valeur `CDCLatencySource` est élevée et que la valeur `CDCLatencyTarget` est nettement supérieure à `CDCLatencySource`, cela indique des goulots d’étranglement à la fois pour les lectures sources et les écritures cibles. Commencez par étudier la latence source, puis étudiez la latence cible.
Pour en savoir plus sur la surveillance des métriques des tâches DMS, consultez [Surveillance des AWS tâches DMS](CHAP_Monitoring.md).
# Résolution des problèmes de latence source
Les rubriques suivantes décrivent des scénarios de réplication spécifiques aux types de point de terminaison source.
**Topics**
+ [Résolution de problèmes de point de terminaison Oracle](CHAP_Troubleshooting_Latency_Source_Oracle.md)
+ [Résolution des problèmes liés aux points de terminaison MySQL](CHAP_Troubleshooting_Latency_Source_MySQL.md)
+ [Résolution des problèmes liés aux points de terminaison PostgreSQL](CHAP_Troubleshooting_Latency_Source_PostgreSQL.md)
+ [Résolution des problèmes liés aux points de terminaison SQL Server](CHAP_Troubleshooting_Latency_Source_SQLServer.md)
# 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 AWS de tâches DMS](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs).
+ **Message SORTER** : indique que DMS met en cache les transactions sur l’instance de réplication. Pour plus d'informations, consultez [Message SORTER dans le journal des tâches](CHAP_Troubleshooting_Latency_Target.md#CHAP_Troubleshooting_Latency_Target_Sorter), ci-après.
+ **Journaux des tâches de débogage** : si DMS interrompt le processus de lecture, 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](CHAP_Troubleshooting_Latency.md#CHAP_Troubleshooting_Latency_Causes_Replication_Network) 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](CHAP_Source.Oracle.md#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging).
+ Vérifiez que vous utilisez l’API appropriée pour lire les journaux redo et d’archivage. 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](CHAP_Source.Oracle.md#CHAP_Source.Oracle.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 de plus amples informations, veuillez consulter [ArchivedLogsOnly](https://docs.aws.amazon.com/dms/latest/APIReference/API_OracleSettings.html#DMS-Type-OracleSettings-ArchivedLogsOnly).
+ Si votre source Oracle utilise Automatic Storage Management (ASM), consultez [Stockage de REDO sur Oracle ASM lors de l'utilisation d'Oracle comme source pour AWS DMS](CHAP_Source.Oracle.md#CHAP_Source.Oracle.REDOonASM) pour en savoir plus sur la manière de configurer correctement votre magasin de données. Vous pouvez également optimiser davantage les performances de lecture en utilisant l’attribut de connexion supplémentaire (ECA) `asmUsePLSQLArray`. 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](CHAP_Source.Oracle.md#CHAP_Source.Oracle.ConnectionAttrib).
# Résolution des problèmes liés aux points de terminaison MySQL
Cette section contient des scénarios de réplication spécifiques à MySQL. AWS DMS analyse régulièrement le journal binaire MySQL pour répliquer les modifications. Ce processus peut augmenter la latence dans les scénarios suivants :
**Topics**
+ [Transaction de longue durée sur la source](#CHAP_Troubleshooting_Latency_Source_MySQL_Longrunning)
+ [Charge de travail élevée sur la source](#CHAP_Troubleshooting_Latency_Source_MySQL_Highworkload)
+ [Contention des journaux binaires](#CHAP_Troubleshooting_Latency_Source_MySQL_Binarylog)
## Transaction de longue durée sur la source
Comme MySQL écrit uniquement les transactions validées dans le journal binaire, les transactions de longue durée provoquent des pics de latence proportionnels à la durée d’exécution des requêtes.
Pour identifier les transactions de longue durée, utilisez la requête suivante ou utilisez le journal des requêtes lentes :
```
SHOW FULL PROCESSLIST;
```
Pour plus d’informations sur l’utilisation du journal des requêtes lentes, consultez [The Slow Query Log](https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) dans la [documentation MySQL](https://dev.mysql.com/doc/).
Pour éviter les pics de latence liés aux transactions de longue durée, restructurez vos transactions sources afin de réduire le temps d’exécution des requêtes ou d’augmenter la fréquence de validation.
## Charge de travail élevée sur la source
La CDC DMS étant monothread, un grand nombre de transactions peut augmenter la latence source. Pour déterminer si la latence source est due à une charge de travail importante, comparez le nombre et la taille des journaux binaires générés pendant la période de latence aux journaux générés avant cette latence. Pour vérifier les journaux binaires et le statut du thread de CDC DMS, utilisez les requêtes suivantes :
```
SHOW BINARY LOGS;
SHOW PROCESSLIST;
```
Pour plus d’informations sur les états des threads de vidage de journaux binaires de CDC, consultez [Replication Source Thread States](https://dev.mysql.com/doc/refman/8.0/en/source-thread-states.html).
Vous pouvez déterminer la latence en comparant la dernière position du journal binaire générée sur la source avec l’événement en cours de traitement par DMS. Pour identifier le dernier journal binaire de la source, procédez comme suit :
+ Activez les journaux de débogage sur le composant SOURCE\$1CAPTURE.
+ Récupérez le journal binaire de traitement DMS et les détails de position dans les journaux de débogage des tâches.
+ Utilisez la requête suivante pour identifier le dernier journal binaire de la source :
```
SHOW MASTER STATUS;
```
Pour optimiser davantage les performances, réglez `EventsPollInterval`. Par défaut, DMS interroge le journal binaire toutes les 5 secondes, mais vous pouvez améliorer les performances en réduisant cette valeur. Pour plus d'informations sur le paramètre `EventsPollInterval`, consultez [Paramètres du point de terminaison lors de l'utilisation de MySQL comme source pour AWS DMS](CHAP_Source.MySQL.md#CHAP_Source.MySQL.ConnectionAttrib).
## Contention des journaux binaires
Lorsque vous migrez plusieurs tables contenant une grande quantité de données, nous vous recommandons de les diviser en tâches distinctes pour MySQL 5.7.2 ou version ultérieure. Dans MySQL versions 5.7.2 et ultérieures, le thread de vidage principal réduit le nombre de conflits de verrouillage et améliore le débit. Par conséquent, le thread de vidage ne verrouille plus le journal binaire chaque fois qu’il lit un événement. Cela signifie que plusieurs threads de vidage peuvent lire le fichier journal binaire simultanément. Cela signifie également que les threads de vidage peuvent lire le journal binaire pendant que les clients écrivent dans celui-ci. Pour plus d’informations sur les threads de vidage, consultez [Replication Threads](https://dev.mysql.com/doc/refman/8.0/en/replication-threads.html) et les [notes de mise à jour de MySQL 5.7.2](https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-2.html).
Pour améliorer les performances de réplication pour les versions sources MySQL antérieures à 5.7.2, essayez de consolider les tâches avec les composants CDC.
# Résolution des problèmes liés aux points de terminaison PostgreSQL
Cette section contient des scénarios de réplication spécifiques à PostgreSQL.
**Topics**
+ [Transaction de longue durée sur la source](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning)
+ [Charge de travail élevée sur la source](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload)
+ [Débit réseau élevé](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork)
+ [Déversez des fichiers dans Aurora PostgreSQL](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill)
## Transaction de longue durée sur la source
Lorsque la base de données source contient des transactions de longue durée, telles que des milliers d’insertions dans une seule transaction, les compteurs de transactions et d’événements CDC DMS n’augmentent pas tant que la transaction n’est pas terminée. Ce retard peut entraîner des problèmes de latence que vous pouvez mesurer à l’aide de la métrique `CDCLatencyTarget`.
Pour examiner les transactions de longue durée, effectuez l’une des opérations suivantes :
+ Utilisez la vue `pg_replication_slots`. Si la `restart_lsn` valeur n'est pas mise à jour, il est probable que PostgreSQL ne soit pas en mesure de publier Write Ahead Logs WALs () en raison de transactions actives de longue durée. Pour en savoir plus sur la vue `pg_replication_slots`, consultez [pg\$1replication\$1slots](https://www.postgresql.org/docs/15/view-pg-replication-slots.html) dans la [documentation de PostgreSQL 15.4.](https://www.postgresql.org/docs/15/)
+ Utilisez la requête suivante pour renvoyer la liste de toutes les requêtes actives dans la base de données, ainsi que les informations associées :
```
SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity WHERE query != ''
AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
```
Dans les résultats de la requête, le champ `age` indique la durée active de chaque requête, que vous pouvez utiliser pour identifier les requêtes de longue durée.
## Charge de travail élevée sur la source
Si la charge de travail de votre source PostgreSQL est élevée, vérifiez les points suivants pour réduire la latence :
+ Vous pouvez rencontrer une latence élevée lorsque vous utilisez le plug-in `test_decoding` lors de la migration d’un sous-ensemble de tables de la base de données source avec une valeur élevée de transactions par seconde (TPS). Cela est dû au fait que le plug-in `test_decoding` envoie toutes les modifications de base de données à l’instance de réplication, que DMS filtre ensuite en fonction du mappage de table de la tâche. Les événements relatifs aux tables qui ne font pas partie du mappage des tables de la tâche peuvent augmenter la latence source.
+ Vérifiez le débit TPS en utilisant l’une des méthodes suivantes.
+ Pour les sources Aurora PostgreSQL, utilisez la métrique. `CommitThroughput` CloudWatch
+ Pour PostgreSQL qui s’exécute sur Amazon RDS ou sur site, utilisez la requête suivante à l’aide d’un client PSQL version 11 ou ultérieure (appuyez sur **enter** pendant la requête pour faire avancer les résultats) :
```
SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset
select pg_sleep(60);
SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset
select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second";
```
+ Pour réduire la latence lors de l’utilisation du plug-in `test_decoding`, envisagez plutôt d’utiliser le plug-in `pglogical`. Contrairement au plug-in `test_decoding`, le plug-in `pglogical` filtre les modifications du journal d’écriture anticipée (WAL) à la source et envoie uniquement les modifications pertinentes à l’instance de réplication. Pour plus d'informations sur l'utilisation du `pglogical` plugin avec AWS DMS, consultez[Configuration du plug-in pglogical](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security.Pglogical).
## Débit réseau élevé
La réplication peut utiliser beaucoup de bande passante du réseau lorsque vous utilisez le plug-in `test_decoding`, en particulier lors de transactions à volume élevé. Cela est dû au fait que le plug-in `test_decoding` traite les modifications et les convertit dans un format lisible par l’homme qui est plus grand que le format binaire d’origine.
Pour améliorer les performances, pensez plutôt à utiliser le plug-in `pglogical`, qui est un plug-in binaire. Contrairement au plug-in `test_decoding`, le plug-in `pglogical` génère une sortie au format binaire, ce qui entraîne des modifications du flux WAL (Write Ahead Log) compressé.
## Déversez des fichiers dans Aurora PostgreSQL
Dans les versions 13 et supérieures de PostgreSQL, `logical_decoding_work_mem` le paramètre détermine l'allocation de mémoire pour le décodage et le streaming. [Pour plus d'informations sur le `logical_decoding_work_mem` paramètre, consultez la section [Consommation de ressources dans PostgreSQL dans](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM) la documentation de PostgreSQL 13.13.](https://www.postgresql.org/docs/13/)
La réplication logique accumule les modifications pour toutes les transactions en mémoire jusqu'à ce que ces transactions soient validées. Si la quantité de données stockée pour toutes les transactions dépasse la quantité spécifiée par le paramètre de base de données`logical_decoding_work_mem`, DMS déverse les données de transaction sur le disque afin de libérer de la mémoire pour les nouvelles données de décodage.
Les transactions de longue durée, ou de nombreuses sous-transactions, peuvent entraîner une consommation accrue de mémoire de décodage logique par le DMS. Cette augmentation de l'utilisation de la mémoire entraîne la création par DMS de fichiers indésirables sur le disque, ce qui entraîne une latence élevée de la source lors de la réplication.
Pour réduire l'impact d'une augmentation de la charge de travail source, procédez comme suit :
+ Réduisez les transactions de longue durée.
+ Réduisez le nombre de sous-transactions.
+ Évitez d'effectuer des opérations qui génèrent une grande quantité d'enregistrements de journal, telles que la suppression ou la mise à jour d'une table entière en une seule transaction. Effectuez plutôt des opérations par petits lots.
Vous pouvez utiliser les CloudWatch mesures suivantes pour surveiller la charge de travail sur la source :
+ `TransactionLogsDiskUsage`: le nombre d'octets actuellement occupés par le WAL logique. Cette valeur augmente de façon monotone si les emplacements de réplication logiques ne sont pas en mesure de suivre le rythme des nouvelles écritures ou si des transactions de longue durée empêchent le ramassage des anciens fichiers.
+ `ReplicationSlotDiskUsage`: quantité d'espace disque actuellement utilisée par les emplacements de réplication logique.
Vous pouvez réduire la latence de la source en ajustant le `logical_decoding_work_mem` paramètre. La valeur par défaut de ce paramètre est de 64 Mo. Ce paramètre limite la quantité de mémoire utilisée par chaque connexion de réplication en continu logique. Nous recommandons de définir `logical_decoding_work_mem` une valeur nettement supérieure à la `work_mem` valeur afin de réduire le nombre de modifications décodées que le DMS écrit sur le disque.
Nous vous recommandons de vérifier régulièrement la présence de fichiers déversés, en particulier pendant les périodes de forte activité de migration ou de latence. Si le DMS crée un nombre important de fichiers de déversement, cela signifie que le décodage logique ne fonctionne pas efficacement, ce qui peut augmenter le temps de latence. Pour atténuer ce problème, augmentez la valeur du `logical_decoding_work_mem` paramètre.
Vous pouvez vérifier le dépassement des transactions en cours à l'aide de la `aurora_stat_file` fonction. Pour plus d'informations, consultez la section [Ajustement de la mémoire de travail pour le décodage logique](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.html#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem) dans le manuel *Amazon Relational Database Service* Developer Guide.
# Résolution des problèmes liés aux points de terminaison SQL Server
Cette section contient des scénarios de réplication spécifiques à SQL Server. Pour déterminer les modifications à répliquer à partir de SQL Server, il AWS DMS lit les journaux de transactions et effectue des analyses périodiques sur la base de données source. La latence de réplication résulte généralement du fait que SQL Server limite ces analyses en raison de contraintes sur les ressources. Elle peut également résulter d’une augmentation significative du nombre d’événements écrits dans le journal des transactions en peu de temps.
**Topics**
+ [Reconstructions d’index](#CHAP_Troubleshooting_Latency_Source_SQLServer_Indexrebuilds)
+ [Transactions volumineuses](#CHAP_Troubleshooting_Latency_Source_SQLServer_Largetransactions)
+ [Intervalle d’interrogation MS-CDC mal configuré pour Amazon RDS SQL Server](#CHAP_Troubleshooting_Latency_Source_SQLServer_MisconfiguredCDC)
+ [Réplication de plusieurs tâches de CDC à partir de la même base de données source](#CHAP_Troubleshooting_Latency_Source_SQLServer_MultipleCDC)
+ [Traitement de sauvegarde du journal des transactions pour RDS pour SQL Server](#CHAP_Troubleshooting_Latency_Source_SQLServer_backup)
## Reconstructions d’index
Lorsque SQL Server reconstruit un index volumineux, il utilise une seule transaction. Cela génère de nombreux événements et peut utiliser une grande quantité d’espace de journalisation si SQL Server reconstruit plusieurs index à la fois. Quand cela se produit, vous pouvez vous attendre à de brefs pics de réplication. Si votre source SQL Server présente des pics de journalisation persistants, vérifiez les points suivants :
+ Vérifiez d'abord la durée des pics de latence à l'aide des `CDCLatencySource` CloudWatch métriques `CDCLatencySource` et, ou en consultant les messages de surveillance du débit dans les journaux des tâches. Pour plus d'informations sur CloudWatch les métriques pour AWS DMS, voir[Métriques de tâches de réplication](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task).
+ Vérifiez si la taille des journaux de transactions actifs ou des sauvegardes de journaux a augmenté au cours du pic de latence. Vérifiez également si une tâche de maintenance ou une reconstruction a été exécutée pendant cette période. Pour en savoir plus sur la vérification de la taille des journaux de transactions, consultez [Surveiller l’utilisation de l’espace pour le journal](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse) dans la [documentation technique de SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16).
+ Vérifiez que votre plan de maintenance respecte les bonnes pratiques relatives à SQL Server. Pour en savoir plus sur les bonnes pratiques de maintenance de SQL Server, consultez [Stratégie de maintenance d’index](https://learn.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes?view=sql-server-ver16#index-maintenance-strategy) dans la [documentation technique de SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16).
Pour résoudre les problèmes de latence lors des reconstructions d’index, essayez ce qui suit :
+ Utilisez le modèle de récupération `BULK_LOGGED` pour les reconstructions hors connexion afin de réduire le nombre d’événements qu’une tâche doit traiter.
+ Si possible, arrêtez la tâche pendant les reconstructions d’index. Vous pouvez également essayer de planifier des reconstructions d’index en dehors des heures de pointe pour atténuer l’impact d’un pic de latence.
+ Essayez d'identifier les goulots d'étranglement liés aux ressources qui ralentissent les lectures du DMS, tels que la latence du disque ou le I/O débit, et résolvez-les.
## Transactions volumineuses
Les transactions comportant un grand nombre d’événements, ou les transactions de longue durée, font grossir le journal des transactions.. Les lectures DMS prennent donc plus de temps, ce qui entraîne une latence. Cela est similaire à l’effet des reconstructions d’index sur les performances de réplication.
Vous pouvez avoir des difficultés à identifier ce problème si vous ne connaissez pas la charge de travail typique de la base de données source. Pour résoudre ce problème, procédez comme suit :
+ Tout d'abord, identifiez le temps pendant lequel le temps de latence a augmenté à l'aide `WriteThroughput` CloudWatch des métriques `ReadThroughput` et, ou en consultant les messages de surveillance du débit dans les journaux des tâches.
+ Vérifiez la présence ou non de requêtes de longue durée sur la base de données source pendant le pic de latence. Pour en savoir plus sur les requêtes de longue durée, consultez [Résoudre les problèmes de lenteur des requêtes dans SQL Server](https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/performance/troubleshoot-slow-running-queries) dans la [documentation technique de SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16).
+ Vérifiez si la taille des journaux de transactions actifs ou des sauvegardes de journaux a augmenté. Pour plus d’informations, consultez [Surveiller l’utilisation de l’espace pour le journal](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse) dans la [documentation technique de SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16).
Pour résoudre ce problème, effectuez l’une des actions suivantes :
+ La meilleure solution consiste à restructurer vos transactions côté application afin qu’elles se terminent rapidement.
+ Si vous ne pouvez pas restructurer vos transactions, une solution de contournement à court terme consiste à rechercher des goulots d’étranglement liés aux ressources, tels que des temps d’attente sur le disque ou des conflits de CPU. Si vous trouvez des goulots d’étranglement dans la base de données source, vous pouvez réduire la latence en augmentant les ressources de disque, de CPU et de mémoire pour la base de données source. Cela réduit les conflits pour les ressources système, ce qui permet aux requêtes DMS de se terminer plus rapidement.
## Intervalle d’interrogation MS-CDC mal configuré pour Amazon RDS SQL Server
Un paramètre d’intervalle d’interrogation mal configuré sur les instances Amazon RDS peut faire grossir le journal des transactions. Cela est dû au fait que la réplication empêche la troncation du journal. Bien que les tâches en cours d’exécution puissent continuer à se répliquer avec une latence minimale, l’arrêt et la reprise des tâches, ou le démarrage de tâches de CDC uniquement, peuvent entraîner l’échec des tâches. Cela est dû à des délais d’attente lors de l’analyse du journal des transactions volumineux.
Pour résoudre un intervalle d’interrogation mal configuré, procédez comme suit :
+ Vérifiez si la taille du journal des transactions actif augmente et si l’utilisation du journal est proche de 100 %. Pour plus d’informations, consultez [Surveiller l’utilisation de l’espace pour le journal](https://learn.microsoft.com/en-us/sql/relational-databases/logs/manage-the-size-of-the-transaction-log-file?view=sql-server-ver16#MonitorSpaceUse) dans la [documentation technique de SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16).
+ Vérifiez si la troncation du journal est retardée avec un paramètre `log_reuse_wait_desc value` égal à `REPLICATION`. Pour plus d’informations, consultez [Le journal des transactions (SQL Server)](https://learn.microsoft.com/en-us/sql/relational-databases/logs/the-transaction-log-sql-server?view=sql-server-ver16#FactorsThatDelayTruncation) dans la [documentation technique de SQL Server](https://learn.microsoft.com/en-us/sql/sql-server/?view=sql-server-ver16).
Si vous rencontrez des problèmes avec l’un des éléments de la liste précédente, ajustez l’intervalle d’interrogation MS-CDC. Pour en savoir plus sur l’ajustement de l’intervalle d’interrogation, consultez [Paramètres recommandés lors de l'utilisation de RDS pour SQL Server comme source pour AWS DMS](CHAP_Source.SQLServer.CDC.md#CHAP_Source.SQLServer.Configuration.Settings).
## Réplication de plusieurs tâches de CDC à partir de la même base de données source
Pendant la phase de chargement complet, nous recommandons de répartir les tables entre les tâches afin d’améliorer les performances, de séparer les tables dépendantes de manière logique et d’atténuer l’impact de l’échec d’une tâche. Toutefois, pendant la phase CDC, nous recommandons de consolider les tâches afin de minimiser les analyses DMS. Pendant la phase CDC, chaque tâche DMS analyse les journaux de transactions pour détecter de nouveaux événements plusieurs fois par minute. Comme chaque tâche s’exécute indépendamment, chaque tâche analyse chaque journal de transactions individuellement. Cela augmente l’utilisation de disque et de CPU sur la base de données SQL Server source. Par conséquent, l’exécution d’un grand nombre de tâches en parallèle peut entraîner une limitation des lectures DMS par SQL Server, ce qui augmente la latence.
Vous aurez peut-être du mal à identifier ce problème si plusieurs tâches démarrent progressivement. Le symptôme le plus courant de ce problème est que la plupart des analyses de tâches commencent à prendre plus de temps. Cela entraîne une latence plus élevée pour ces analyses. SQL Server donne la priorité à certaines analyses de tâches, de sorte que certaines tâches présentent une latence normale. Pour résoudre ce problème, vérifiez la métrique `CDCLatencySource` pour toutes vos tâches. Si `CDCLatencySource` augmente pour certaines tâches, alors que `CDCLatencySource` est faible pour d’autres, il est probable que SQL Server limite vos lectures DMS pour certaines de vos tâches.
Si SQL Server limite les lectures de vos tâches pendant la CDC, consolidez vos tâches afin de minimiser le nombre d’analyses DMS. Le nombre maximal de tâches pouvant se connecter à la base de données source sans créer de conflits dépend de facteurs tels que la capacité de la base de données source, le taux de croissance du journal des transactions ou le nombre de tables. Pour déterminer le nombre idéal de tâches pour votre scénario de réplication, testez la réplication dans un environnement de test similaire à votre environnement de production.
## Traitement de sauvegarde du journal des transactions pour RDS pour SQL Server
AWS DMS Les versions 3.5.3 et ultérieures prennent en charge la réplication à partir de RDS pour les sauvegardes de journaux SQL Server. La réplication des événements à partir des journaux de sauvegarde sur les instances RDS est plus lente que la réplication des événements à partir du journal des transactions actif. Cela est dû au fait que DMS demande l'accès aux sauvegardes en série pour garantir le maintien de la séquence des transactions et pour minimiser le risque de remplissage du stockage de l'instance Amazon RDS. De plus, du côté d'Amazon RDS, le temps nécessaire pour mettre les sauvegardes à la disposition de DMS varie en fonction de la taille de la sauvegarde du journal et de la charge sur l'instance RDS pour SQL Server.
En raison de ces contraintes, nous vous recommandons de définir l'ECA `ActivateSafeguard` sur`true`. Cela garantit que les transactions ne sont pas sauvegardées pendant que la tâche DMS lit le journal des transactions actif. Ce paramètre empêche également Amazon RDS d'archiver les transactions dans le journal actif lorsque DMS lit les transactions depuis la sauvegarde, éliminant ainsi la possibilité que DMS ne puisse pas rattraper le journal actif. Notez que cela peut entraîner une augmentation de la taille du journal actif pendant que la tâche est en train de rattraper son retard. Assurez-vous que votre instance dispose d'un espace de stockage suffisant pour éviter qu'elle ne manque d'espace.
Pour une tâche uniquement CDC répliquée à partir de sources RDS pour SQL Server, utilisez si possible la position de début CDC native par rapport à l'heure de début CDC native. Cela est dû au fait que DMS s'appuie sur les tables système pour identifier le point de départ de la position de départ native, plutôt que d'analyser les sauvegardes de journaux individuelles lorsque vous spécifiez une heure de début native.
# Résolution des problèmes de latence cible
Cette section contient des scénarios qui peuvent affecter la latence cible.
**Topics**
+ [Indexation des problèmes](#CHAP_Troubleshooting_Latency_Target_Indexing)
+ [Message SORTER dans le journal des tâches](#CHAP_Troubleshooting_Latency_Target_Sorter)
+ [Verrouillage de base de données](#CHAP_Troubleshooting_Latency_Target_Locking)
+ [Recherches d’objets LOB lentes](#CHAP_Troubleshooting_Latency_Target_LOB)
+ [Multi-AZ, journalisation des audits et sauvegardes](#CHAP_Troubleshooting_Latency_Target_MultiAZ)
## Indexation des problèmes
Pendant la phase CDC, AWS DMS réplique les modifications sur la source en exécutant des instructions DML (insert, update et delete) sur la cible. Pour les migrations hétérogènes à l’aide de DMS, des différences d’optimisation d’index sur la source et la cible peuvent entraîner un ralentissement des écritures sur la cible. Cela entraîne des problèmes de performances et de latence cible.
Pour résoudre des problèmes d’indexation, procédez comme suit. Les procédures relatives à ces étapes varient selon les moteurs de base de données.
+ Surveillez la durée d’interrogation pour la base de données cible. La comparaison de la durée d’exécution des requêtes sur la cible et sur la source peut indiquer les index qu’il convient d’optimiser.
+ Activez la journalisation pour les requêtes lentes.
Pour résoudre les problèmes d’indexation liés à des réplications de longue durée, procédez comme suit :
+ Ajustez les index de vos bases de données source et cible afin que la durée d’exécution des requêtes soit similaire sur la source et sur la cible.
+ Comparez les index secondaires utilisés dans les requêtes DML pour la source et la cible. Assurez-vous que les performances DML sur la cible soient comparables ou supérieures aux performances DML sur la source.
Notez que la procédure d’optimisation des index est spécifique à votre moteur de base de données. Il n’existe aucune fonctionnalité DMS permettant d’ajuster les index source et cible.
## Message SORTER dans le journal des tâches
Si un point de terminaison cible ne parvient pas à suivre le volume de modifications qui AWS DMS y sont écrites, la tâche met en cache les modifications sur l'instance de réplication. Si le cache croît et dépasse un seuil interne, la tâche arrête de lire les modifications provenant de la source. DMS procède ainsi pour éviter que l’instance de réplication ne soit à court de stockage ou que la tâche ne soit bloquée lors de la lecture d’un grand volume d’événements en attente.
Pour résoudre ce problème, consultez les CloudWatch journaux pour y trouver un message similaire à l'un des suivants :
```
[SORTER ]I: Reading from source is paused. Total disk usage exceeded the limit 90% (sorter_transaction.c:110)
[SORTER ]I: Reading from source is paused. Total storage used by swap files exceeded the limit 1048576000 bytes (sorter_transaction.c:110)
```
Si vos journaux contiennent un message similaire au premier message, désactivez tout enregistrement de suivi pour la tâche et augmentez le stockage des instances de réplication. Pour en savoir plus sur l’augmentation du stockage des instances de réplication, consultez [Modification d'une instance de réplication](CHAP_ReplicationInstance.Modifying.md).
Si vos journaux contiennent un message similaire au second message, procédez comme suit :
+ Déplacez les tables contenant de nombreuses transactions ou des opérations DML de longue durée vers une tâche distincte, si elles n’ont pas de dépendances sur les autres tables de la tâche.
+ Augmentez les paramètres `MemoryLimitTotal` et `MemoryKeepTime` pour conserver la transaction plus longtemps en mémoire. Cela n’aidera pas si la latence est maintenue, mais cela peut aider à maintenir une latence faible pendant de courtes périodes intensives de volume transactionnel. Pour en savoir plus sur ces paramètres de tâche, consultez [Paramètres de réglage du traitement des modifications](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md).
+ Évaluez si vous pouvez utiliser l’application par lots pour votre transaction en définissant `BatchApplyEnabled` sur `true`. Pour en savoir plus sur le paramètre `BatchApplyEnabled`, consultez [Paramètres de métadonnées des tâches cibles](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md).
## Verrouillage de base de données
Si une application accède à une base de données AWS DMS utilisée comme cible de réplication, elle peut verrouiller une table à laquelle DMS essaie d'accéder. Cela crée un conflit de verrouillage. Comme DMS écrit les modifications dans la base de données cible dans l’ordre où elles se sont produites dans la source, les retards d’écriture dans une table dus à des conflits de verrouillage créent des retards d’écriture dans toutes les tables.
Pour résoudre ce problème, interrogez la base de données cible pour vérifier si un conflit de verrouillage bloque les transactions d’écriture DMS. Si la base de données cible bloque les transactions d’écriture DMS, effectuez une ou plusieurs des opérations suivantes :
+ Restructurez vos requêtes pour valider les modifications plus fréquemment.
+ Modifiez vos paramètres de délai de verrouillage.
+ Partitionnez vos tables pour minimiser les conflits de verrouillage.
Notez que la procédure d’optimisation des conflits de verrouillage est spécifique à votre moteur de base de données. Il n’existe aucune fonctionnalité DMS permettant de régler les conflits de verrouillage.
## Recherches d’objets LOB lentes
Lors de AWS DMS la réplication d'une colonne d'objets volumineux (LOB), elle effectue une recherche sur la source juste avant d'écrire les modifications sur la cible. Cette recherche n’entraîne normalement aucune latence sur la cible, mais si la base de données source retarde la recherche en raison d’un verrouillage, la latence cible peut augmenter.
Ce problème est généralement difficile à diagnostiquer. Pour résoudre ce problème, activez le débogage détaillé sur les journaux de tâches et comparez les horodatages des appels de recherche d’objets LOB par DMS. Pour en savoir plus sur l’activation du débogage détaillé, consultez [Affichage et gestion des journaux AWS de tâches DMS](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs).
Pour résoudre ce problème, essayez les opérations suivantes :
+ Améliorez les performances des requêtes SELECT sur la base de données source.
+ Réglez les paramètres LOB dans DMS. Pour en savoir plus sur le réglage des paramètres LOB, consultez [Migration d'objets binaires de grande taille () LOBs](CHAP_BestPractices.md#CHAP_BestPractices.LOBS).
## Multi-AZ, journalisation des audits et sauvegardes
Pour les cibles Amazon RDS, la latence cible peut augmenter dans les cas suivants :
+ Sauvegardes
+ Après avoir activé plusieurs zones de disponibilité (multi-AZ)
+ Après avoir activé la journalisation de la base de données, telle que les journaux d’audit ou de requêtes lentes.
Ces problèmes sont généralement difficiles à diagnostiquer. Pour résoudre ces problèmes, surveillez la latence pour détecter les pics périodiques pendant les fenêtres de maintenance Amazon RDS ou pendant les périodes de fortes charges de base de données.
Pour résoudre ces problèmes, essayez les opérations suivantes :
+ Si possible, lors d’une migration à court terme, désactivez le mode multi-AZ, les sauvegardes ou la journalisation.
+ Replanifiez vos fenêtres de maintenance pour les périodes de faible activité.