Data Transmission Service:Synchroniser des données d'une base de données SQL Server auto-gérée vers une instance RDS PostgreSQL

Base de données source

• Les tables doivent posséder une contrainte PRIMARY KEY ou UNIQUE garantissant l'unicité de tous leurs champs. À défaut, la base de données de destination risque de contenir des enregistrements en double.

• Lors de la sélection d'objets au niveau de la table avec modification de la destination (comme le renommage de tables ou de colonnes), une seule tâche peut synchroniser jusqu'à 5 000 tables. Au-delà, configurez plusieurs tâches ou effectuez une synchronisation au niveau de la base de données.

• Une tâche unique permet de synchroniser jusqu'à 10 bases de données. Si vous devez en synchroniser davantage, configurez plusieurs tâches afin d'éviter tout problème de performance ou de stabilité.

• DTS utilise la fonction fn_log pour lire les journaux source. Ne purgez pas ces journaux avant la fin de la tâche, sous peine de provoquer son échec.

• Exigences relatives à la sauvegarde des journaux :

  • Activez la journalisation des données. Définissez le mode de sauvegarde sur Full et effectuez une sauvegarde physique complète.

  • Pour une synchronisation incrémentielle uniquement : conservez les journaux pendant plus de 24 heures.

  • Pour une synchronisation combinée complète et incrémentielle : conservez les journaux pendant au moins 7 jours. Une fois la synchronisation complète terminée, réduisez cette durée de rétention à plus de 24 heures. Le non-respect de ces exigences peut compromettre le contrat de niveau de service (SLA) de DTS.

• Pour activer la CDC sur les tables sources, toutes les conditions suivantes doivent être remplies (sinon, la pré-vérification échoue) :

  • Le champ srvname dans sys.sysservers doit correspondre à la valeur retournée par la fonction SERVERPROPERTY.

  • SQL Server auto-géré : le propriétaire de la base de données doit être l'utilisateur sa.

  • ApsaraDB RDS for SQL Server : le propriétaire de la base de données doit être l'utilisateur sqlsa.

  • Édition Enterprise : SQL Server 2008 ou version ultérieure requis.

  • Édition Standard : SQL Server 2016 SP1 ou version ultérieure requis.

  • SQL Server 2017 (édition Standard ou Enterprise) : mettez à niveau vers une version plus récente.

• Instances sources en lecture seule : les opérations DDL ne peuvent pas être synchronisées.

• Source Azure SQL Database : une tâche unique ne peut synchroniser les données que d'une seule base de données.

• Source ApsaraDB RDS for SQL Server : désactivez le chiffrement transparent des données (TDE) pour garantir la stabilité de la tâche. Reportez-vous à la section Désactiver TDE dans « Configurer TDE ».

• Pendant la synchronisation complète des données, activez le niveau d'isolation de transaction READ_COMMITTED_SNAPSHOT dans la base de données source afin d'empêcher les verrous partagés d'interférer avec les écritures. Sans ce paramètre, des incohérences de données ou des pannes d'instance peuvent survenir ; ces incidents ne sont pas couverts par le SLA de DTS.

• Durant la synchronisation du schéma et la synchronisation complète des données, n'exécutez aucune instruction DDL, car cela entraînerait l'échec de la tâche.

• ApsaraDB RDS for SQL Server édition Web : définissez le SQL Server Incremental Synchronization Mode sur Incremental Synchronization Based on Logs of Source Database (Heap tables are not supported) lors de la configuration de la tâche.

Autres limites

• Types de données non pris en charge : CURSOR, ROWVERSION, SQL_VARIANT, HIERARCHYID, POLYGON, GEOMETRY, GEOGRAPHY, ainsi que les types définis par l'utilisateur créés avec CREATE TYPE. Les bases de données source et de destination étant hétérogènes, il n'existe pas de correspondance biunivoque entre les types de données. Évaluez l'impact de la conversion des types sur votre charge de travail. Pour consulter le tableau de mappage des types, reportez-vous à Mappages de types de données pour la synchronisation de schémas.

• Seules les tables peuvent être sélectionnées comme objets de synchronisation, et toutes doivent appartenir au même schéma. Sinon, des incohérences de données ou un échec de la tâche peuvent survenir.

• Si vous utilisez le mode Incremental Synchronization Based on Logs of Source Database (Heap tables are not supported), les tables doivent posséder des index cluster contenant des colonnes de clé primaire. Elles ne peuvent pas être des tables heap, des tables sans clé primaire, des tables compressées ou des tables comportant des colonnes calculées.

