Résolution des problèmes liés aux tâches de migration AWS Database Migration Service - AWS Service de Migration de Base de Données
Les tâches de migration s'exécutent lentementLa barre de statut des tâches ne bouge pasLa tâche est terminée mais rien n'a été migréDes clés étrangères et des index secondaires sont manquantsAWS DMSne crée pas de CloudWatch journauxDes problèmes se produisent lors de la connexion à Amazon RDSDes problèmes de réseau surviennentLa capture des données modifiées est bloquée après le chargement completErreurs de violation de clé primaire lors du redémarrage d'une tâcheÉchec du chargement initial d'un schémaÉchec des tâches avec une erreur inconnueLe redémarrage d'une tâche charge les tables dès le débutLe nombre de tables par tâche pose problèmeLes tâches échouent quand une clé primaire est créée sur une colonne LOBDes doublons d'enregistrements apparaissent sur une table cible sans clé primaireÉchec des points de terminaison sources dans la plage IP réservéeLes horodatages sont brouillés dans les requêtes Amazon AthenaRésolution de problèmes avec OracleRésolution des problèmes liés à MySQLRésolution des problèmes liés à PostgreSQLRésolution des problèmes liés à Microsoft SQL ServerRésolution des problèmes liés à Amazon RedshiftRésolution des problèmes liés à Amazon Aurora MySQL Résolution des problèmes liés à SAP ASERésolution des problèmes liés à IBM Db2

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 tâches de migration AWS Database Migration Service

Vous trouverez ci-dessous des rubriques relatives à la résolution des problèmes liés à AWS Database Migration Service (AWS DMS). Ces rubriques peuvent vous aider à résoudre les problèmes courants en utilisant à la fois AWS DMS et les bases de données de point de terminaison sélectionnées.

Si vous avez ouvert un dossier AWS Support, votre ingénieur support peut éventuellement identifier un problème potentiel lié à l'une de vos configurations de la base de données des points de terminaison. Votre ingénieur peut également vous demander d'exécuter un script d'assistance pour renvoyer des informations de diagnostic concernant la base de données. Pour plus de détails sur le téléchargement, l'exécution et le chargement des informations de diagnostic à partir de ce type de script d'assistance, consultez Utilisation de scripts d'assistance au diagnostic dans AWS DMS.

À des fins de résolution des problèmes, AWS DMS collecte les fichiers de trace et de vidage dans l'instance de réplication. Vous pouvez fournir ces fichiers au AWS Support en cas de problème nécessitant un dépannage. Par défaut, DMS purge les fichiers de trace et de vidage datant de plus de trente jours. Pour désactiver la collecte de fichiers de trace et de vidage, ouvrez un dossier auprès du AWS Support.

Rubriques

Les tâches de migration s'exécutent lentement

Plusieurs problèmes peuvent entraîner la lenteur d'exécution d'une tâche de migration, ou pour les tâches suivantes, une lenteur d'exécution supérieure à celle de la tâche initiale.

La raison la plus courante de la lenteur d'exécution d'une tâche de migration est le fait que des ressources inappropriées soient allouées à l'instance de réplication AWS DMS. Pour vous assurer que votre instance dispose de suffisamment de ressources pour les tâches que vous exécutez, vérifiez l'utilisation que fait votre instance de réplication du CPU, de la mémoire, des fichiers d'échange et des IOPS. Par exemple, plusieurs tâches avec Amazon Redshift comme point de terminaison utilisent un volume important d'E/S. Vous pouvez augmenter le nombre d'E/S par seconde pour votre instance de réplication ou fractionner vos tâches sur plusieurs instances de réplication pour une migration plus efficace.

Pour plus d'informations sur la détermination de la taille de votre instance de réplication, consultez Sélection de la meilleure taille pour une instance de réplication.

Vous pouvez augmenter la vitesse d'une charge de migration initiale en procédant comme suit :

  • Si votre cible est une instance de base de données Amazon RDS, vérifiez que l'option Multi-AZ n'est pas activée pour l'instance de base de données cible.

  • Désactivez les sauvegardes ou la journalisation automatiques sur la base de données cible au cours du chargement et réactivez ces fonctionnalités une fois la migration terminée.

  • Si cette fonctionnalité est disponible sur votre cible, utilisez les IOPS provisionnés.

  • Si vos données de migration contiennent des LOB, vérifiez que la tâche est optimisée pour la migration d'objets LOB. Pour plus d'informations sur l'optimisation pour les objets LOB, consultez Paramètres de métadonnées des tâches cibles.

La barre de statut des tâches ne bouge pas

La barre d’état des tâches donne une estimation de la progression de la tâche. La qualité de cette estimation dépend de la qualité des statistiques de table de la base de données source ; meilleures sont les statistiques de table, plus précise sera l'estimation.

Pour une tâche avec une seule table ne disposant pas de statistiques de lignes estimées, AWS DMS ne peut pas fournir une estimation complète de pourcentage. Dans ce cas, utilisez l'état de la tâche et l'indication des lignes chargées pour confirmer que la tâche est bien en cours d'exécution et de progression.

La tâche est terminée mais rien n'a été migré

Procédez comme suit si rien n'a été migré une fois votre tâche terminée.

Des clés étrangères et des index secondaires sont manquants

AWS DMS crée des tables, des clés primaires et, dans certains cas, des index uniques, mais il ne crée pas d'autres objets qui ne sont pas requis pour migrer efficacement les données de la source. Par exemple, il ne crée pas d'index secondaires, de contraintes de clés non primaires ou de valeurs de données par défaut.

Pour migrer des objets secondaires à partir de votre base de données, utilisez les outils natifs de la base de données si vous effectuez une migration vers le même moteur de base de données que votre base de données source. Utilisez l'AWS Schema Conversion Tool (AWS SCT) si vous effectuez une migration vers un moteur de base de données autre que celui utilisé par la base de données source pour migrer des objets secondaires.

AWS DMSne crée pas de CloudWatch journaux

Si votre tâche de réplication ne crée pas de CloudWatch journaux, assurez-vous que votre compte possède le dms-cloudwatch-logs-role rôle. Si ce rôle n'est pas présent, procédez comme suit pour le créer :

  1. Connectez-vous à l’AWS Management Console et ouvrez la console IAM à l’adresse https://console.aws.amazon.com/iam/.

  2. Choisissez l'onglet Rôles. Sélectionnez Créer un rôle.

  3. Dans la section Sélectionner le type d'entité de confiance, choisissez Service AWS.

  4. Dans la section Choisir un cas d'utilisation, choisissez DMS.

  5. Sélectionnez Next: Permissions (Étape suivante : autorisations).

  6. Entrez AmazonDMSCloudWatchLogsRole dans le champ de recherche et cochez la case à côté d'AmazonDMS. CloudWatchLogsRole Cela donne AWS DMS des autorisations d'accès CloudWatch.

  7. Choisissez Suivant : Balises.

  8. Choisissez Suivant : Vérification.

  9. Entrez dms-cloudwatch-logs-role pour Nom du rôle. Ce nom est sensible à la casse.

  10. Sélectionnez Créer un rôle.

