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.

SQLDépannage des terminaux de serveur

Cette section contient des scénarios de réplication spécifiques au SQL serveur. Pour déterminer les modifications à répliquer depuis le SQL serveur, 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 le SQL serveur limite ces scans en raison de contraintes de 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.

Reconstructions d’index

Lorsque le SQL serveur 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 journal si le SQL serveur reconstruit plusieurs index à la fois. Quand cela se produit, vous pouvez vous attendre à de brefs pics de réplication. Si la source de votre SQL serveur a subi des pics de log, vérifiez les points suivants :

Pour résoudre les problèmes de latence lors des reconstructions d’index, essayez ce qui suit :

Transactions volumineuses

Les transactions comportant un grand nombre d’événements, ou les transactions de longue durée, font grossir le journal des transactions.. Cela DMS allonge les lectures, 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 :

Pour résoudre ce problème, effectuez l’une des actions suivantes :

Intervalle d'CDCinterrogation MS mal configuré pour Amazon Server RDS SQL

Un paramètre d'intervalle d'interrogation mal configuré sur les RDS instances Amazon peut entraîner une augmentation du 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 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 :

Si vous rencontrez des problèmes avec l'un des éléments de la liste précédente, réglez l'intervalle d'CDCinterrogation MS-. Pour en savoir plus sur l’ajustement de l’intervalle d’interrogation, consultez Paramètres recommandés lors de l'utilisation RDS de for SQL Server en tant que source pour AWS DMS.

Réplication de plusieurs CDC tâches à 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, au cours de cette CDC phase, nous recommandons de consolider les tâches afin de minimiser les DMS scans. Au cours de cette CDC phase, chaque DMS tâche 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 le disque et CPU l'utilisation de la base de données SQL du serveur source. Par conséquent, un grand nombre de tâches exécutées en parallèle peuvent entraîner le ralentissement des DMS lectures par le SQL serveur, 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. SQLLe serveur 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 certaines tâches ont une augmentationCDCLatencySource, tandis que d'autres ont un faibleCDCLatencySource, il est probable que le SQL serveur limite le nombre de vos DMS lectures pour certaines de vos tâches.

Si le SQL serveur limite les lectures de vos tâches pendant la durée de lectureCDC, consolidez vos tâches afin de minimiser le nombre de DMS scans. 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 for SQL Server

AWS DMS Les versions 3.5.3 et ultérieures prennent en charge la réplication depuis RDS pour les sauvegardes des journaux SQL du serveur. La réplication des événements à partir des journaux de sauvegarde sur les RDS instances est plus lente que celle des événements à partir du journal des transactions actif. Cela est dû au fait que les DMS demandes d'accès aux sauvegardes sont effectuées en série afin de garantir le maintien de la séquence des transactions et de minimiser le risque de saturation du stockage des RDS instances Amazon. De plus, du RDS côté d'Amazon, le temps nécessaire pour rendre les sauvegardes disponibles DMS varie en fonction de la taille de la sauvegarde du journal et de la charge sur l'instance SQL du serveur RDS for.

En raison de ces contraintes, nous vous recommandons de définir la valeur ECA ActivateSafeguard surtrue. Cela garantit que les transactions ne sont pas sauvegardées pendant que la DMS tâche lit le journal des transactions actif. Ce paramètre empêche également Amazon RDS d'archiver les transactions dans le journal actif lorsqu'DMSil lit les transactions depuis la sauvegarde, éliminant ainsi le risque de DMS ne pas pouvoir 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 CDC uniquement répliquée à partir de RDS sources SQL du serveur, utilisez si possible la position de CDC départ native par rapport à l'heure de CDC début native. Cela est dû au fait qu'il 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.