• Si la tâche implique une synchronisation incrémentielle, n'effectuez aucune opération de reconstruction d'index. Cela pourrait provoquer l'échec de la tâche et une perte de données. DTS ne peut pas synchroniser les opérations DDL liées à la clé primaire d'une table avec CDC activée.

• Si le nombre de tables avec CDC activée dans une tâche de synchronisation dépasse la limite maximale prise en charge par DTS, la pré-vérification échoue.

• Si un champ unique écrit dans une table avec CDC activée dépasse 64 Ko, exécutez la commande suivante pour supprimer cette limite de taille :

  exec sp_configure 'max text repl size', -1;

• Lors de la modification des objets de synchronisation, il est impossible de retirer des bases de données.

• Les modules de collecte de données incrémentielles de plusieurs tâches de synchronisation partageant la même base de données SQL Server source fonctionnent de manière indépendante.

• En cas d'échec d'une tâche DTS, le support DTS la restaure dans un délai de 8 heures. Durant cette restauration, la tâche peut être redémarrée et ses paramètres modifiés. Les paramètres de la base de données ne sont pas modifiés.

Mode d'analyse hybride basé sur les journaux

• DTS utilise le composant CDC pour synchroniser les données incrémentielles. Assurez-vous que le job CDC de la base de données source s'exécute correctement, faute de quoi la tâche DTS échouera.

• DTS crée le déclencheur dts_cdc_sync_ddl, la table de battement de cœur dts_sync_progress et la table d'historique DDL dts_cdc_ddl_history dans la base de données source, puis active la CDC pour cette base et pour certaines tables spécifiques.

• N'exécutez pas d'instructions SELECT INTO, TRUNCATE ou RENAME COLUMN sur des tables avec CDC activée. Les déclencheurs créés par DTS ne doivent pas être supprimés manuellement.

• N'ajoutez ni ne supprimez de colonnes plus d'une fois toutes les 10 minutes. Par exemple, l'exécution des deux instructions suivantes dans un intervalle de 10 minutes provoque une erreur de tâche :

  ALTER TABLE test_table DROP COLUMN Flag;
  ALTER TABLE test_table ADD Remark nvarchar(50) not null default('');

• Il est recommandé de limiter le nombre maximal d'enregistrements par seconde à 1 000 pour les tables avec CDC activée dans la base de données source.

• Par défaut, le composant CDC conserve les données incrémentielles pendant 3 jours. Pour prolonger cette durée de rétention, exécutez :

  exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>;

  <time> est exprimé en minutes. Si le volume quotidien moyen de données incrémentielles dépasse 10 millions d'enregistrements, définissez <time> sur 1440.

• Une tâche unique prend en charge jusqu'à 1 000 tables avec CDC activée. Dépasser cette limite peut entraîner des retards ou une instabilité.

• Lorsque le module de pré-traitement de la tâche active la CDC au niveau de la base de données et des tables dans la source, des verrous au niveau des tables surviennent pendant quelques secondes en raison des limitations de SQL Server.

Synchronisation incrémentielle basée sur la CDC (mode interrogation)

• Le compte de la base de données source doit disposer des autorisations nécessaires pour activer la CDC. Pour activer la CDC au niveau de la base de données, utilisez un compte doté du rôle sysadmin. Pour l'activer au niveau des tables, utilisez un compte privilégié.

  • Azure SQL Database (modèle vCore) : toutes les bases de données prennent en charge la CDC. Pour les bases de données du modèle DTU, un niveau de service S3 ou supérieur est requis.

  • Amazon RDS for SQL Server : un compte privilégié possède les autorisations requises ; la CDC peut être activée pour les procédures stockées au niveau de la base de données.

  • La CDC ne peut pas être activée pour les index columnstore cluster.

• La synchronisation incrémentielle des données présente une latence de 10 secondes.

• Une tâche unique prend en charge jusqu'à 1 000 tables. Dépasser cette limite peut entraîner des retards ou une instabilité.

• N'ajoutez ni ne supprimez de colonnes plus de deux fois par minute, sous peine de provoquer l'échec de la tâche.

• Ne modifiez pas les instances CDC dans la base de données source pendant la synchronisation. Cela risquerait de provoquer l'échec de la tâche ou une perte de données.

• Par défaut, le composant CDC conserve les données incrémentielles pendant 3 jours. Pour prolonger cette durée de rétention, exécutez :

  exec console.sys.sp_cdc_change_job @job_type = 'cleanup', @retention= <time>;

  <time> est exprimé en minutes. Si le volume quotidien moyen de données incrémentielles dépasse 10 millions d'enregistrements, définissez <time> sur 1440.