Des problèmes se produisent lors de la connexion à Amazon RDS

Il peut y avoir plusieurs raisons pour lesquelles vous ne pouvez pas vous connecter à une instance de base de données Amazon RDS que vous définissez en tant que source ou cible. Voici quelques points à vérifier :

  • Vérifiez que la combinaison du nom d'utilisateur et du mot de passe est correcte.

  • Vérifiez que la valeur de point de terminaison affichée dans la console Amazon RDS pour l'instance est identique à l'identifiant de point de terminaison que vous avez utilisé pour créer le point de terminaison AWS DMS.

  • Vérifiez que la valeur de port affichée dans la console Amazon RDS pour l'instance est la même que le port affecté au point de terminaison AWS DMS.

  • Vérifiez que le groupe de sécurité assigné à l'instance de base de données Amazon RDS permet des connexions à partir de l'instance de réplication AWS DMS.

  • Si l'instance de réplication AWS DMS et l'instance de base de données Amazon RDS ne se trouvent pas dans le même cloud privé virtuel (VPC), vérifiez que l'instance de base de données est accessible publiquement.

Message d'erreur : Incorrect thread connection string: incorrect thread value 0

Cette erreur peut souvent se produire lorsque vous testez la connexion vers un point de terminaison. Cette erreur indique la présence d'une erreur dans la chaîne de connexion. Un espace situé après l'adresse IP de l'hôte en est un exemple. Un caractère incorrect copié dans la chaîne de connexion est un autre exemple.

Des problèmes de réseau surviennent

Les problèmes de mise en réseau les plus répandus portent sur le groupe de sécurité VPC utilisé par l'instance de réplication AWS DMS. Par défaut, ce groupe de sécurité possède des règles qui autorisent le trafic sortant à 0.0.0.0/0 sur tous les ports. Dans de nombreux cas, vous modifiez ce groupe de sécurité ou vous utilisez votre propre groupe de sécurité. Si tel est le cas, assurez-vous au moins que les points de terminaison sources et cibles disposent d'une sortie sur leurs ports de base de données respectifs.

