Utilisation d'une base de données Microsoft SQL Server comme source pour AWS DMS - AWS Service de Migration de Base de Données
Limitations sur SQL Server en tant que sourceAutorisations SQL ServerConditions préalables pour l’utilisation de la CDC continueCapture des modifications pour SQL Server autogéré sur site ou sur EC2Configuration de la réplication continue sur une instance de base de données SQL Server cloudParamètres facultatifs pour RDS for SQL Server en tant que sourceMéthodes de compression prises en chargeUtilisation de groupes de AlwaysOn disponibilité SQL Server autogérésExigences de sécuritéParamètres de point de terminaisonTypes de données sources pour SQL Server

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.

Utilisation d'une base de données Microsoft SQL Server comme source pour AWS DMS

Migrez les données d'une ou de plusieurs bases de données Microsoft SQL Server à l'aide de AWS DMS. Avec une base de données SQL Server comme source, vous pouvez migrer des données vers une autre base de données SQL Server ou vers l'une des autres bases de données AWS DMS prises en charge.

Pour plus d'informations sur les versions de SQL Server prises AWS DMS en charge en tant que source, consultezSources pour AWS DMS.

La base de données source SQL Server peut être installée sur n'importe quel ordinateur dans votre réseau. Un compte SQL Server avec les privilèges d'accès appropriés à la base de données source pour le type de tâche que vous avez choisi est également nécessaire pour une utilisation avec AWS DMS. Ce compte doit disposer des autorisations view definition et view server state. Vous ajoutez cette autorisation à l’aide de la commande suivante :

grant view definition to [user]
grant view server state to [user]

AWS DMS prend en charge la migration de données à partir d'instances nommées de SQL Server. Vous pouvez utiliser la notation suivante dans le nom du serveur lorsque vous créez le point de terminaison source.

IPAddress\InstanceName

Par exemple, voici un nom de serveur correct de point de terminaison source. Ici, la première partie du nom est l'adresse IP du serveur et la seconde partie est le nom de l'instance SQL Server (dans cet exemple, SQLTest).

10.0.0.25\SQLTest

Obtenez également le numéro de port sur lequel votre instance nommée de SQL Server écoute et utilisez-le pour configurer votre point de terminaison AWS DMS source.

Note

Le port 1433 est le port par défaut pour Microsoft SQL Server. Mais les ports dynamiques qui changent chaque fois que SQL Server est démarré, et les numéros de port statiques spécifiques utilisés pour se connecter à SQL Server via un pare-feu sont également souvent utilisés. Vous souhaitez donc connaître le numéro de port réel de votre instance nommée de SQL Server lorsque vous créez le point de terminaison AWS DMS source.

Vous pouvez utiliser SSL pour chiffrer les connexions entre votre point de terminaison SQL Server et l'instance de réplication. Pour plus d'informations sur l'utilisation de SSL avec un point de terminaison SQL Server, consultez Utilisation du protocole SSL avec AWS Database Migration Service.

Pour plus de détails sur l'utilisation des bases de données source SQL Server AWS DMS, consultez les sections suivantes.

Limitations relatives à l'utilisation de SQL Server comme source pour AWS DMS

Les limites suivantes s'appliquent lors de l'utilisation d'une base de données SQL Server comme source pour AWS DMS :

  • La propriété d'identité d'une colonne n'est pas migrée vers une colonne de base de données cible.

  • Le point de terminaison SQL Server ne prend pas en charge l'utilisation de tables contenant des colonnes éparses.

  • L'authentification Windows n'est pas prise en charge.

  • Les modifications apportées aux champs calculés dans un serveur SQL Server ne sont pas répliquées.

  • Les tables temporelles ne sont pas prises en charge.

  • L'échange de partition SQL Server n'est pas pris en charge.

  • Lorsque vous utilisez les utilitaires WRITETEXT et UPDATETEXT, AWS DMS ne capture pas les événements appliqués à la base de données source.

  • Le modèle de langage de manipulation de données (DML) suivant n’est pas pris en charge. 

    SELECT * INTO new_table FROM existing_table

  • Lorsque vous utilisez SQL Server comme source, le chiffrement au niveau des colonnes n'est pas pris en charge.

  • AWS DMS ne prend pas en charge les audits au niveau du serveur sur SQL Server 2008 ou SQL Server 2008 R2 en tant que sources. Cela est dû à un problème connu avec SQL Server 2008 et 2008 R2. Par exemple, l'exécution de la commande suivante AWS DMS entraîne un échec.

    USE [master]
