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 relatives au SQL serveur en tant que sourceSQLAutorisations du serveurConditions préalables à l'utilisation continue CDCMéthodes de compression prises en chargeUtilisation de groupes de AlwaysOn disponibilité de SQL serveurs autogérésParamètres de point de terminaisonTypes de données source pour le SQL serveur

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 les 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 SQL du serveur source peut être installée sur n'importe quel ordinateur de votre réseau. Un compte de SQL serveur doté des privilèges d'accès appropriés à la base de données source pour le type de tâche que vous avez choisi est requis pour l'utiliser avec AWS DMS. Pour de plus amples informations, veuillez consulter Autorisations pour les tâches SQL du serveur.

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 est le nom de l'instance SQL du serveur (dans cet exemple,SQLTest).

10.0.0.25\SQLTest

Obtenez également le numéro de port sur lequel votre instance de SQL serveur nommée é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 le SQL serveur est démarré et les numéros de port statiques spécifiques utilisés pour se connecter au SQL serveur via un pare-feu sont également souvent utilisés. Vous souhaitez donc connaître le numéro de port réel de l'instance de SQL serveur que vous avez nommée lorsque vous créez le point de terminaison AWS DMS source.

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

Vous pouvez l'utiliser CDC pour une migration continue à partir d'une base de données SQL du serveur. Pour plus d'informations sur la configuration de la base de données de votre SQL serveur source pourCDC, consultezCapture des modifications des données pour une réplication continue à partir SQL du serveur.

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

Rubriques

Limitations relatives à l'utilisation SQL du serveur comme source pour AWS DMS

Les limites suivantes s'appliquent lors de l'utilisation d'une base de données SQL serveur 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 du serveur ne prend pas en charge l'utilisation de tables avec des colonnes éparses.

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

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

  • Les tables temporelles ne sont pas prises en charge.

  • SQLLe changement de partition de serveur n'est pas pris en charge.

  • Lorsque vous utilisez les UPDATETEXT utilitaires WRITETEXT et, 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 SQL du serveur sur 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 lorsque vous utilisez SQL Server comme 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 de SQL Server Replication Publisher 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 DMS réplication avec des groupes de disponibilité, la base de données de distribution ne peut pas être placée dans un groupe de disponibilité. SQL2016 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 du serveur (GEOGRAPHYetGEOMETRY), vous pouvez soit ignorer la propriété identifiant du système de référence spatiale (SRID), soit spécifier un autre nombre. Lorsque vous répliquez des tables avec des types de données spatiales, AWS DMS remplace le SRID par la valeur par défaut SRID (0 pour GEOMETRY et 4326 pourGEOGRAPHY).

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

  • Les index Columnstore ne sont pas pris en charge.

  • Les tables optimisées pour la mémoire (utilisant In-MemoryOLTP) 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 du point de readBackupOnly=Y terminaison (attribut de connexion supplémentaire) ne fonctionne pas RDS pour les instances source SQL du serveur en raison de la manière dont RDS les sauvegardes sont effectuées.

  • EXCLUSIVE_AUTOMATIC_TRUNCATIONne fonctionne pas sur les instances source d'Amazon RDS SQL Server car RDS les utilisateurs n'ont pas accès pour exécuter la procédure stockée SQL du serveur,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 de base de données (ADR) est activée.

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

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

  • UPDATEles instructions 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 des modifications à la base de données cible. Cela peut se produire, par exemple, lorsque la base de données cible applique des DELETE instructions INSERT Updates as and au lieu d'une seule UPDATE instruction. Avec le mode d’application optimisé par lots, la table peut être ignorée. Avec le mode d'application transactionnel, l'UPDATEopération peut entraîner des violations des contraintes. 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 de SQL serveur pour chaque table répliquée, et les articles de réplication de SQL serveur présentent ces limites.

  • Lorsque vous utilisez Change Data Capture (CDC), vous devez définir toutes les colonnes qui constituent un index unique en tant queNOT NULL. Si cette exigence n'est pas remplie, l'erreur système 22838 SQL du serveur en résultera.

  • Vous risquez de perdre des événements si le SQL serveur archive le journal des transactions actif vers le journal de sauvegarde ou les tronque du journal des transactions actif.

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 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.

  • Pour les sources Cloud SQL Server autres qu'Amazon RDS pour Microsoft SQL Server, 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 avecCDC. Vous risquez de perdre des événements si le SQL serveur les archive du journal des transactions actif vers le journal de sauvegarde, ou les tronque du journal des transactions actif avant de DMS pouvoir les lire.

  • Pour les sources Amazon RDS pour Microsoft SQL Server, les versions AWS DMS 3.5.2 et antérieures prennent en charge la réplication continue (CDC) uniquement avec le journal des transactions actif, car il n'est pas DMS possible d'accéder au journal de sauvegarde avecCDC. Vous risquez de perdre des événements si RDS le SQL serveur les archive du journal des transactions actif vers le journal de sauvegarde, ou si le serveur les tronque du journal des transactions actif avant de DMS pouvoir les lire. Cette limitation ne s'applique pas aux AWS DMS versions 3.5.3 et supérieures.