Les autres problèmes liés à la configuration peuvent inclure les suivants :

  • L'instance de réplication et les points de terminaison sources et cibles se trouvent dans le même VPC : le groupe de sécurité utilisé par les points de terminaison doit autoriser le trafic entrant sur le port de base de données à partir de l'instance de réplication. Veillez à ce que le groupe de sécurité utilisé par l'instance de réplication ait accès aux points de terminaison. Vous pouvez également créer une règle dans le groupe de sécurité utilisé par les points de terminaison qui autorise l'accès à l'adresse IP privée de l'instance de réplication.

  • Le point de terminaison source se trouve en dehors du VPC utilisé par l'instance de réplication (avec une passerelle Internet) : le groupe de sécurité du VPC doit inclure des règles de routage qui envoient le trafic non destiné au VPC vers la passerelle Internet. Dans cette configuration, la connexion au point de terminaison semble provenir de l'adresse IP publique sur l'instance de réplication.

  • Le point de terminaison source est en dehors du VPC utilisé par l'instance de réplication (avec une passerelle NAT) : vous pouvez configurer une passerelle de traduction d'adresses réseau (NAT) en utilisant une adresse IP Elastic unique liée à une interface réseau Elastic unique. Cette passerelle NAT reçoit un identifiant NAT (nat-#####).

    Dans certains cas, le VPC inclut une route par défaut vers cette passerelle NAT au lieu de la passerelle Internet. Dans de tels cas, l'instance de réplication semble plutôt contacter le point de terminaison de base de données en utilisant l'adresse IP publique de la passerelle NAT. Ici, le trafic entrant vers le point de terminaison de base de données en dehors du VPC doit autoriser le trafic entrant à partir de l'adresse NAT au lieu de l'adresse IP publique de l'instance de réplication.

Pour en savoir plus sur l'utilisation de votre propre serveur de noms sur site, consultez Utilisation de votre propre serveur de noms sur site.

La capture des données modifiées est bloquée après le chargement complet

Il se peut que les modifications de réplication soient lentes ou bloquées après une migration de chargement complet si plusieurs paramètres AWS DMS sont conflit les uns avec les autres.

Supposons, par exemple, que le paramètre Mode de préparation des tables cible soit défini sur Ne rien faire ou Tronquer. Dans ce cas, vous avez demandé à AWS DMS de ne pas effectuer de configuration sur les tables cibles, notamment de créer des index principaux et uniques. Si vous n'avez pas créé de clés primaires ou uniques sur les tables cibles, AWS DMS effectue une analyse complète de table pour chaque mise à jour. Cette approche peut avoir un impact considérable sur les performances.

Erreurs de violation de clé primaire lors du redémarrage d'une tâche

Cette erreur peut se produire lorsque des données restent dans la base de données cible depuis une tâche de migration précédente. Si l'option Mode de préparation des tables cible est définie sur Ne rien faire, AWS DMS ne réalise aucun préparation sur la table cible, y compris le nettoyage des données insérées à partir d'une tâche précédente.

Pour redémarrer votre tâche et éviter ces erreurs, supprimez les lignes insérées dans les tables cibles à partir de l'exécution précédente de la tâche.

Échec du chargement initial d'un schéma

Dans certains cas, le chargement initial de vos schémas peut échouer avec une erreur Operation:getSchemaListDetails:errType=, status=0, errMessage=, errDetails=.

Dans de tels cas, le compte d'utilisateur utilisé par AWS DMS pour se connecter au point de terminaison source ne dispose pas des autorisations nécessaires.

Échec des tâches avec une erreur inconnue

La cause des types d'erreur inconnus peut être variée. Toutefois, nous constatons souvent que le problème implique des ressources insuffisantes allouées à l'instance de réplication AWS DMS.

Pour garantir que votre instance dispose de suffisamment de ressources pour effectuer la migration, vérifiez l'utilisation que fait votre instance du CPU, de la mémoire, des fichiers d'échange et des IOPS. Pour plus d'informations concernant la supervision, consultez la page Métriques AWS Database Migration Service

Le redémarrage d'une tâche charge les tables dès le début

AWS DMS redémarre le chargement de table au début lorsque le chargement initial d'une table ne s'est pas terminé. Lorsqu'une tâche est redémarrée, AWS DMS recharge les tables depuis le début lorsque le chargement initial ne s'est pas terminé.

Le nombre de tables par tâche pose problème

Aucune limite ne s'applique au nombre de tables par tâche de réplication. Toutefois, en règle générale, nous recommandons de limiter le nombre de tables d'une tâche à moins de 60 000. L'utilisation des ressources peut souvent être un goulot d'étranglement lorsqu'une tâche unique utilise plus de 60 000 tables.

Les tâches échouent quand une clé primaire est créée sur une colonne LOB

En mode LOB COMPLET ou LOB LIMITÉ, AWS DMS ne prend pas en charge la réplication des clés primaires qui sont des types de données LOB.

DMS effectue initialement la migration d'une ligne avec une colonne LOB comme null, puis met à jour ultérieurement la colonne LOB. Ainsi, lorsque la clé primaire est créée sur une colonne LOB, l'insertion initiale échoue car la clé primaire ne peut pas être null. Comme solution de contournement, ajoutez une autre colonne en tant que clé primaire et supprimez la clé primaire de la colonne LOB.

Des doublons d'enregistrements apparaissent sur une table cible sans clé primaire

L'exécution d'une tâche de chargement complet + CDC peut créer des enregistrements en double sur les tables cibles sans clé primaire ni index unique. Pour éviter de dupliquer les enregistrements sur les tables cibles pendant les tâches de chargement complet et de CDC, assurez-vous que les tables cibles ont une clé primaire ou un index unique.

Échec des points de terminaison sources dans la plage IP réservée

Si une base de données source AWS DMS utilise une adresse IP comprise dans la plage IP réservée 192.168.0.0/24, le test de connexion des points de terminaison sources échoue. Les étapes suivantes fournissent une solution de contournement possible :

  1. Recherchez une instance Amazon EC2 qui ne figure pas dans la plage réservée et qui peut communiquer avec la base de données source dans 192.168.0.0/24.

  2. Installez un proxy socat et exécutez-le. Vous en trouverez un exemple ci-dessous.

    yum install socat
                
socat -d -d -lmlocal2 tcp4-listen:database port,bind=0.0.0.0,reuseaddr,fork tcp4:source_database_ip_address:database_port
&

Utilisez l'adresse IP de l'instance Amazon EC2 et le port de base de données indiqué ci-dessus pour le point de terminaison AWS DMS. Assurez-vous que le point de terminaison dispose du groupe de sécurité qui permet à AWS DMS d'accéder au port de base de données. Notez que le proxy doit être actif pendant toute la durée d'exécution de votre tâche DMS. Selon le cas d'utilisation, vous devrez peut-être automatiser la configuration du proxy.

Les horodatages sont brouillés dans les requêtes Amazon Athena

Si les horodatages sont déformés dans les requêtes Athena, utilisez l'ModifyEndpointaction AWS Management Console ou pour définir la valeur de parquetTimestampInMillisecond votre point de terminaison Amazon S3 sur. true Pour plus d'informations, consultez S3Settings.

Résolution de problèmes avec Oracle

Vous allez en apprendre davantage sur la résolution des problèmes spécifiques à l'utilisation d'AWS DMS avec des bases de données Oracle.

Extraire les données à partir de vues

Vous pouvez extraire une fois les données d'une vue ; vous ne pouvez pas les utiliser pour la réplication continue. Pour pouvoir extraire des données à partir de vues, vous devez ajouter le code suivant à la section Paramètres du point de terminaison de la page du point de terminaison source Oracle. Lorsque vous extrayez les données d'une vue, la vue est représentée sous la forme d'une table sur le schéma cible.

"ExposeViews": true

Migration des LOB à partir d'Oracle 12c

AWS DMSpeut utiliser deux méthodes pour capturer les modifications apportées à une base de données Oracle, Binary Reader et Oracle LogMiner. Par défaut, AWS DMS utilise Oracle LogMiner pour capturer les modifications. Toutefois, sur Oracle 12c, Oracle LogMiner ne prend pas en charge les colonnes LOB. Pour capturer les modifications apportées aux colonnes LOB dans Oracle 12c, utilisez Binary Reader.

Basculer entre Oracle LogMiner et Binary Reader

AWS DMSpeut utiliser deux méthodes pour capturer les modifications apportées à une base de données Oracle source, Binary Reader et Oracle LogMiner. Oracle LogMiner est la valeur par défaut. Pour utiliser Binary Reader pour capturer les modifications, procédez comme suit :

Pour utiliser Binary Reader pour capturer des modifications

  1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/dms/v2/.

  2. Choisissez Endpoints (Points de terminaison).

  3. Choisissez le point de terminaison source Oracle que vous souhaitez utiliser avec Binary Reader.

  4. Sélectionnez Modifier.

  5. Choisissez Avancé, puis ajoutez le code suivant pour Attributs de connexion supplémentaires.

    
useLogminerReader=N

  6. Utilisez un outil de développement Oracle tel que SQL-Plus pour accorder le privilège supplémentaire suivant au compte d'utilisateur AWS DMS utilisé pour vous connecter au point de terminaison Oracle.

    
SELECT ON V_$TRANSPORTABLE_PLATFORM

Erreur : CDC Oracle arrêtée 122301 nombre maximal de nouvelles tentatives de CDC Oracle dépassé.

Cette erreur se produit lorsque les journaux d'archive Oracle nécessaires ont été supprimés de votre serveur avant qu'AWS DMS ait pu les utiliser pour capturer les modifications. Augmentez vos stratégies de conservation des journaux sur votre serveur de base de données. Pour une base de données Amazon RDS, exécutez la procédure suivante pour augmenter la durée de conservation des journaux. Par exemple, le code suivant augmente la durée de conservation des journaux sur une instance DB Amazon RDS à 24 heures.


exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);

Ajout automatique d'une journalisation supplémentaire à un point de terminaison source Oracle

Par défaut, la journalisation supplémentaire d'AWS DMS est désactivée. Pour activer automatiquement la journalisation supplémentaire pour un point de terminaison source Oracle, procédez comme suit.

Pour ajouter la journalisation supplémentaire à un point de terminaison source Oracle

  1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/dms/v2/.

  2. Choisissez Endpoints (Points de terminaison).

  3. Choisissez le point de terminaison source Oracle auquel vous souhaitez ajouter la journalisation supplémentaire.

  4. Sélectionnez Modifier.

  5. Choisissez Avancé, puis ajoutez le code suivant dans la zone de texte Attributs de connexion supplémentaires :

    
addSupplementalLogging=Y

  6. Sélectionnez Modifier.

Les modifications de LOB ne sont pas capturées

Actuellement, une table doit avoir une clé primaire pour qu'AWS DMS puisse capturer les modifications LOB. Si une table qui contient des données de type LOB ne possède pas de clé primaire, vous pouvez réaliser plusieurs actions pour capturer les modifications LOB :

  • Ajouter une clé primaire à la table. Il peut suffire d'ajouter une colonne ID et de la renseigner avec une séquence à l'aide d'un déclencheur.

  • Créez une vue matérialisée de la table qui inclut un ID généré par le système en tant que clé primaire et migrez la vue matérialisée plutôt que la table.

  • Créer une copie de secours logique, ajouter une clé primaire à la table et effectuer la migration à partir de la copie de secours logique.