GO 
ALTER SERVER AUDIT [my_audit_test-20140710] WITH (STATE=on)
GO

  • Les colonnes de géométrie ne sont pas prises en charge en mode LOB complet si SQL Server est utilisé en tant que source. Utilisez plutôt le mode LOB limité ou définissez le paramètre de tâche InlineLobMaxSize pour utiliser le mode LOB en ligne.

  • Lorsque vous utilisez une base de données source Microsoft SQL Server dans une tâche de réplication, les définitions du diffuseur de publication de réplication SQL Server ne sont pas supprimées si vous supprimez la tâche. Un administrateur système Microsoft SQL Server doit supprimer ces définitions de Microsoft SQL Server.

  • La migration des données depuis les non-schema-bound vues et les données liées au schéma est prise en charge uniquement pour les tâches à chargement complet.

  • La modification de noms de tables à l'aide de sp_rename n'est pas prise en charge (par exemple, sp_rename 'Sales.SalesRegion', 'SalesReg;)

  • La modification de noms de colonnes à l'aide de sp_rename n'est pas prise en charge (par exemple, sp_rename 'Sales.Sales.Region', 'RegID', 'COLUMN';)

  • AWS DMS ne prend pas en charge le traitement des modifications pour définir ou annuler les valeurs par défaut des colonnes (en utilisant la ALTER COLUMN SET DEFAULT clause avec ALTER TABLE instructions).

  • AWS DMS ne prend pas en charge le traitement des modifications pour définir la nullité des colonnes (en utilisant la ALTER COLUMN [SET|DROP] NOT NULL clause avec des ALTER TABLE instructions).

  • Avec SQL Server 2012 et SQL Server 2014, lors de l’utilisation de la réplication DMS avec des groupes de disponibilité, la base de données de distribution ne peut pas être placée dans un groupe de disponibilité. SQL 2016 prend en charge le placement de la base de données de distribution dans un groupe de disponibilité, à l'exception des bases de données de distribution utilisées dans les topologies de fusion, bidirectionnelles ou de peer-to-peer réplication.

  • Pour les tables partitionnées, AWS DMS ne prend pas en charge les différents paramètres de compression des données pour chaque partition.

  • Lorsque vous insérez une valeur dans les types de données spatiales SQL Server (GEOGRAPHY et GEOMETRY), vous pouvez ignorer la propriété SRID (Spatial Reference System Identifier) ou spécifier un nombre différent. Lors de la réplication de tables contenant des types de données spatiales, AWS DMS remplace le SRID par le SRID par défaut (0 pour GEOMETRY et 4326 pour GEOGRAPHY).

  • Si votre base de données n'est pas configurée pour MS-REPLICATION ou MS-CDC, vous pouvez toujours capturer des tables qui n'ont pas de clé primaire, mais seuls les événements DML INSERT/DELETE sont capturés. Les événements UPDATE et TRUNCATE TABLE sont ignorés.

  • Les index Columnstore ne sont pas pris en charge.

  • Les tables optimisées pour la mémoire (utilisant OLTP en mémoire) ne sont pas prises en charge.

  • Lors de la réplication d’une table avec une clé primaire composée de plusieurs colonnes, la mise à jour des colonnes de clé primaire pendant le chargement complet n’est pas prise en charge.

  • La durabilité retardée n'est pas prise en charge.

  • Le paramètre de point de terminaison readBackupOnly=Y (attribut de connexion supplémentaire) ne fonctionne pas sur les instances source RDS for SQL Server en raison de la manière dont RDS effectue les sauvegardes.

  • EXCLUSIVE_AUTOMATIC_TRUNCATION ne fonctionne pas sur les instances source Amazon RDS SQL Server, car les utilisateurs de RDS ne sont pas autorisés à exécuter la procédure stockée SQL Server sp_repldone.

  • AWS DMS ne capture pas les commandes de troncation.

  • AWS DMS ne prend pas en charge la réplication à partir de bases de données lorsque la restauration accélérée des bases de données (ADR) est activée.

  • AWS DMS ne prend pas en charge la capture d'instructions en langage de définition de données (DDL) et en langage de manipulation de données (DML) au cours d'une seule transaction.

  • AWS DMS ne prend pas en charge la réplication des packages d'applications au niveau des données (DACPAC).

  • Les instructions UPDATE qui impliquent des clés primaires ou des index uniques et qui mettent à jour plusieurs lignes de données peuvent provoquer des conflits lorsque vous appliquez les modifications à la base de données cible. Cela peut se produire, par exemple, lorsque la base de données cible applique des mises à jour sous forme d’instructions INSERT et DELETE au lieu d’une seule instruction UPDATE. Avec le mode d’application optimisé par lots, la table peut être ignorée. Avec le mode d’application transactionnel, l’opération UPDATE peut entraîner des violations de contrainte. Pour éviter ce problème, rechargez la table correspondante. Vous pouvez également rechercher les enregistrements problématiques dans la table de contrôle Application des exceptions (dmslogs.awsdms_apply_exceptions) et les modifier manuellement dans la base de données cible. Pour de plus amples informations, veuillez consulter Paramètres de réglage du traitement des modifications.

  • AWS DMS ne prend pas en charge la réplication de tables et de schémas dont le nom inclut un caractère spécial de l'ensemble suivant.

    \\ -- \n \" \b \r ' \t ;

  • Le masquage des données n'est pas pris en charge. AWS DMS migre les données masquées sans les masquer.

  • AWS DMS réplique jusqu'à 32 767 tables avec des clés primaires et jusqu'à 1 000 colonnes pour chaque table. Cela est dû au fait que AWS DMS crée un article de réplication SQL Server pour chaque table répliquée, et les articles de réplication de SQL Server présentent ces limites.

  • Lorsque vous utilisez la capture des données de modification (CDC), vous devez définir toutes les colonnes qui constituent un index unique en tant que NOT NULL. Si cette exigence n’est pas remplie, l’erreur système SQL Server 22838 se produit.

Les limitations suivantes s'appliquent lors de l'accès aux journaux de transactions de sauvegarde :

  • Les sauvegardes chiffrées ne sont pas prises en charge.

  • Les sauvegardes stockées sur une URL ou sur Windows Azure ne sont pas prises en charge.

  • AWS DMS ne prend pas en charge le traitement direct des sauvegardes du journal des transactions au niveau des fichiers à partir de dossiers partagés alternatifs.

Autorisations pour les tâches de chargement complet uniquement

Les autorisations suivantes sont requises pour effectuer des tâches de chargement complet uniquement. Notez que AWS DMS cela ne crée pas le dms_user login. Pour en savoir plus sur la création d’un identifiant de connexion pour SQL Server, consultez Création d'un utilisateur de base de données avec Microsoft SQL Server.

USE db_name;
                
                CREATE USER dms_user FOR LOGIN dms_user; 
                ALTER ROLE [db_datareader] ADD MEMBER dms_user; 
                GRANT VIEW DATABASE STATE to dms_user ; 
                
                USE master;
                
                GRANT VIEW SERVER STATE TO dms_user;

Conditions préalables pour l’utilisation de la réplication continue (CDC) à partir d’une source SQL Server

Vous pouvez utiliser la réplication continue (capture des données de modification ou CDC) pour une base de données SQL Server autogérée sur site ou sur Amazon EC2, ou une base de données de cloud telle que Amazon RDS ou une instance gérée par Microsoft Azure SQL.

Les conditions suivantes s'appliquent précisément lorsque la réplication continue est utilisée avec une base de données SQL Server comme source pour AWS DMS :

  • SQL Server doit être configuré pour des sauvegardes complètes et vous devez effectuer une sauvegarde avant de commencer la réplication des données.

  • Le modèle de récupération doit être défini sur Bulk logged ou Full.

  • La sauvegarde SQL Server sur plusieurs disques n'est pas prise en charge. Si la sauvegarde est définie pour écrire la sauvegarde de la base de données dans plusieurs fichiers sur différents disques, AWS DMS vous ne pouvez pas lire les données et la AWS DMS tâche échoue.

  • Pour les sources SQL Server autogérées, les définitions du diffuseur de publication de réplication SQL Server pour la source utilisée dans une tâche de CDC DMS ne sont pas supprimées lorsque vous supprimez la tâche. Un administrateur système SQL Server doit supprimer ces définitions de SQL Server pour les sources autogérées.

  • Pendant le CDC, il AWS DMS doit consulter les sauvegardes du journal des transactions de SQL Server pour lire les modifications. AWS DMS ne prend pas en charge les sauvegardes du journal des transactions SQL Server créées à l'aide de logiciels de sauvegarde tiers qui ne sont pas au format natif. Pour prendre en charge les sauvegardes du journal des transactions qui sont au format natif et qui ont été créées à l’aide d’un logiciel de sauvegarde tiers, ajoutez l’attribut de connexion use3rdPartyBackupDevice=Y au point de terminaison source.

  • Pour les sources SQL Server autogérées, sachez que SQL Server ne capture pas les modifications sur les tables nouvellement créées tant qu'elles n'ont pas été publiées. Lorsque des tables sont ajoutées à une source SQL Server, AWS DMS gère la création de la publication. Toutefois, ce processus peut prendre plusieurs minutes. Les opérations réalisées sur les tables nouvellement créées pendant ce délai ne sont pas capturées ni répliquées sur la cible.

  • AWS DMS la capture des données de modification nécessite l'activation de la journalisation complète des transactions dans SQL Server. Pour activer la journalisation complète des transactions dans SQL Server, activez MS-REPLICATION ou CHANGE DATA CAPTURE (CDC).

  • Les entrées tlog SQL Server ne seront pas marquées pour être réutilisées tant que la tâche de capture MS CDC n’aura pas traité ces modifications.

  • Les opérations CDC ne sont pas prises en charge sur les tables de mémoire optimisée. Cette limitation s’applique à SQL Server 2014 (lorsque la fonctionnalité a été introduite pour la première fois) et aux versions ultérieures.

  • AWS DMS la capture des données de modification nécessite une base de données de distribution par défaut sur Amazon EC2 ou On-Prem SQL Server comme source. Vous devez donc vous assurer d’avoir activé le distributeur lors de la configuration de la réplication MS pour les tables comportant des clés primaires.

Capture des modifications de données pour SQL Server autogéré sur site ou sur Amazon EC2

Pour capturer les modifications à partir d’une base de données Microsoft SQL Server source, assurez-vous que la base de données est configurée pour des sauvegardes complètes. Configurez la base de données en mode récupération complète ou en mode journalisation en bloc.

Pour une source SQL Server autogérée, AWS DMS utilise ce qui suit :

Réplication Microsoft

Pour capturer les modifications pour des tables comportant des clés primaires. Vous pouvez le configurer automatiquement en octroyant des privilèges d'administrateur système à l'utilisateur du AWS DMS point de terminaison sur l'instance SQL Server source. Vous pouvez également suivre les étapes décrites dans cette section pour préparer la source et utiliser un utilisateur ne disposant pas des privilèges d'administrateur système pour le AWS DMS point de terminaison.

MS-CDC

Pour capturer les modifications pour des tables sans clés primaires. Activez MS-CDC au niveau de la base de données et individuellement pour toutes les tables.

Lorsque vous configurez une base de données SQL Server pour la réplication continue (CDC), vous pouvez procéder de différentes manières :

  • Configurez la réplication continue en utilisant le rôle sysadmin.

  • Configurez la réplication continue pour qu'elle n'utilise pas le rôle sysadmin.

Configuration de la réplication continue sur une instance SQL Server autogérée

Cette section contient des informations sur la configuration de la réplication continue sur une instance SQL Server autogérée en utilisant ou non le rôle sysadmin.

Configuration de la réplication continue sur une instance SQL Server autogérée : Utilisation du rôle sysadmin

AWS DMS la réplication continue pour SQL Server utilise la réplication native de SQL Server pour les tables dotées de clés primaires et la capture des données de modification (CDC) pour les tables sans clés primaires.

Avant de configurer la réplication continue, consultez Conditions préalables pour l’utilisation de la réplication continue (CDC) à partir d’une source SQL Server.

Pour les tables avec des clés primaires, AWS DMS vous pouvez généralement configurer les artefacts requis sur la source. En revanche, pour les instances SQL Server source autogérées, assurez-vous de configurer manuellement la distribution SQL Server en premier. Ensuite, les utilisateurs de la AWS DMS source disposant d'une autorisation d'administrateur système peuvent créer automatiquement la publication pour les tables avec des clés primaires.

Pour vérifier si la distribution a déjà été configurée, exécutez la commande suivante.

sp_get_distributor

Si le résultat est NULL pour la distribution de colonnes, cela signifie que la distribution n’est pas configurée. Vous pouvez procéder comme suit pour configurer la distribution.

Pour configurer la distribution

  1. Connectez-vous à la base de données source SQL Server à l’aide de l’outil SQL Server Management Studio (SSMS).

  2. Ouvrez le menu contextuel (clic droit) pour le dossier Replication, puis choisissez Configurer la distribution. L’assistant Configurer la distribution s’affiche.

  3. Suivez les instructions de l’assistant pour entrer les valeurs par défaut et créer la distribution.

Pour configurer la CDC

AWS DMS la version 3.4.7 et les versions ultérieures peuvent configurer MS CDC pour votre base de données et toutes vos tables automatiquement si vous n'utilisez pas de réplique en lecture seule. Pour utiliser cette fonctionnalité, définissez l’ECA SetUpMsCdcForTables sur true. Pour en savoir plus sur les ECA, consultez Paramètres de point de terminaison.

Pour les versions AWS DMS antérieures à 3.4.7, ou pour une réplique en lecture seule en tant que source, effectuez les opérations suivantes :

  1. Pour les tables sans clés primaires, configurez MS-CDC pour la base de données. Pour ce faire, utilisez un compte auquel le rôle sysadmin est affecté et exécutez la commande suivante.

    use [DBname]
EXEC sys.sp_cdc_enable_db

  2. Configurez ensuite MS-CDC pour chacune des tables sources. Pour chaque table disposant de clés uniques mais ne disposant pas de clé primaire, exécutez la requête suivante afin de configurer MS-CDC.

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@index_name = N'unique_index_name',
@role_name = NULL,
@supports_net_changes = 1
GO

  3. Pour chaque table ne disposant pas de clé primaire ou de clé unique, exécutez la requête suivante afin de configurer MS-CDC.

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL
GO

Pour plus d'informations sur la configuration de MS-CDC pour des tables spécifiques, consultez la documentation SQL Server.

Configuration de la réplication continue sur une instance SQL Server autonome : sans le rôle sysadmin

Pour en savoir plus sur la configuration de la réplication continue sur une instance SQL Server autonome sans le rôle sysadmin, consultez Configuration de la réplication continue sur une instance SQL Server autonome : sans le rôle sysadmin.

Configuration de la réplication continue sur une instance de base de données SQL Server cloud

Cette section explique comment configurer la CDC sur une instance de base de données SQL Server hébergée sur le cloud. Une instance SQL Server hébergée sur le cloud est une instance exécutée sur Amazon RDS for SQL Server, une instance gérée par Azure SQL ou toute autre instance SQL Server gérée dans le cloud. Pour en savoir plus sur les limitations relatives à la réplication continue pour chaque type de base de données, consultez Limitations relatives à l'utilisation de SQL Server comme source pour AWS DMS.

Avant de configurer la réplication continue, consultez Conditions préalables pour l’utilisation de la réplication continue (CDC) à partir d’une source SQL Server.

À la différence des sources Microsoft SQL Server autogérées, Amazon RDS for SQL Server ne prend pas en charge la réplication Microsoft. Par conséquent, AWS DMS vous devez utiliser MS-CDC pour les tables avec ou sans clés primaires.

Amazon RDS n'accorde pas de privilèges d'administrateur système pour configurer les artefacts de réplication AWS DMS utilisés pour les modifications continues dans une instance SQL Server source. Veillez à activer MS-CDC pour l’instance Amazon RDS (en utilisant des privilèges d’utilisateur principal) comme décrit dans la procédure suivante.

Pour activer MS-CDC pour une instance de base de données SQL Server cloud

  1. Exécutez l’une des requêtes suivantes au niveau de la base de données.

    Pour une instance de base de données RDS for SQL Server, utilisez cette requête.

    exec msdb.dbo.rds_cdc_enable_db 'DB_name'

    Pour une instance de base de données gérée par Azure SQL, utilisez cette requête.

    USE DB_name 
GO 
EXEC sys.sp_cdc_enable_db 
GO

  2. Pour chaque table disposant d’une clé primaire, exécutez la requête suivante afin d’activer MS-CDC.

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL,
@supports_net_changes = 1
GO

    Pour chaque table disposant de clés uniques mais ne disposant pas de clé primaire, exécutez la requête suivante afin d’activer MS-CDC.

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@index_name = N'unique_index_name',
@role_name = NULL,
@supports_net_changes = 1
GO

    Pour chaque table ne disposant pas de clé unique ni de clé primaire, exécutez la requête suivante afin d’activer MS-CDC.

    exec sys.sp_cdc_enable_table
@source_schema = N'schema_name',
@source_name = N'table_name',
@role_name = NULL
GO

  3. Définissez la période de rétention pour rendre les modifications disponibles au niveau de la source en utilisant les commandes suivantes.

    use dbname
EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@pollinginterval = 86399
exec sp_cdc_stop_job 'capture'
exec sp_cdc_start_job 'capture'

    Le paramètre @pollinginterval est mesuré en secondes avec une valeur recommandée définie sur 86399. Cela signifie que le journal des transactions conserve les modifications pendant 86 399 secondes (un jour) lorsque @pollinginterval = 86399. La procédure exec sp_cdc_start_job 'capture' lance les paramètres.

    Note

    Dans certaines versions de SQL Server, si la valeur de pollinginterval est définie sur plus de 3 599 secondes, elle est réinitialisée à la valeur par défaut de 5 secondes. Dans ce cas, les entrées du T-Log sont purgées avant de AWS DMS pouvoir les lire. Pour déterminer quelles versions de SQL Server sont concernées par ce problème connu, consultez cet article de la base de connaissances Microsoft.

    Si vous utilisez Amazon RDS avec le mode multi-AZ, veillez à configurer également votre instance secondaire de sorte qu’elle ait les bonnes valeurs en cas de basculement.

    exec rdsadmin..rds_set_configuration 'cdc_capture_pollinginterval' , 86399

Si une tâche de AWS DMS réplication qui capture les modifications continues apportées à votre source SQL Server s'arrête pendant plus d'une heure, suivez la procédure ci-dessous.

Pour maintenir la période de rétention pendant une tâche AWS DMS de réplication

  1. Arrêtez la tâche qui tronque les journaux de transactions à l’aide de la commande suivante. 

    exec sp_cdc_stop_job 'capture'

  2. Trouvez votre tâche sur la AWS DMS console et reprenez-la.

  3. Choisissez l’onglet Surveillance, puis vérifiez la métrique CDCLatencySource.

  4. Une fois que la métrique CDCLatencySource est égale à 0 (zéro) et ne change plus, redémarrez la tâche qui tronque les journaux de transactions à l’aide de la commande suivante.

    exec sp_cdc_start_job 'capture'

N’oubliez pas de démarrer la tâche qui tronque les journaux de transactions SQL Server. Dans le cas contraire, l’espace de stockage sur votre instance SQL Server risque de se remplir.

Limitations de la réplication continue sur une instance de base de données SQL Server cloud

  • AWS DMS prend en charge la réplication continue (CDC) uniquement avec le journal des transactions actif. Vous ne pouvez pas utiliser le journal de sauvegarde avec la CDC.

  • Vous risquez de perdre des événements si vous les déplacez du journal des transactions actif vers le journal de sauvegarde ou si vous les tronquez du journal des transactions actif.

Paramètres recommandés lors de l'utilisation d'Amazon RDS for SQL Server comme source pour AWS DMS

Lorsque vous utilisez Amazon RDS for SQL Server en tant que source, la tâche de capture repose sur les paramètres maxscans et maxtrans. Ces paramètres régissent le nombre maximal d’analyses effectuées par la capture dans le journal des transactions et le nombre de transactions traitées pour chaque analyse.

Pour les bases de données où le nombre de transactions est supérieur à maxtrans*maxscans, l’augmentation de la valeur polling_interval peut entraîner une accumulation d’enregistrements dans le journal des transactions actif. À son tour, cette accumulation peut entraîner une augmentation de la taille du journal des transactions.

Notez que cela AWS DMS ne repose pas sur la tâche de capture MS-CDC. La tâche de capture MS-CDC marque les entrées du journal des transactions comme ayant été traitées. Cela permet à la tâche de sauvegarde du journal des transactions de supprimer les entrées du journal des transactions.

Nous vous recommandons de surveiller la taille du journal des transactions et la réussite des tâches MS-CDC. Si les tâches MS-CDC échouent, le journal des transactions peut augmenter de manière excessive et provoquer des échecs de AWS DMS réplication. Vous pouvez surveiller les erreurs des tâches de capture MS-CDC à l’aide de la vue de gestion dynamique sys.dm_cdc_errors de la base de données source. Vous pouvez surveiller la taille du journal des transactions à l’aide de la commande de gestion DBCC SQLPERF(LOGSPACE).

Pour remédier à l’augmentation du journal des transactions provoquée par MS-CDC

  1. Vérifiez le Log Space Used % pour lequel la base de données AWS DMS est en train de se répliquer et vérifiez qu'il augmente continuellement.

    DBCC SQLPERF(LOGSPACE)

  2. Identifiez ce qui bloque le processus de sauvegarde du journal des transactions.

    Select log_reuse_wait, log_reuse_wait_desc, name from sys.databases where name = db_name();

    Si la valeur log_reuse_wait_desc est égale à REPLICATION, la conservation de la sauvegarde du journal est due à la latence dans MS-CDC.

  3. Augmentez le nombre d’événements traités par la tâche de capture en augmentant les valeurs des paramètres maxtrans et maxscans.

    EXEC sys.sp_cdc_change_job @job_type = 'capture' ,@maxtrans = 5000, @maxscans = 20 
exec sp_cdc_stop_job 'capture'
exec sp_cdc_start_job 'capture'

Pour résoudre ce problème, définissez les valeurs de maxscans et de maxtrans manière à ce maxtrans*maxscans qu'elles soient égales au nombre moyen d'événements générés pour les tables AWS DMS répliquées à partir de la base de données source chaque jour.

Si vous définissez ces paramètres sur une valeur supérieure à la valeur recommandée, les tâches de capture traitent tous les événements des journaux de transactions. Si vous définissez ces paramètres sur une valeur inférieure à la valeur recommandée, la latence MS-CDC augmente ainsi que la taille de votre journal des transactions.

L’identification des valeurs appropriées pour maxscans et maxtrans peut s’avérer difficile, car les modifications de la charge de travail produisent un nombre variable d’événements. Dans ce cas, nous vous recommandons de configurer la surveillance sur la latence MS-CDC. Pour plus d’informations, consultez Monitor the process dans la documentation de SQL Server. Configurez ensuite maxtrans et maxscans de manière dynamique en fonction des résultats de la surveillance.

Si la AWS DMS tâche ne parvient pas à trouver les numéros de séquence de journal (LSN) nécessaires pour reprendre ou poursuivre la tâche, celle-ci peut échouer et nécessiter un rechargement complet.

Note

Lors de l'utilisation AWS DMS pour répliquer des données à partir d'une source RDS pour SQL Server, vous pouvez rencontrer des erreurs lorsque vous tentez de reprendre la réplication après un événement stop-start de l'instance Amazon RDS. Cela est dû au fait que le processus SQL Server Agent redémarre le processus de capture lorsqu’il redémarre après l’événement d’arrêt/démarrage. Cela permet de contourner l’intervalle d’interrogation MS-CDC.

De ce fait, sur les bases de données dont le volume de transactions est inférieur au traitement de la tâche de capture MS-CDC, les données peuvent être traitées ou marquées comme répliquées et sauvegardées avant de AWS DMS pouvoir reprendre là où elles s'étaient arrêtées, ce qui entraîne l'erreur suivante :

[SOURCE_CAPTURE ]E: Failed to access LSN '0000dbd9:0006f9ad:0003' in the backup log sets since BACKUP/LOG-s are not available. [1020465] (sqlserver_endpoint_capture.c:764)

Pour atténuer ce problème, définissez les valeurs maxtrans et maxscans comme recommandé précédemment.

Méthodes de compression prises en charge pour SQL Server

Notez ce qui suit concernant la prise en charge des méthodes de compression SQL Server dans AWS DMS :

  • AWS DMS prend en charge la compression ligne/page dans SQL Server version 2008 et versions ultérieures.

  • AWS DMS ne prend pas en charge le format de stockage Vardecimal.

  • AWS DMS ne prend pas en charge les colonnes clairsemées et la compression de structure en colonnes.

Utilisation de groupes de AlwaysOn disponibilité SQL Server autogérés

Les groupes de disponibilité SQL Server Always On assurent la haute disponibilité et la reprise après sinistre comme alternative au niveau de l’entreprise à la mise en miroir de base de données.

Dans AWS DMS, vous pouvez migrer les modifications à partir d'une seule réplique de groupe de disponibilité principal ou secondaire.

Utilisation du réplica de groupe de disponibilité principal

Pour utiliser le groupe de disponibilité principal comme source dans AWS DMS, procédez comme suit :

  1. Activez l’option de distribution pour toutes les instances de SQL Server dans vos réplicas de disponibilité. Pour de plus amples informations, veuillez consulter Configuration de la réplication continue sur une instance SQL Server autogérée.

  2. Dans la AWS DMS console, ouvrez les paramètres de la base de données source SQL Server. Pour Nom du serveur, spécifiez le nom DNS (Domain Name Service) ou l’adresse IP qui a été configuré(e) pour l’écouteur du groupe de disponibilité.

Lorsque vous démarrez une AWS DMS tâche pour la première fois, le démarrage peut prendre plus de temps que d'habitude. Cette lenteur est due au fait que la création des articles de la table est dupliquée par le serveur du groupe de disponibilité.

Utilisation d’un réplica de groupe de disponibilité secondaire

Pour utiliser un groupe de disponibilité secondaire comme source dans AWS DMS, procédez comme suit :

  1. Utilisez les mêmes informations d'identification pour vous connecter à des répliques individuelles que celles utilisées par l'utilisateur du point de terminaison AWS DMS source.

  2. Assurez-vous que votre instance de AWS DMS réplication peut résoudre les noms DNS de toutes les répliques existantes et s'y connecter. Vous pouvez utiliser la requête SQL suivante pour obtenir les noms DNS de tous vos réplicas.

    select ar.replica_server_name, ar.endpoint_url from sys.availability_replicas ar
JOIN sys.availability_databases_cluster adc
ON adc.group_id = ar.group_id AND adc.database_name = '<source_database_name>';

  3. Lorsque vous créez le point de terminaison source, spécifiez le nom DNS de l’écouteur du groupe de disponibilité pour le nom du serveur du point de terminaison ou pour l’adresse du serveur du secret de point de terminaison. Pour plus d’informations sur les écouteurs de groupe de disponibilité, consultez Qu’est-ce qu’un écouteur de groupe de disponibilité ? dans la documentation de SQL Server.

    Vous pouvez utiliser un serveur DNS public ou un serveur DNS sur site pour résoudre l’écouteur du groupe de disponibilité, le réplica principal et les réplicas secondaires. Pour utiliser un serveur DNS sur site, configurez Amazon Route 53 Resolver. Pour de plus amples informations, veuillez consulter Utilisation de votre propre serveur de noms sur site.

  4. Ajoutez les attributs de connexion supplémentaires suivants au point de terminaison source.

    Attribut de connexion supplémentaire Valeur Remarques
    applicationIntent ReadOnly Sans ce paramètre ODBC, la tâche de réplication est routée vers le réplica du groupe de disponibilité principal. Pour plus d’informations, consultez Prise en charge des fonctionnalités de récupération d’urgence, haute disponibilité par SQL Server Native Client dans la documentation de SQL Server.
    multiSubnetFailover yes Pour plus d’informations, consultez Prise en charge des fonctionnalités de récupération d’urgence, haute disponibilité par SQL Server Native Client dans la documentation de SQL Server.
    alwaysOnSharedSynchedBackupIsEnabled false Pour de plus amples informations, veuillez consulter Paramètres du point de terminaison lors de l'utilisation de SQL Server comme source pour AWS DMS.
    activateSafeguard false Pour plus d'informations, consultez Limites, ci-après.
    setUpMsCdcForTables false Pour plus d'informations, consultez Limites, ci-après.

  5. Activez l’option de distribution sur tous les réplicas de votre groupe de disponibilité. Ajoutez tous les nœuds à la liste des distributeurs. Pour de plus amples informations, veuillez consulter Pour configurer la distribution.

  6. Exécutez la requête suivante sur le réplica principal en lecture-écriture pour activer la publication de la base de données. Vous n’exécutez cette requête qu’une seule fois pour la base de données. 

    sp_replicationdboption @dbname = N'<source DB name>', @optname = N'publish', @value = N'true';

Limites

Les limitations de l’utilisation d’un réplica de groupe de disponibilité secondaire sont les suivantes :

  • AWS DMS ne prend pas en charge Safeguard lors de l'utilisation d'une réplique de groupe de disponibilité en lecture seule comme source. Pour de plus amples informations, veuillez consulter Paramètres du point de terminaison lors de l'utilisation de SQL Server comme source pour AWS DMS.

  • AWS DMS ne prend pas en charge l'attribut de connexion setUpMsCdcForTables supplémentaire lors de l'utilisation d'une réplique de groupe de disponibilité en lecture seule comme source. Pour de plus amples informations, veuillez consulter Paramètres du point de terminaison lors de l'utilisation de SQL Server comme source pour AWS DMS.

  • AWS DMS peut utiliser une réplique de groupe de disponibilité secondaire autogérée comme base de données source pour une réplication continue (capture des données de modification, ou CDC) à partir de la version 3.4.7. Les réplicas de lecture SQL Server Multi-AZ cloud ne sont pas pris en charge. Si vous utilisez des versions précédentes de AWS DMS, assurez-vous d'utiliser la réplique du groupe de disponibilité principal comme base de données source pour CDC.

Basculement vers d’autres nœuds

Si vous définissez l'attribut de connexion ApplicationIntent supplémentaire pour votre point de terminaison surReadOnly, votre AWS DMS tâche se connecte au nœud en lecture seule ayant la priorité de routage en lecture seule la plus élevée. Il bascule ensuite vers les autres nœuds en lecture seule de votre groupe de disponibilité lorsque le nœud en lecture seule ayant la priorité la plus élevée n’est pas disponible. Si vous ne le définissez pasApplicationIntent, votre AWS DMS tâche se connecte uniquement au nœud principal (lecture/écriture) de votre groupe de disponibilité.

Exigences de sécurité lors de l'utilisation de SQL Server comme source pour AWS Database Migration Service

Le compte AWS DMS utilisateur doit avoir au moins le rôle db_owner d'utilisateur dans la base de données SQL Server source à laquelle vous vous connectez.

Paramètres du point de terminaison lors de l'utilisation de SQL Server comme source pour AWS DMS

Vous pouvez utiliser des paramètres de point de terminaison pour configurer la base de données source SQL Server comme si vous utilisiez des attributs de connexion supplémentaires. Vous spécifiez les paramètres lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console ou à l'aide de la create-endpoint commande dans le AWS CLI, avec la syntaxe --microsoft-sql-server-settings '{"EndpointSetting": "value", ...}' JSON.

Les paramètres de point de terminaison que vous pouvez utiliser avec SQL Server en tant que source sont indiqués dans le tableau suivant.

Name (Nom) Description

ActivateSafeguard

Cet attribut active ou désactive Safeguard. Pour en savoir plus sur Safeguard, consultez SafeguardPolicy ci-dessous.

Valeur par défaut : true

Valeurs valides : {false, true}

Exemple : '{"ActivateSafeguard": true}'
AlwaysOnSharedSynchedBackupIsEnabled

Cet attribut ajuste le comportement AWS DMS lors de la migration depuis une base de données source SQL Server hébergée dans le cadre d'un cluster de groupes de disponibilité Always On.

AWS DMS offre une prise en charge améliorée des bases de données source SQL Server configurées pour s'exécuter dans un cluster Always On. Dans ce cas, AWS DMS tente de savoir si des sauvegardes de transactions sont effectuées à partir de nœuds du cluster Always On autres que le nœud sur lequel l’instance de base de données source est hébergée. Au démarrage de la tâche de migration, AWS DMS essaie de se connecter à chaque nœud du cluster, mais échoue s'il ne parvient pas à se connecter à l'un des nœuds.

Si vous AWS DMS devez interroger tous les nœuds du cluster Always On pour les sauvegardes de transactions, définissez cet attribut surfalse.

Valeur par défaut : true

Valeurs valides : true ou false

Exemple : '{"AlwaysOnSharedSynchedBackupIsEnabled": false}'

"ApplicationIntent": "readonly"

Ce paramètre d’attribut du pilote ODBC oblige SQL Server à router votre tâche de réplication vers le nœud en lecture seule ayant la priorité la plus élevée. Sans ce paramètre, SQL Server route votre tâche de réplication vers le nœud en lecture-écriture principal.

EnableNonSysadminWrapper

Utilisez ce paramètre de point de terminaison lorsque vous configurez la réplication continue sur un serveur SQL Server autonome sans utilisateur sysadmin. Ce paramètre est pris en charge dans les AWS DMS versions 3.4.7 et supérieures. Pour en savoir plus sur la configuration de la réplication continue sur une instance SQL Server autonome, consultez Configuration de la réplication continue sur une instance SQL Server autonome : sans le rôle sysadmin.

Valeur par défaut : false

Valeurs valides : true, false

Exemple : '{"EnableNonSysadminWrapper": true}'

ExecuteTimeout

Utilisez cet attribut de connexion supplémentaire (ECA) pour définir le délai d’expiration de l’instruction client pour l’instance SQL Server, en secondes. La valeur par défaut est de 60 secondes.

Exemple : '{"ExecuteTimeout": 100}'

FatalOnSimpleModel

Lorsqu’il est défini sur true, ce paramètre génère une erreur fatale lorsque le modèle de récupération de base de données SQL Server est défini sur simple.

Valeur par défaut : false

Valeurs valides : true ou false

Exemple : '{"FatalOnSimpleModel": true}'

ForceLobLookup

Force la recherche d’objets LOB sur le LOB en ligne.

Valeur par défaut : false

Valeurs valides : true, false

Exemple : '{"ForceLobLookup": false}'

"MultiSubnetFailover": "Yes"

Cet attribut de pilote ODBC permet à DMS de se connecter au nouveau groupe de disponibilité principal en cas de basculement d’un groupe de disponibilité. Cet attribut a été conçu pour les situations où la connexion est rompue ou si l’adresse IP de l’écouteur est incorrecte. Dans ces situations, AWS DMS tente de se connecter à toutes les adresses IP associées à l'écouteur Availability Group.

ReadBackupOnly

L’utilisation de cet attribut nécessite des privilèges sysadmin. Lorsque cet attribut est défini surY, pendant la réplication en cours, AWS DMS lit les modifications uniquement à partir des sauvegardes du journal des transactions et non à partir du fichier journal des transactions actif. Définir ce paramètre sur Y vous permet de contrôler la croissance du fichier journal de transactions actives durant les tâches de chargement complet et de réplication continue. Toutefois, cela peut ajouter une latence source pour la réplication en cours.

Valeurs valides : N ou Y. L’argument par défaut est N.

Exemple : '{"ReadBackupOnly": Y}'

Remarque : ce paramètre ne fonctionne pas sur les instances sources Amazon RDS SQL Server en raison de la manière dont RDS effectue les sauvegardes.

SafeguardPolicy

Pour des performances optimales, AWS DMS essaie de capturer toutes les modifications non lues dans le journal des transactions actif (TLOG). Toutefois, il arrive parfois qu’en raison d’une troncation, le TLOG actif ne contienne pas toutes les modifications non lues. Lorsque cela se produit, AWS DMS accède à la sauvegarde du journal pour capturer les modifications manquantes. Pour minimiser le besoin d'accéder à la sauvegarde du journal, AWS DMS empêchez la troncature à l'aide de l'une des méthodes suivantes :

  1. RELY_ON_SQL_SERVER_REPLICATION_AGENT(Lancer les transactions dans la base de données) : il s'agit de la valeur par défaut pour AWS DMS.

    Lorsque vous utilisez ce paramètre, AWS DMS requiert que l’agent de lecture de journaux SQL Server soit en cours d’exécution, afin qu’ AWS DMS puisse déplacer les transactions marquées pour réplication à partir du TLOG actif. Notez que si l’agent de lecture de journaux n’est pas en cours d’exécution, le TLOG actif peut se remplir, ce qui bascule la base de données source en mode lecture seule jusqu’à ce que vous puissiez résoudre le problème. Si vous devez activer Microsoft Replication dans votre base de données dans un autre but AWS DMS, vous devez choisir ce paramètre.

    Lorsque vous utilisez ce paramètre, il AWS DMS minimise les lectures de sauvegarde du journal en créant une table appelée awsdms_truncation_safeguard et empêche la troncature du TLOG en imitant une transaction ouverte dans la base de données. Cela empêche la base de données de tronquer les événements et de les déplacer vers le journal de sauvegarde pendant cinq minutes (par défaut). Assurez-vous que la table n’est incluse dans aucun plan de maintenance, car cela pourrait entraîner l’échec de la tâche de maintenance. Vous pouvez supprimer la table en toute sécurité si aucune tâche n’est configurée avec l’option de base de données Start Transactions.

  2. EXCLUSIVE_AUTOMATIC_TRUNCATION(À utiliser exclusivement sp_repldone avec une seule tâche) : lorsque vous utilisez ce paramètre, AWS DMS il contrôle totalement le processus de l'agent de réplication qui marque les entrées du journal comme étant ready for truncation utiliséessp_repldone. Avec ce paramètre, AWS DMS n'utilise pas de transaction fictive comme avec le paramètre RELY_ON_SQL_SERVER_REPLICATION_AGENT (par défaut). Vous ne pouvez utiliser ce paramètre que lorsque MS Replication n'est pas utilisé à d'autres fins que dans la AWS DMS base de données source. En outre, lorsque vous utilisez ce paramètre, une seule AWS DMS tâche peut accéder à la base de données. Si vous devez exécuter des AWS DMS tâches parallèles sur la même base de données, utilisezRELY_ON_SQL_SERVER_REPLICATION_AGENT.

    • Ce paramètre nécessite que l’agent de lecture de journaux soit arrêté dans la base de données. Si l'agent Log Reader est en cours d'exécution au démarrage de la AWS DMS tâche, celle-ci forcera son arrêt. Vous pouvez également arrêter l’agent de lecture de journaux manuellement avant de démarrer la tâche.

    • Lorsque vous utilisez cette méthode avec MS-CDC, vous devez arrêter et désactiver les tâches de capture MS-CDC et de nettoyage MS-CDC.

    • Vous ne pouvez pas utiliser ce paramètre lorsque la tâche de migration de Microsoft SQL Server s'exécute sur une machine de distribution distante, car elle AWS DMS n'a pas accès à la machine distante.

    • EXCLUSIVE_AUTOMATIC_TRUNCATION ne fonctionne pas sur les instances sources Amazon RDS for SQL Server, car les utilisateurs d’Amazon RDS ne sont pas autorisés à exécuter la procédure stockée sp_repldone.

    • Si vous définissez SafeguardPolicy sur EXCLUSIVE_AUTOMATIC_TRUNCATION sans utiliser le rôle sysadmin, vous devez accorder des autorisations sur les objets dbo.syscategories et dbo.sysjobs à l’utilisateur dmsuser.

Valeur par défaut : RELY_ON_SQL_SERVER_REPLICATION_AGENT

Valeurs valides : {EXCLUSIVE_AUTOMATIC_TRUNCATION, RELY_ON_SQL_SERVER_REPLICATION_AGENT}

Exemple : '{"SafeguardPolicy": "EXCLUSIVE_AUTOMATIC_TRUNCATION"}'

SetUpMsCdcForTables

Cet attribut active MS-CDC pour la base de données source et pour les tables du mappage de tâche pour lesquelles la réplication Microsoft n’a pas été activée. La définition de cette valeur sur true exécute la procédure stockée sp_cdc_enable_db sur la base de données source et exécute la procédure stockée sp_cdc_enable_table sur chaque table de la tâche pour laquelle la réplication Microsoft n’est pas activée dans la base de données source. Pour plus d’informations sur l’activation de la distribution, consultez Configuration de la réplication continue sur une instance SQL Server autogérée.

Valeurs valides : {true, false}

Exemple : '{"SetUpMsCdcForTables": true}'

TlogAccessMode

Indique le mode utilisé pour extraire les données de CDC.

Valeur par défaut : PreferTlog

Valeurs valides : BackupOnly, PreferBackup, PreferTlog, TlogOnly

Exemple : '{"TlogAccessMode": "PreferTlog"}'

Use3rdPartyBackupDevice

Lorsque cet attribut est défini sur Y, AWS DMS traite les sauvegardes des journaux de transactions tiers si elles sont créées au format natif.

Types de données sources pour SQL Server

La migration de données qui utilise SQL Server comme source AWS DMS prend en charge la plupart des types de données SQL Server. Le tableau suivant indique les types de données source SQL Server pris en charge lors de l'utilisation AWS DMS et le mappage par défaut à partir AWS DMS des types de données.

Pour en savoir plus sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section concernant le point de terminaison cible que vous utilisez.

Pour plus d'informations sur AWS DMS les types de données, consultezTypes de données pour AWS Database Migration Service.

Types de données SQL Server

AWS DMS types de données

BIGINT

INT8

BIT

BOOLEAN

DECIMAL

NUMERIC

INT

INT4

MONEY

NUMERIC

NUMERIC (p,s)

NUMERIC

SMALLINT

INT2

SMALLMONEY

NUMERIC

TINYINT

UINT1

REAL

REAL4

FLOAT

REAL8

DATETIME

DATETIME

DATETIME2 (SQL Server 2008 et versions ultérieures)

DATETIME

SMALLDATETIME

DATETIME

DATE

DATE

TIME

TIME

DATETIMEOFFSET

WSTRING

CHAR

CHAÎNE

VARCHAR

CHAÎNE

VARCHAR (max)

CLOB

TEXT

Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation des types de données CLOB pour une tâche spécifique.

Pour les tables SQL Server, AWS DMS met à jour les colonnes LOB de la cible, même pour les instructions UPDATE qui ne modifient pas la valeur de la colonne LOB dans SQL Server.

Pendant le CDC, AWS DMS prend en charge les types de données CLOB uniquement dans les tables qui incluent une clé primaire.

NCHAR

WSTRING

NVARCHAR (length)

WSTRING

NVARCHAR (max)

NCLOB

NTEXT

Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation de SupportLobs pour une tâche spécifique. Pour plus d’informations sur l’activation de la prise en charge des objets LOB, consultez Configuration du support LOB pour les bases de données sources dans une tâche AWS DMS.

Pour les tables SQL Server, AWS DMS met à jour les colonnes LOB de la cible, même pour les instructions UPDATE qui ne modifient pas la valeur de la colonne LOB dans SQL Server.

Pendant le CDC, AWS DMS prend en charge les types de données CLOB uniquement dans les tables qui incluent une clé primaire.

BINAIRE

BYTES

VARBINARY

BYTES

VARBINARY (max)

BLOB

IMAGE

Pour les tables SQL Server, AWS DMS met à jour les colonnes LOB de la cible, même pour les instructions UPDATE qui ne modifient pas la valeur de la colonne LOB dans SQL Server.

Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation des types de données BLOB pour une tâche spécifique.

AWS DMS prend en charge les types de données BLOB uniquement dans les tables qui incluent une clé primaire.

TIMESTAMP

BYTES

UNIQUEIDENTIFIER

CHAÎNE

HIERARCHYID

Utilisez HIERARCHYID lors de la réplication sur un point de terminaison cible SQL Server.

Utilisez WSTRING (250) lors de la réplication sur tous les autres points de terminaison cibles.

xml

NCLOB

Pour les tables SQL Server, AWS DMS met à jour les colonnes LOB de la cible, même pour les instructions UPDATE qui ne modifient pas la valeur de la colonne LOB dans SQL Server.

Pour utiliser ce type de données avec AWS DMS, vous devez activer l'utilisation des types de données NCLOB pour une tâche spécifique.

Pendant le CDC, AWS DMS prend en charge les types de données NCLOB uniquement dans les tables qui incluent une clé primaire.

GEOMETRY

Utilisez GEOMETRY lors de la réplication de points de terminaison cibles qui prennent en charge ce type de données.

Utilisez CLOB lors de la réplication de points de terminaison cibles qui ne prennent pas en charge ce type de données.

GEOGRAPHY

Utilisez GEOGRAPHY lors de la réplication de points de terminaison cibles qui prennent en charge ce type de données.

Utilisez CLOB lors de la réplication de points de terminaison cibles qui ne prennent pas en charge ce type de données.

AWS DMS ne prend pas en charge les tables qui incluent des champs contenant les types de données suivants.

  • CURSOR

  • SQL_VARIANT

  • TABLE

Note

Les types de données définis par l'utilisateur sont pris en charge selon leur type de base. Par exemple, un type de données défini par l'utilisateur basé sur DATETIME est traité en tant que type de données DATETIME.