• Lorsque le module de pré-traitement de la tâche active la CDC au niveau de la base de données et des tables dans la source, des verrous au niveau des tables surviennent pendant quelques secondes en raison des limitations de SQL Server.

Clés étrangères

• Lors de la synchronisation du schéma, DTS synchronise les clés étrangères de la source vers la destination.

• Pendant la synchronisation complète et incrémentielle des données, DTS désactive temporairement les vérifications de contraintes de clés étrangères et les opérations en cascade au niveau de la session. Si vous exécutez des mises à jour ou des suppressions en cascade sur la source pendant la synchronisation, des incohérences de données peuvent survenir.

Cas particuliers

Si la source est une instance ApsaraDB RDS for SQL Server, DTS crée automatiquement un compte nommé rdsdt_dtsacct sur cette instance. Ne supprimez pas ce compte et ne modifiez pas son mot de passe tant que la tâche de synchronisation est en cours d'exécution. Pour plus d'informations, consultez Comptes système.

Impact sur le stockage

Une fois la synchronisation initiale complète terminée, les tables de destination peuvent occuper plus d'espace de stockage que celles de la source. En effet, les opérations INSERT concurrentes durant cette phase provoquent une fragmentation des tables dans la destination.

Lors de la synchronisation initiale complète, DTS mobilise une partie des ressources de lecture et d'écriture des bases de données source et de destination, ce qui peut augmenter leur charge. Évaluez les performances de vos bases de données avant de lancer la synchronisation. Il est recommandé d'effectuer cette opération pendant les heures creuses, par exemple lorsque la charge CPU des bases source et de destination est inférieure à 30 %.

Étape 1 : Ouvrir la page Data Synchronization

Utilisez l'une des méthodes suivantes :

Étape 2 : Configurer les bases de données source et de destination

Cliquez sur Create Task. Sur la page de configuration de la tâche, définissez les paramètres suivants.

Nom de la tâche

Base de données source

Base de données de destination

Étape 3 : Tester la connectivité

En bas de la page, cliquez sur Test Connectivity and Proceed. Dans la boîte de dialogue CIDR Blocks of DTS Servers, cliquez sur Test Connectivity.

Assurez-vous que les blocs CIDR des serveurs DTS ont bien été ajoutés aux paramètres de sécurité des bases de données source et de destination. Consultez Ajouter les blocs CIDR des serveurs DTS .

Étape 4 : Configurer les objets de synchronisation

À l'étape Configure Objects, définissez les paramètres suivants.

Étape 5 : Configurer les paramètres avancés

Cliquez sur Next: Advanced Settings.

Étape 6 : Configurer la vérification des données (facultatif)

Cliquez sur Next Step: Data Verification. Pour plus de détails, consultez Configurer une tâche de vérification des données.

Étape 7 : Exécuter la pré-vérification

Cliquez sur Next: Save Task Settings and Precheck.

• Pour prévisualiser les paramètres API permettant de configurer cette tâche, passez le curseur sur Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters.

• La tâche doit réussir la pré-vérification avant de pouvoir démarrer.

• Si la pré-vérification échoue, cliquez sur View Details en regard de chaque élément en échec, corrigez les problèmes, puis relancez la pré-vérification.

• Si une alerte se déclenche : pour les alertes non ignorables, corrigez le problème et relancez l'opération. Pour les alertes pouvant être ignorées, cliquez sur Confirm Alert Details, puis sur Ignore dans la boîte de dialogue des détails, cliquez sur OK, puis sur Precheck Again.

Étape 8 : Acheter l'instance

1. Attendez que le Success Rate atteigne 100%, puis cliquez sur Next: Purchase Instance.

2. Sur la page d'achat, configurez les paramètres suivants.

   Paramètre	Description
   Billing Method	Subscription : paiement anticipé pour une période donnée. Plus économique pour une utilisation à long terme. Options : 1 à 9 mois, 1 an, 2 ans, 3 ans ou 5 ans. Pay-as-you-go : facturation horaire. Adapté pour une utilisation à court terme. Libérez l'instance lorsqu'elle n'est plus nécessaire afin d'éviter des frais continus.
   Resource Group Settings	Groupe de ressources pour l'instance de synchronisation. Valeur par défaut : default resource group. Consultez Qu'est-ce que Resource Management ?
   Instance Class	Détermine la vitesse de synchronisation. Faites votre choix en fonction des exigences de votre charge de travail. Consultez Classes d'instances de synchronisation de données.

3. Lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms.

4. Cliquez sur Buy and Start. Dans la boîte de dialogue, cliquez sur OK.

La tâche apparaît dans la liste des tâches. Vous pouvez y suivre sa progression.