Erreur : ORA-12899 : valeur trop grande pour la colonne nom de la colonne

L'erreur « ORA-12899 : valeur trop grande pour la colonne column-name » est souvent causée par quelques problèmes.

L'un de ces problèmes est dû à une incompatibilité entre les jeux de caractères utilisés par les bases de données source et cible.

Dans un autre de ces problèmes, les paramètres NLS (National Language Support) diffèrent entre les deux bases de données. Cette erreur survient souvent lorsque le paramètre NLS_LENGTH_SEMANTICS de base de données source est défini à la valeur CHAR et que le paramètre NLS_LENGTH_SEMANTICS de la base de données cible est défini à la valeur BYTE.

Mauvaise interprétation du type de données NUMBER

Le type de données Oracle NUMBER est converti en divers types de données AWS DMS, selon la précision et l'échelle de NUMBER. Ces conversions sont documentées ici Types de données sources pour Oracle. La façon dont le type NUMBER est converti peut également être affectée par l'utilisation de paramètres de point de terminaison pour le point de terminaison Oracle source. Ces paramètres de point de terminaison sont documentés dans Paramètres du point de terminaison lors de l'utilisation d'Oracle comme source pour AWS DMS.

Enregistrements manquants pendant le chargement complet

Lors d'un chargement complet, AWS DMS recherche les transactions ouvertes au niveau de la base de données et attend que la transaction soit validée. Par exemple, en fonction du paramètre de tâche TransactionConsistencyTimeout=600, AWS DMS attend 10 minutes même si la transaction ouverte porte sur une table non incluse dans le mappage de tables. Mais si la transaction ouverte porte sur une table incluse dans le mappage de tables et que la transaction n'est pas validée à temps, il en résulte des enregistrements manquants dans la table cible.

Vous pouvez modifier le paramètre de tâche TransactionConsistencyTimeout et augmenter le temps d'attente si vous savez que la validation des transactions ouvertes prendra plus de temps.

Notez également que la valeur par défaut du paramètre de tâche FailOnTransactionConsistencyBreached est false. Cela signifie qu'AWS DMS continue d'appliquer d'autres transactions mais que des transactions ouvertes sont manquées. Si vous souhaitez que la tâche échoue quand des transactions ouvertes ne sont pas fermées à temps, vous pouvez définir FailOnTransactionConsistencyBreached sur true.

Erreur de table

Table Error apparaît dans les statistiques de table lors de la réplication si une clause WHERE ne fait pas référence à une colonne de clé primaire et qu'une journalisation supplémentaire n'est pas utilisée pour toutes les colonnes.

Pour résoudre ce problème, activez la journalisation supplémentaire pour toutes les colonnes de la table référencée. Pour plus d’informations, consultez Configurez une journalisation supplémentaire.

Erreur : impossible de récupérer les identifiants de destination des journaux Redo archivés par Oracle

Cette erreur se produit quand aucun journal d'archive n'est généré pour votre source Oracle ou que V$ARCHIVED_LOG est vide. Vous pouvez résoudre cette erreur en échangeant les journaux manuellement.

Pour une base de données Amazon RDS, exécutez la procédure suivante pour échanger les fichiers journaux. La procédure switch_logfile ne comporte aucun paramètre.

exec rdsadmin.rdsadmin_util.switch_logfile;

Pour une base de données source Oracle autogérée, utilisez la commande suivante pour forcer un échange de journaux.

ALTER SYSTEM SWITCH LOGFILE ;

Évaluation des performances de lecture des journaux redo ou d'archivage Oracle

Si vous rencontrez des problèmes de performances avec votre source Oracle, vous pouvez évaluer les performances de lecture de vos journaux redo ou d'archivage Oracle afin de trouver des moyens d'améliorer les performances. Pour tester les performances de lecture des journaux redo ou d'archivage, utilisez l'Amazon Machine Image (AMI) de diagnostic AWS DMS.

Vous pouvez utiliser l'AMI de diagnostic AWS DMS pour effectuer les opérations suivantes :

  • Utiliser la méthode bFile pour évaluer les performances des fichiers journaux redo.

  • Utilisez LogMiner cette méthode pour évaluer les performances du fichier de journalisation.

  • Utiliser la méthode PL/SQL (dbms_lob.read) pour évaluer les performances des fichiers journaux redo.

  • Utiliser une exécution monothread pour évaluer les performances de lecture sur un fichier ASM.

  • Utiliser une exécution multithread pour évaluer les performances de lecture sur un fichier ASM.

  • Utiliser la fonction directe Windows Readfile() ou Linux Pread64 pour évaluer le fichier journal redo.

Vous pouvez ensuite prendre des mesures correctives en fonction des résultats.

Pour tester les performances de lecture sur un fichier journal redo ou d'archivage Oracle

  1. Créez une instance Amazon EC2 d'AMI de diagnostic AWS DMS et connectez-vous à celle-ci.

    Pour plus d'informations, consultez Utilisation de l'AMI de diagnostic AWS DMS.

  2. Exécutez la commande awsreplperf.

    $ awsreplperf

    Cette commande affiche les options de l'utilitaire de performances de lecture Oracle d'AWS DMS.

    0.	Quit
1.	Read using Bfile
2.	Read using LogMiner
3.	Read file PL/SQL (dms_lob.read)
4.	Read ASMFile Single Thread
5.	Read ASMFile Multi Thread
6.	Readfile() function

  3. Sélectionnez une option dans la liste.

  4. Entrez les informations de journal d'archivage et de connexion de base de données suivantes.

    Oracle user name [system]:
Oracle password:

Oracle connection name [orcllx]:
Connection format hostname:port/instance

Oracle event trace? [N]: 
Default N = No or Y = Yes

Path to redo or archive log file []:

  5. Examinez la sortie affichée pour obtenir des informations pertinentes sur les performances de lecture. Par exemple, ce qui suit montre le résultat qui peut résulter de la sélection de l'option numéro 2, Lire en utilisant LogMiner.

    Sortie de l'utilitaire de performances de lecture

  6. Pour quitter l'utilitaire, entrez 0 (zéro).

Étapes suivantes

  • Lorsque les résultats indiquent que la vitesse de lecture est inférieure à un seuil acceptable, exécutez le script d'assistance au diagnostic Oracle sur le point de terminaison et passez en revue les sections Temps d'attente, Charger le profil et Profil d'E/S. Ajustez ensuite toute configuration anormale susceptible d'améliorer les performances de lecture. Par exemple, si vos fichiers journaux redo ont une capacité maximale de 2 Go, essayez d'augmenter LOG_BUFFER à 200 Mo pour améliorer les performances.

  • Passez en revue les bonnes pratiques AWS DMS pour vous assurer que votre instance, votre tâche et vos points de terminaison de réplication DMS sont configurés de manière optimale.

Résolution des problèmes liés à MySQL