Autorisations pour les tâches SQL du serveur

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 plus d'informations sur la création d'un identifiant pour le SQL serveur, consultezCré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;
                GRANT VIEW DEFINITION to dms_user;
                
                USE master;
                
                GRANT VIEW SERVER STATE TO dms_user;

Autorisations pour les tâches faisant l'objet d'une réplication continue

Les instances de SQL serveur autogérées peuvent être configurées pour DMS une réplication continue avec ou sans le sysadmin rôle. Pour les instances de SQL serveur, où vous ne pouvez pas accorder le sysadmin rôle, assurez-vous que l'DMSutilisateur dispose des privilèges décrits ci-dessous.

Configurer des autorisations pour une réplication continue à partir d'une base de données SQL serveur autogérée

  1. Créez un nouveau compte de SQL serveur avec authentification par mot de passe à l'aide de SQL Server Management Studio (SSMS) ou comme décrit précédemment dansAutorisations pour les tâches de chargement complet uniquement, par exemple,self_managed_user.

  2. Exécutez les GRANT commandes suivantes : 

    GRANT VIEW SERVER STATE TO self_managed_user;

USE MSDB;
    GRANT SELECT ON MSDB.DBO.BACKUPSET TO self_managed_user;
    GRANT SELECT ON MSDB.DBO.BACKUPMEDIAFAMILY TO self_managed_user;
    GRANT SELECT ON MSDB.DBO.BACKUPFILE TO self_managed_user;
    
USE db_name;
    CREATE USER self_managed_user FOR LOGIN self_managed_user;
    ALTER ROLE [db_owner] ADD MEMBER self_managed_user;
    GRANT VIEW DEFINITION to self_managed_user;

  3. Outre les autorisations précédentes, l'utilisateur a besoin de l'une des autorisations suivantes :

Configurer des autorisations pour une réplication continue à partir d'une base de données de SQL serveur cloud

Une instance de SQL serveur hébergée dans le cloud est une instance exécutée sur Amazon RDS pour Microsoft SQL Server, une instance SQL gérée Azure ou toute autre instance de SQL serveur cloud gérée prise en charge parDMS.

Créez un nouveau compte de SQL serveur avec authentification par mot de passe à l'aide de SQL Server Management Studio (SSMS) ou comme décrit précédemment dansAutorisations pour les tâches de chargement complet uniquement, par exemple,rds_user.

Exécutez les commandes GRANT suivantes.

GRANT VIEW SERVER STATE TO rds_user;

USE MSDB;
    GRANT SELECT ON MSDB.DBO.BACKUPSET TO rds_user;
    GRANT SELECT ON MSDB.DBO.BACKUPMEDIAFAMILY TO rds_user;
    GRANT SELECT ON MSDB.DBO.BACKUPFILE TO rds_user;
    
USE db_name;
    CREATE USER rds_user FOR LOGIN rds_user;
    ALTER ROLE [db_owner] ADD MEMBER rds_user;
    GRANT VIEW DEFINITION to rds_user;

Pour les sources Amazon RDS pour Microsoft SQL Server, les DMS versions 3.5.3 et supérieures prennent en charge la lecture à partir des sauvegardes du journal des transactions. Pour vous assurer qu'DMSil est en mesure d'accéder aux sauvegardes des journaux, en plus de ce qui précède, accordez des privilèges à l'masterutilisateur ou les privilèges suivants sur une source de RDS SQL serveur :

//DMS 3.5.3 version onwards
GRANT EXEC ON msdb.dbo.rds_dms_tlog_download TO rds_user;
GRANT EXEC ON msdb.dbo.rds_dms_tlog_read TO rds_user;
GRANT EXEC ON msdb.dbo.rds_dms_tlog_list_current_lsn TO rds_user;
GRANT EXEC ON msdb.dbo.rds_task_status TO rds_user;

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

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

