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 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 AWS DMS , lisez les journaux de transactions et exécutez 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.
Rubriques
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 :
Tout d'abord, vérifiez la durée des pics de latence à l'aide des
CDCLatencySourceCloudWatch métriquesCDCLatencySourceet, ou en consultant les messages de surveillance du débit dans les journaux des tâches. Pour plus d'informations sur CloudWatch les statistiques pour AWS DMS, consultezMétriques de tâches de réplication.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
dans la documentation technique de SQL Server . 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
dans la documentation technique de SQL Server .
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_LOGGEDpour 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 des ressources qui ralentissent les lectures du DMS, tels que la latence ou le I/O débit du disque, 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 la durée pendant laquelle la latence a augmenté à l'aide
WriteThroughputCloudWatch des métriquesReadThroughputet, 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
dans la documentation technique de SQL Server . 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
dans la documentation technique de SQL Server .
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' MS-CDC interrogation 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 un minimum de latence, l'arrêt et la reprise des tâches, ou le démarrage de CDC-only tâches, peuvent entraîner leur échec. 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
dans la documentation technique de SQL Server . 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)dans la documentation technique de SQL Server .
Si vous rencontrez des problèmes avec l'un des éléments de la liste précédente, réglez l'intervalle d' MS-CDC interrogation. 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.
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 depuis 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 de transactions actif. En effet, DMS demande l'accès aux sauvegardes en série pour s'assurer qu'il conserve la séquence des transactions et pour minimiser le risque de saturation de l'espace de 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 régler l'ECA ActivateSafeguard surtrue. 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 rattrape son retard. Assurez-vous que votre instance dispose de suffisamment d'espace de stockage pour éviter qu'elle ne manque d'espace.
Pour une CDC-only tâche de réplication à partir de sources RDS pour SQL Server, utilisez si possible la position de début du CDC native plutôt que l'heure de début du CDC native. En effet, DMS s'appuie sur des tables système pour identifier le point de départ de la position de départ native, au lieu d'analyser les sauvegardes de journaux individuelles lorsque vous spécifiez une heure de début native.