Vous allez en apprendre davantage sur la résolution des problèmes spécifiques à l'utilisation d'AWS DMS avec des bases de données MySQL.

Échec de la tâche CDC pour le point de terminaison d'instance DB Amazon RDS car la journalisation binaire est désactivée

Ce problème se produit avec les instances de base de données Amazon RDS car les sauvegardes automatiques sont désactivées. Activez les sauvegardes automatiques en définissant la période de conservation des sauvegardes avec une valeur différente de zéro.

Les connexions à une instance MySQL cible sont déconnectées durant une tâche

Si une tâche contenant des objets LOB est déconnectée d'une cible MySQL, le journal des tâches peut présenter le type d'erreurs suivant. 

[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: 08S01 NativeError: 
2013 Message: [MySQL][ODBC 5.3(w) Driver][mysqld-5.7.16-log]Lost connection 
to MySQL server during query [122502] ODBC general error.
 [TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
2006 Message: [MySQL][ODBC 5.3(w) Driver]MySQL server has gone away 
[122502] ODBC general error.

Dans ce cas, il se peut que vous deviez ajuster certains paramètres de tâche.

Pour résoudre le problème de déconnexion d'une tâche à une cible MySQL, procédez comme suit :

  • Vérifiez que vos variables de base de données max_allowed_packet sont assez grandes pour contenir la plus grande taille de LOB.

  • Vérifiez que les variables suivantes sont définies pour présenter une valeur de délai d'expiration élevée. Nous vous recommandons d'utiliser une valeur d'au moins 5 minutes pour chacune de ces variables.

    • net_read_timeout

    • net_write_timeout

    • wait_timeout

Pour plus d'informations sur la définition des variables système MySQL, consultez Variables système du serveur (langue française non garantie) dans la documentation MySQL.

Ajout de la validation automatique à un point de terminaison compatible MySQL

Pour ajouter la validation automatique à un point de terminaison cible compatible MySQL

  1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/dms/v2/.

  2. Choisissez Endpoints (Points de terminaison).

  3. Choisissez le point de terminaison cible compatible MySQL auquel vous souhaitez ajouter la validation automatique.

  4. Sélectionnez Modifier.

  5. Choisissez Avancé, puis ajoutez le code suivant dans la zone de texte Attributs de connexion supplémentaires :

    
Initstmt= SET AUTOCOMMIT=1

  6. Sélectionnez Modifier.

Désactiver les clés étrangères sur un point de terminaison cible compatible MySQL

Vous pouvez désactiver les contrôles de clé étrangère sur MySQL en ajoutant les éléments suivants dans Attributs de connexion supplémentaires, dans la section Avancé du point de terminaison cible MySQL, Amazon Aurora MySQL-Compatible Edition ou MariaDB.

Pour désactiver les clés étrangères sur un point de terminaison cible compatible MySQL

  1. Connectez-vous à la AWS DMS console AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/dms/v2/.

  2. Choisissez Endpoints (Points de terminaison).

  3. Choisissez le point de terminaison cible MySQL, Aurora MySQL ou MariaDB pour lequel vous voulez désactiver les clés étrangères.

  4. Sélectionnez Modifier.

  5. Choisissez Avancé, puis ajoutez le code suivant dans la zone de texte Attributs de connexion supplémentaires :

    
Initstmt=SET FOREIGN_KEY_CHECKS=0

  6. Sélectionnez Modifier.

Caractères remplacés par un point d'interrogation

Ce problème se produit suivant lorsque les caractères de point de terminaison source ont été codés par un jeu de caractères non pris en charge par AWS DMS.

Entrées de journal « Événement incorrect »

Les entrées « Événement incorrect » dans les journaux de migration indiquent généralement qu'une opération de langage de manipulation de données (DDL) non prise en charge a été tentée sur le point de terminaison de la base de données source. Les opérations DDL non prises en charge déclenchent un événement que l'instance de réplication ne peut pas ignorer, si bien qu'un événement incorrect est journalisé.

Pour résoudre ce problème, redémarrez la tâche depuis le début. Cela recharge les tables et lance la capture des modifications une fois que l'opération DDL non prise en charge a été émise.

Capture de données modifiées avec MySQL 5.5

La capture des données de modification (CDC) AWS DMS pour les bases de données compatibles Amazon RDS MySQL nécessite la journalisation binaire basée sur les lignes de l'image complète, qui n'est pas prise en charge dans MySQL versions 5.5 et antérieures. Pour pouvoir utiliser la CDC AWS DMS, vous devez mettre à niveau votre instance de base de données Amazon RDS à MySQL version 5.6.

Augmentation de la durée de conservation des journaux binaires pour les instances de base de données Amazon RDS

AWS DMS nécessite la conservation des fichiers journaux binaires pour la capture de données modifiées. Pour augmenter la durée de conservation des journaux sur une instance DB Amazon RDS, utilisez la procédure suivante. L'exemple suivant permet d'augmenter la durée de conservation des journaux binaires à 24 heures. 


call mysql.rds_set_configuration('binlog retention hours', 24);

Message du journal : quelques modifications de la base de données source n'ont eu aucun impact lorsqu'elles ont été appliquées à la base de données cible.

Lorsque AWS DMS met à jour la valeur d'une colonne de base de données MySQL à sa valeur existante, un message zero rows affectedest renvoyé à partir de MySQL. Ce comportement est différent des autres moteurs de base de données tels qu'Oracle et SQL Server. Ces moteurs mettent à jour une ligne, même si la valeur de remplacement est identique à la valeur actuelle.

Erreur : Identificateur trop long

L'erreur suivante se produit lorsqu'un identificateur est trop long :


TARGET_LOAD E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
1059 Message: MySQLhttp://ODBC 5.3(w) Driverhttp://mysqld-5.6.10Identifier 
name 'name' is too long 122502 ODBC general error. (ar_odbc_stmt.c:4054)

Dans certains cas, vous configurez AWS DMS pour créer les tables et les clés primaires dans la base de données cible. Dans de tels cas, DMS n'utilise actuellement pas pour les clés primaires les noms utilisés dans la base de données source. Au lieu de cela, DMS crée le nom de clé primaire en fonction du nom de la table. Lorsque le nom de la table est long, l'identificateur généré automatiquement peut être plus long que la limite autorisée pour MySQL.

Pour résoudre ce problème, l'approche actuelle consiste à précréer les tables et les clés primaires dans la base de données cible. Utilisez ensuite une tâche dont le paramètre de tâche Mode de préparation des tables cible est défini sur Ne rien faire ou Tronquer pour remplir les tables cibles.

Erreur : un jeu de caractères non pris en charge entraîne l'échec de la conversion des données de champ

L'erreur suivante se produit lorsqu'un jeu de caractères non pris en charge entraîne l'échec de la conversion des données de champ :


"[SOURCE_CAPTURE ]E: Column 'column-name' uses an unsupported character set [120112] 
A field data conversion failed. (mysql_endpoint_capture.c:2154)

Vérifiez les paramètres de la base de données liés aux connexions. La commande suivante peut être utilisée pour définir ces paramètres.


SHOW VARIABLES LIKE '%char%';

Erreur : page de codes 1252 à UTF8 [120112] Échec de la conversion des données d'un champ

L'erreur suivante peut se produire pendant une migration si des caractères autres que page de codes 1252 se trouvent dans la base de données MySQL source.

  
[SOURCE_CAPTURE ]E: Error converting column 'column_xyz' in table
'table_xyz with codepage 1252 to UTF8 [120112] A field data conversion failed. 
(mysql_endpoint_capture.c:2248)

Pour contourner ce problème, vous pouvez utiliser l'attribut de connexion supplémentaire CharsetMapping avec votre point de terminaison MySQL source pour spécifier la correspondance des jeux de caractères. Vous devrez peut-être redémarrer la tâche de migration AWS DMS depuis le début si vous ajoutez ce paramètre de point de terminaison.

Par exemple, le paramètre de point de terminaison suivant peut être utilisé pour un point de terminaison source MySQL dont le jeu de caractères source est Utf8 ou latin1. 65001 est l'identificateur de la page de code UTF8. 

   
CharsetMapping=utf8,65001
CharsetMapping=latin1,65001

Non-migration des index, des clés étrangères ou des mises à jour ou suppressions en cascade

AWS DMS ne prend pas en charge la migration d'objets secondaires tels que les index et les clés étrangères. Pour répliquer les modifications apportées aux tables enfants à la suite d'une opération de mise à jour ou de suppression en cascade, la contrainte de clé étrangère de déclenchement doit être active sur la table cible. Pour contourner cette limitation, créez la clé étrangère manuellement sur la table cible. Créez ensuite une tâche unique pour le chargement complet et la CDC, ou deux tâches distinctes pour le chargement complet et la CDC, comme décrit ci-après :

Création d'une tâche unique prenant en charge le chargement complet et la CDC

Cette procédure décrit comment migrer des clés étrangères et des index à l'aide d'une tâche unique de chargement complet et de CDC.

Création d'une tâche de chargement complet et de CDC

  1. Créez manuellement les tables avec des clés étrangères et des index sur la cible pour qu'elles correspondent aux tables sources.

  2. Ajoutez l'attribut ECA suivant au point de terminaison AWS DMS cible :

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  3. Créez la tâche AWS DMS avec TargetTablePrepMode défini sur DO_NOTHING.

  4. Définissez le paramètre Stop task after full load completes sur StopTaskCachedChangesApplied.

  5. Lancez la tâche. AWS DMS arrête automatiquement la tâche une fois le chargement complet terminé et applique les modifications mises en cache.

  6. Supprimez l'attribut ECA SET FOREIGN_KEY_CHECKS que vous avez ajouté précédemment.

  7. Reprenez la tâche. La tâche entre dans la phase CDC et applique les modifications continues de la base de données source à la cible.

Création séparée de tâches de chargement complet et de CDC

Ces procédures décrivent comment migrer les clés étrangères et les index à l'aide de tâches distinctes de chargement complet et de CDC.

Création d'une tâche de chargement complet

  1. Créez manuellement les tables avec des clés étrangères et des index sur la cible pour qu'elles correspondent aux tables sources.

  2. Ajoutez l'attribut ECA suivant au point de terminaison AWS DMS cible :

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  3. Créez la tâche AWS DMS avec le paramètre TargetTablePrepMode défini sur DO_NOTHING et EnableValidation défini sur FALSE.

  4. Lancez la tâche. AWS DMS arrête automatiquement la tâche une fois le chargement complet terminé et applique les modifications mises en cache.

  5. Une fois la tâche terminée, notez l'heure UTC de début de la tâche de chargement complet, ou le nom et la position du fichier journal binaire, pour démarrer la tâche de CDC uniquement. Reportez-vous aux journaux pour obtenir l'horodatage (UTC) à partir de l'heure de début du chargement complet initial.

Création d'une tâche de CDC uniquement

  1. Supprimez l'attribut ECA SET FOREIGN_KEY_CHECKS que vous avez défini précédemment.

  2. Créez la tâche de CDC uniquement avec la position de départ définie sur l'heure de début du chargement complet, notée à l'étape précédente. Vous pouvez également utiliser la position du journal binaire enregistrée à l'étape précédente. Définissez le paramètre TargetTablePrepMode sur DO_NOTHING. Activez la validation des données en définissant le paramètre EnableValidation sur TRUE, si nécessaire.

  3. Démarrez la tâche de CDC uniquement et surveillez les journaux pour détecter les erreurs.

Note

Cette solution de contournement s'applique uniquement à une migration de MySQL vers MySQL. Vous ne pouvez pas utiliser cette méthode avec la fonctionnalité d'application par lots, car l'application par lots nécessite que les tables cibles ne possèdent pas de clés étrangères actives.

Résolution des problèmes liés à PostgreSQL

Vous allez en apprendre davantage sur la résolution des problèmes spécifiques à l'utilisation d'AWS DMS avec des bases de données PostgreSQL.

Types de données JSON tronqués

AWS DMS traite le type de données JSON dans PostgreSQL sous la forme d'une colonne de type de données LOB. Cela signifie que la limite de taille des objets LOB, lorsque vous utilisez le mode LOB limité, s'applique aux données JSON.

Supposons, par exemple, que le mode LOB limité soit défini sur 4 096 Ko. Dans ce cas, toutes les données JSON d'une taille supérieure à 4 096 Ko sont tronquées à la limite de 4 096 Ko et échouent au test de validation dans PostgreSQL.

Les informations de journalisation suivantes montrent des données JSON qui ont été tronquées en raison du mode LOB limité et qui n'ont pas pu être validées.

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt.c:2415)

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)