Les exigences suivantes s'appliquent spécifiquement lors de l'utilisation de la réplication continue avec une base de données SQL serveur comme source pour AWS DMS :

  • SQLLe serveur doit être configuré pour des sauvegardes complètes, et vous devez effectuer une sauvegarde avant de commencer à répliquer les données.

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

  • SQLLa sauvegarde du serveur 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 de SQL serveur autogérées, les définitions de SQL Server Replication Publisher pour la source utilisée dans une DMS CDC tâche ne sont pas supprimées lorsque vous supprimez la tâche. Un administrateur système SQL du serveur doit supprimer ces définitions du SQL serveur pour les sources autogérées.

  • PendantCDC, AWS DMS doit consulter les sauvegardes du journal des transactions SQL du serveur pour lire les modifications. AWS DMS ne prend pas en charge les sauvegardes du journal des transactions SQL du serveur 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 de SQL serveur autogérées, sachez que le SQL serveur ne capture pas les modifications apportées aux tables nouvellement créées tant qu'elles n'ont pas été publiées. Lorsque des tables sont ajoutées à une source SQL du serveur, 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 le SQL serveur. Pour activer la journalisation complète des transactions sur le SQL serveur, activez MS- REPLICATION ou CHANGE DATA CAPTURE (CDC).

  • SQLLes entrées du tlog du serveur ne seront pas marquées pour être réutilisées tant que la tâche de CDC capture MS n'aura pas traité ces modifications.

  • CDCles opérations ne sont pas prises en charge sur les tables optimisées pour la mémoire. 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 sur un SQL serveur On-Prem 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.

Méthodes de compression prises en charge pour le SQL serveur

Notez ce qui suit à propos de la prise en charge des méthodes de compression SQL du serveur dans AWS DMS :

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

  • 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é de SQL serveurs autogérés

SQLLes groupes de disponibilité Server Always On offrent une haute disponibilité et une reprise après sinistre en tant qu'alternative au niveau de l'entreprise à la mise en miroir de bases 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 serveur dans vos répliques de disponibilité. Pour de plus amples informations, veuillez consulter Configuration de la réplication continue sur un serveur autogéré SQL.

  2. Dans la AWS DMS console, ouvrez les paramètres de la base de données source SQL du serveur. Pour le nom du serveur, spécifiez le nom ou l'adresse IP du service de noms de domaine (DNS) configuré pour votre écouteur de 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 DNS noms de toutes les répliques existantes et s'y connecter. Vous pouvez utiliser la SQL requête suivante pour obtenir les DNS noms de toutes vos répliques.

    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 DNS nom de l'écouteur du groupe de disponibilité pour le nom du serveur du point de terminaison ou pour l'adresse du serveur du secret du point de terminaison. Pour plus d'informations sur les écouteurs de groupe de disponibilité, voir Qu'est-ce qu'un écouteur de groupe de disponibilité ? dans la documentation SQL du serveur.

    Vous pouvez utiliser un DNS serveur public ou un serveur sur site DNS pour résoudre l'écouteur du groupe de disponibilité, le réplica principal et les répliques secondaires. Pour utiliser un DNS serveur sur site, configurez le résolveur Amazon Route 53. 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 ODBC paramètre, la tâche de réplication est acheminée vers le réplica du groupe de disponibilité principal. Pour plus d'informations, consultez la section Support client natif SQL du serveur pour la haute disponibilité et la reprise après sinistre dans la documentation SQL du serveur.
    multiSubnetFailover yes Pour plus d'informations, consultez la section Support client natif SQL du serveur pour la haute disponibilité et la reprise après sinistre dans la documentation SQL du serveur.
    alwaysOnSharedSynchedBackupIsEnabled false Pour de plus amples informations, veuillez consulter Paramètres du point de terminaison lors SQL de l'utilisation du serveur 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 SQL de l'utilisation du serveur 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 SQL de l'utilisation du serveur 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 ouCDC) à partir de la version 3.4.7. Les répliques de lecture multi-AZ de Cloud SQL Server ne sont pas prises 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 pourCDC.

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é.

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

Vous pouvez utiliser les paramètres du point de terminaison pour configurer la base de données source de votre SQL serveur de la même manière que 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 contenue dans le AWS CLI, avec la --microsoft-sql-server-settings '{"EndpointSetting": "value", ...}' JSON syntaxe.

Le tableau suivant indique les paramètres de point de terminaison que vous pouvez utiliser avec le SQL serveur en tant que source.

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 du serveur hébergée dans le cadre d'un cluster de groupes de disponibilité Always On.