Migration incorrecte de colonnes d'un type de données défini par l'utilisateur

Lors de la réplication à partir d'une source PostgreSQL, AWS DMS crée la table cible avec les mêmes types de données pour toutes les colonnes, sauf les colonnes contenant des types de données définis par l'utilisateur. Dans ces cas, le type de données est créé en tant que « character varying » dans la cible.

Erreur : Aucun schéma sélectionné dans lequel effectuer la création

Dans certains cas, le message d'erreur « SQL_ERROR SqlState : 3F000:7 Message : ERREUR NativeError : aucun schéma n'a été sélectionné pour être créé » peut s'afficher.

Cette erreur peut se produire lorsque le mappage de table JSON contient une valeur générique pour le schéma mais que la base de données source ne prend pas en charge cette valeur.

Les suppressions et les mises à jour dans une table ne sont pas répliquées via la CDC

Les opérations de suppression et de mise à jour pendant la capture des données de modification (CDC) sont ignorées si la table source ne possède pas de clé primaire. AWS DMS prend en charge la capture des données de modification (CDC) pour les tables PostgreSQL avec des clés primaires.

Si une table n'a pas de clé primaire, les journaux d'écriture anticipée (WAL) n'incluent pas d'image antérieure de la ligne de base de données. Dans ce cas, AWS DMS ne peut pas mettre à jour la table. Pour que les opérations de suppression soient répliquées, créez une clé primaire sur la table source.

Les instructions de troncation ne sont pas propagées

Lorsque vous utilisez la capture des données de modification (CDC), les opérations TRUNCATE ne sont pas prises en charge par AWS DMS.

Empêcher PostgreSQL de capturer la DDL

Vous pouvez empêcher un point de terminaison cible PostgreSQL de capturer des instructions DDL en ajoutant l'instruction Paramètres du point de terminaison suivante.


"CaptureDDLs": "N"

Sélectionner le schéma où sont créés les objets de base de données pour la capture de la DDL

Vous pouvez contrôler dans quel schéma les objets de base de données liés à la capture de la DDL sont créés. Ajoutez l'instruction Paramètres du point de terminaison suivante. Le paramètre Paramètres du point de terminaison est disponible dans l'onglet du point de terminaison source.


"DdlArtifactsSchema: "xyzddlschema"

Tables Oracle manquantes après la migration vers PostgreSQL

Dans ce cas, vos tables et données restent généralement accessibles.

Par défaut, Oracle met en majuscules les noms de table, alors que PostgreSQL les met en minuscules par défaut. Lorsque vous effectuez une migration d'Oracle vers PostgreSQL, nous vous conseillons de fournir certaines règles de transformation dans la section de mappage de table de votre tâche. Il s'agit de règles de transformation permettant de convertir la casse des noms de table.

Si vous avez migré des tables sans utiliser de règles de transformation pour convertir la casse des noms de table, placez les noms des tables entre guillemets lorsque vous les référencez.

ReplicationSlotDiskUsage augmente et restart_lsn cesse d'avancer pendant les transactions longues, telles que les charges de travail ETL

Lorsque la réplication logique est activée, le nombre maximal de modifications conservées en mémoire par transaction est de 4 Mo. Ensuite, les modifications sont déversées sur le disque. En conséquence, ReplicationSlotDiskUsage augmente et restart_lsn n'avance pas tant que la transaction n'est pas terminée ou abandonnée et que la restauration n'est pas terminée. Comme il s'agit d'une transaction longue, sa restauration peut prendre beaucoup de temps.

Vous devez donc éviter les transactions de longue durée lorsque la réplication logique est activée. Essayez plutôt de diviser la transaction en plusieurs transactions plus petites.

Une tâche utilisant une vue comme source ne contient aucune ligne copiée

Pour migrer une vue, définissez table-type sur all ou view. Pour plus d’informations, consultez Spécification des règles de sélection de table et de transformation à partir de la console.

Les sources qui prennent en charge les vues incluent les suivantes.

  • Oracle

  • Microsoft SQL Server

  • MySQL

  • PostgreSQL

  • IBM Db2 LUW

  • SAP Adaptive Server Enterprise (ASE)

Résolution des problèmes liés à Microsoft SQL Server

Vous allez en apprendre davantage sur la résolution des problèmes spécifiques à l'utilisation d'AWS DMS avec des bases de données Microsoft SQL Server.

Erreurs de capture des modifications pour une base de données SQL Server

Les erreurs pendant la capture des données de modification (CDC) indiquent souvent qu'une des conditions préalables n'était pas remplie. Par exemple, l'une des conditions préalables les plus fréquemment négligées est une sauvegarde complète de la base de données. Le journal des tâches indique cette omission par l'erreur suivante :


SOURCE_CAPTURE E: No FULL database backup found (under the 'FULL' recovery model). 
To enable all changes to be captured, you must perform a full database backup. 
120438 Changes may be missed. (sqlserver_log_queries.c:2623)

Passez en revue les conditions préalables répertoriées pour l'utilisation de SQL Server en tant que source dans Utilisation d'une base de données Microsoft SQL Server comme source pour AWS DMS.

Colonnes d'identité manquantes

AWS DMS ne prend pas en charge les colonnes d'identité lorsque vous créez un schéma cible. Vous devez les ajouter une fois le chargement initial terminé.

Erreur : SQL Server ne prend pas en charge les publications

L'erreur suivante est généré lorsque vous utilisez SQL Server Express comme point de terminaison source :


RetCode: SQL_ERROR SqlState: HY000 NativeError: 21106 
Message: This edition of SQL Server does not support publications.

AWS DMS ne prend pas en charge actuellement SQL Server Express en tant que source ou cible.

Les modifications ne s'affichent pas dans votre cible

AWS DMS nécessite qu'une base de données SQL Server source soit en mode de récupération de données « FULL » ou « BULK LOGGED » afin de capturer systématiquement les modifications. Le modèle « SIMPLE » n'est pas pris en charge.

Le modèle de récupération SIMPLE enregistre les informations minimales nécessaires pour permettre aux utilisateurs de récupérer leur base de données. Toutes les entrées de journal inactives sont automatiquement tronquées lorsqu'un point de contrôle se produit.

Toutes les opérations sont toujours journalisées. Toutefois, dès qu'un point de contrôle se produit, le journal est automatiquement tronqué. Cette troncation signifie que le journal peut être réutilisé et que les anciennes entrées du journal peuvent être remplacées. Lorsque les entrées du journal sont remplacées, les modifications ne peuvent pas être capturées. Ce problème explique pourquoi AWS DMS ne prend pas en charge le modèle de récupération de données SIMPLE. Pour en savoir plus sur les autres conditions préalables requises pour l'utilisation de SQL Server en tant que source, consultez Utilisation d'une base de données Microsoft SQL Server comme source pour AWS DMS.

Table non uniforme mappée entre les partitions

Pendant la capture des données de modification (CDC), la migration d'une table dotée d'une structure spécialisée est suspendue quand AWS DMS ne peut pas effectuer correctement le processus CDC sur la table. Des messages similaires aux suivants sont émis :


[SOURCE_CAPTURE ]W: Table is not uniformly mapped across partitions. Therefore - it is excluded from CDC (sqlserver_log_metadata.c:1415)
[SOURCE_CAPTURE ]I: Table has been mapped and registered for CDC. (sqlserver_log_metadata.c:835)

Lors de l'exécution du processus CDC sur des tables SQL Server, AWS DMS analyse les enregistrements tlog SQL Server. Sur chaque enregistrement tlog, AWS DMS analyse les valeurs hexadécimales contenant des données pour les colonnes qui ont été insérées, mises à jour ou supprimées lors d'une modification.

Pour analyser l'enregistrement hexadécimal, AWS DMS lit les métadonnées de la table à partir des tables système SQL Server. Ces tables système identifient ce que sont les colonnes de table spécialement structurées et révèlent certaines de leurs propriétés internes, telles que « xoffset » et « null bit position ».