AWS DMS a amélioré la prise en charge des bases de données source SQL du serveur 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 de ODBC pilote oblige le SQL serveur à acheminer votre tâche de réplication vers le nœud en lecture seule ayant la priorité la plus élevée. Sans ce paramètre, le SQL serveur achemine votre tâche de réplication vers le nœud de lecture-écriture principal.

EnableNonSysadminWrapper

Utilisez ce paramètre de point de terminaison lorsque vous configurez une réplication continue sur un SQL serveur autonome sans utilisateur sysadmin. Ce paramètre est pris en charge dans les AWS DMS versions 3.4.7 et supérieures. Pour plus d'informations sur la configuration de la réplication continue sur un SQL serveur autonome, consultezCapture des modifications des données pour une réplication continue à partir SQL du serveur.

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 du serveur, en secondes. La valeur par défaut est de 60 secondes.

Exemple : '{"ExecuteTimeout": 100}'

FatalOnSimpleModel

Lorsqu'il est défini surtrue, ce paramètre génère une erreur fatale lorsque le modèle de restauration de base de données SQL du serveur est défini sursimple.

Valeur par défaut : false

Valeurs valides : true ou false

Exemple : '{"FatalOnSimpleModel": true}'

ForceLobLookup

Force la LOB recherche en ligne. LOB

Valeur par défaut : false

Valeurs valides : true, false

Exemple : '{"ForceLobLookup": false}'

"MultiSubnetFailover": "Yes"

Cet attribut de ODBC pilote permet DMS de se connecter au nouveau serveur 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 source d'Amazon RDS SQL Server en raison de la manière dont RDS les sauvegardes sont effectuées.

SafeguardPolicy

Pour des performances optimales, AWS DMS essaie de capturer toutes les modifications non lues dans le journal des transactions actif (TLOG). Cependant, en raison de la troncature, le fichier actif TLOG peut ne pas contenir 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 l'agent SQL Server Log Reader doit être en cours d'exécution, afin de AWS DMS pouvoir déplacer les transactions marquées pour réplication depuis les transactions activesTLOG. Notez que si l'agent Log Reader n'est pas en cours d'exécution, le fichier actif TLOG peut être saturé, ce qui fait passer 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 TLOG troncature 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 CDCcapture et de CDCnettoyage MS-.

    • Vous ne pouvez pas utiliser ce paramètre lorsque la tâche de migration de Microsoft SQL Server s'exécute sur un ordinateur du distributeur distant, car celui-ci AWS DMS n'a pas accès à l'ordinateur distant.

    • EXCLUSIVE_AUTOMATIC_TRUNCATIONne fonctionne pas sur les instances source Amazon RDS for SQL Server car RDS les utilisateurs d'Amazon n'ont pas accès pour exécuter la procédure sp_repldone stockée.

    • 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 des tâches pour lesquelles la réplication MS n'est pas 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 un serveur autogéré SQL.

Valeurs valides : {true, false}

Exemple : '{"SetUpMsCdcForTables": true}'

TlogAccessMode

Indique le mode utilisé pour récupérer les CDC données.

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 source pour le SQL serveur

La migration de données qui utilise le SQL serveur comme source AWS DMS prend en charge la plupart des types de données SQL du serveur. Le tableau suivant indique les types de données source SQL du serveur 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.

SQLTypes de données du serveur

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(SQLServer 2008 et versions ultérieures)

DATETIME

SMALLDATETIME

DATETIME

DATE

DATE

TIME

TIME

DATETIMEOFFSET

WSTRING

CHAR

STRING

VARCHAR

STRING

VARCHAR(maximum)

CLOB

TEXT

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

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

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

NCHAR

WSTRING

NVARCHAR(longueur)

WSTRING

NVARCHAR(maximum)

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 de la LOB prise en charge des bases de données sources dans une AWS DMS tâche.

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

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

BINARY

BYTES

VARBINARY

BYTES

VARBINARY(maximum)

BLOB

IMAGE

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

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

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

TIMESTAMP

BYTES

UNIQUEIDENTIFIER

STRING

HIERARCHYID

HIERARCHYIDÀ utiliser lors de la réplication vers un point de terminaison cible SQL du serveur.

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

XML

NCLOB

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

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

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

GEOMETRY

À utiliser GEOMETRY lors de la réplication vers des points de terminaison cibles prenant en charge ce type de données.

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

GEOGRAPHY

À utiliser GEOGRAPHY lors de la réplication vers des points de terminaison cibles prenant en charge ce type de données.

À utiliser CLOB lors de la réplication vers des 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é comme un type de DATETIME données.