AWS DMS s'attend à ce que les métadonnées soient identiques pour toutes les partitions brutes de la table. Toutefois, dans certains cas, les tables spécialement structurées n'ont pas les mêmes métadonnées sur toutes leurs partitions. Dans ces cas, AWS DMS peut suspendre le processus CDC sur cette table pour éviter d'analyser les modifications de manière incorrecte et de fournir à la cible des données incorrectes. Les solutions de contournement incluent les suivantes :

  • Si la table a un index cluster, effectuez une reconstruction de l'index.

  • Si la table n'a pas d'index organisé en cluster, ajoutez un index organisé en cluster à la table (vous pouvez le supprimer ultérieurement si vous le souhaitez).

Résolution des problèmes liés à Amazon Redshift

Vous allez en apprendre davantage sur la résolution des problèmes spécifiques à l'utilisation d'AWS DMS avec des bases de données Amazon Redshift.

Chargement dans un cluster Amazon Redshift dans une autre région AWS

Vous ne pouvez pas charger dans un cluster Amazon Redshift dans une région AWS autre que celle de l'instance de réplication AWS DMS. DMS exige que l'instance de réplication et le cluster Amazon Redshift figurent dans la même région.

Erreur : la relation « awsdms_apply_exceptions » existe déjà

L'erreur « La relation « awsdms_apply_exceptions » existe déjà » se produit souvent lorsqu'un point de terminaison Redshift est spécifié en tant que point de terminaison PostgreSQL. Pour résoudre ce problème, modifiez le point de terminaison et le Moteur cible en « redshift ».

Erreurs avec les tables dont le nom commence par « awsdms_changes »

Des messages d'erreur de table avec des noms commençant par « awsdms_changes » peuvent apparaître quand deux tâches qui tentent de charger des données dans le même cluster Amazon Redshift s'exécutent simultanément. En raison de la façon dont les tables temporaires sont nommés, des tâches simultanées peuvent entrer en conflit lors de la mise à jour d'une même table.

Présence de tables dans les clusters avec des noms du type dms.awsdms_changes000000000XXXX

AWS DMS crée des tables temporaires lorsque les données sont chargées à partir de fichiers stockés dans Amazon S3. Les noms de ces tables temporaires contiennent tous le préfixe dms.awsdms_changes. Ces tables sont obligatoires pour que AWS DMS puisse stocker des données lorsqu'elles sont chargées pour la première fois et avant qu'elles soient placées dans la table cible finale.

Autorisations requises pour utiliser Amazon Redshift

Pour utiliser AWS DMS avec Amazon Redshift, le compte d'utilisateur que vous utilisez pour accéder à Amazon Redshift doit disposer des autorisations suivantes :

  • CRUD (choisir, insérer, mettre à jour, supprimer)

  • Chargement en bloc

  • Création, modification, suppression (si requis par la définition de la tâche)

Pour voir les conditions préalables requises pour l'utilisation d'Amazon Redshift en tant que cible, consultez Utilisation d'une base de données Amazon Redshift en tant que cible pour AWS Database Migration Service.

Résolution des problèmes liés à Amazon Aurora MySQL

Vous allez en apprendre davantage sur la résolution des problèmes spécifiques à l'utilisation d'AWS DMS avec des bases de données Amazon Aurora MySQL.

Erreur : Champs CHARACTER SET UTF8 se terminant par une « , » entourée par des lignes « " » se terminant par « \n »

Si vous utilisez Amazon Aurora MySQL en tant que cible, il est possible que vous voyiez une erreur similaire à la suivante dans les journaux. Ce type d'erreur indique généralement que le paramètre SQL_MODE contient des caractères ANSI_QUOTES. Si le paramètre SQL_MODE contient des caractères ANSI_QUOTES, les guillemets doubles sont traités comme des apostrophes et peuvent générer des problèmes lorsque vous exécutez une tâche.

Pour corriger cette erreur, supprimez les caractères ANSI_QUOTES du paramètre SQL_MODE.


2016-11-02T14:23:48 [TARGET_LOAD ]E: Load data sql statement. load data local infile 
"/rdsdbdata/data/tasks/7XO4FJHCVON7TYTLQ6RX3CQHDU/data_files/4/LOAD000001DF.csv" into table 
`VOSPUSER`.`SANDBOX_SRC_FILE` CHARACTER SET UTF8 fields terminated by ',' 
enclosed by '"' lines terminated by '\n'( `SANDBOX_SRC_FILE_ID`,`SANDBOX_ID`,
`FILENAME`,`LOCAL_PATH`,`LINES_OF_CODE`,`INSERT_TS`,`MODIFIED_TS`,`MODIFIED_BY`,
`RECORD_VER`,`REF_GUID`,`PLATFORM_GENERATED`,`ANALYSIS_TYPE`,`SANITIZED`,`DYN_TYPE`,
`CRAWL_STATUS`,`ORIG_EXEC_UNIT_VER_ID` ) ; (provider_syntax_manager.c:2561)

Résolution des problèmes liés à SAP ASE

Vous allez en apprendre davantage sur la résolution des problèmes spécifiques à l'utilisation d'AWS DMS avec des bases de données SAP ASE.

Erreur : les colonnes LOB ont des valeurs NULL lorsque la source possède un index unique composite avec des valeurs NULL

Lorsque vous utilisez SAP ASE en tant que source avec des tables configurées avec un index unique composite qui autorise les valeurs NULL, les valeurs LOB risquent de ne pas migrer pendant la réplication continue. Ce comportement est généralement dû au fait que la valeur ANSI_NULL est définie sur 1 par défaut sur le client de l'instance de réplication DMS.

Pour vous assurer que les champs LOB soient correctement migrés, incluez le paramètre de point de terminaison 'AnsiNull=0' dans le point de terminaison source AWS DMS de la tâche.

Résolution des problèmes liés à IBM Db2

Vous allez en apprendre davantage sur la résolution des problèmes spécifiques à l'utilisation d'AWS DMS avec des bases de données IBM Db2.

Erreur : Resume from timestamp is not supported Task

Pour la réplication continue (CDC), si vous prévoyez de démarrer la réplication à partir d'un horodatage spécifique, définissez l'attribut de connexion StartFromContext sur l'horodatage requis. Pour plus d'informations, consultez Paramètres de point de terminaison lors de l'utilisation de Db2 LUW. Définir StartFromContext sur l'horodatage requis permet d'éviter le problème suivant :

Last Error Resume from timestamp is not supported Task error notification received from 
subtask 0, thread 0 [reptask/replicationtask.c:2822] [1020455] 'Start from timestamp' was blocked to prevent Replicate from 
scanning the log (to find the timestamp). When using IBM DB2 for LUW, 'Start from timestamp' is only supported if an actual 
change was captured by this Replicate task earlier to the specified timestamp.