Data Transmission Service:Migrate SQL Server databases to Alibaba Cloud

Liste de contrôle de préparation

Avant de sélectionner une solution :

1. Vérifiez la compatibilité des versions. Exécutez la requête suivante sur les instances source et de destination pour vérifier que le niveau de compatibilité de la destination est égal ou supérieur à celui de la source :

      SELECT name, compatibility_level FROM sys.databases;

2. Vérifiez l'accès réseau. Confirmez que les bases de données source et de destination acceptent les connexions provenant des serveurs DTS ou d'autres outils de migration.

3. Évaluez les caractéristiques de la base de données source. Identifiez les tables heap, les tables sans clé primaire, les tables compressées et les tables avec des colonnes calculées. Ces éléments déterminent les modes DTS disponibles. FAQ sur la vérification des types de table.

4. Vérifiez l'édition et la version source. Certains modes de migration nécessitent des éditions et versions spécifiques de SQL Server (détails dans la matrice des capacités ci-dessous).

Sauvegarde physique via Object Storage Service (OSS) (manuelle)

Téléchargez manuellement les sauvegardes complètes et incrémentielles vers OSS, puis restaurez-les sur l'instance de destination.

Procédure :

1. Définissez le paramètre backup_type sur FULL dans la base de données source.

2. Créez une sauvegarde complète et téléchargez-la dans un compartiment OSS.

3. Sauvegardez et téléchargez les journaux incrémentiels selon une planification définie.

4. Arrêtez les écritures dans la base de données source. Une fois le dernier journal incrémentiel rejoué avec succès, basculez les charges de travail vers la destination.

Si la base de données source exécute SQL Server 2008 R2, mettez à niveau la version de la base de données avant d'effectuer cette opération.

Référence : Migrer des données d'une instance SQL Server gérée par l'utilisateur vers une instance ApsaraDB RDS for SQL Server

Sauvegarde physique via Data Disaster Recovery et DTS

Utilisez une passerelle physique et DTS pour automatiser le téléchargement et la restauration des sauvegardes.

Procédure :

1. Déployez une passerelle physique.

2. Utilisez DTS pour migrer les données. Le système télécharge automatiquement les données de sauvegarde vers OSS.

3. Arrêtez les écritures dans la base de données source. Une fois le dernier journal incrémentiel rejoué avec succès, basculez les charges de travail vers la destination.

Référence : Migrer des données d'une base de données SQL Server gérée par l'utilisateur vers une instance ApsaraDB RDS for SQL Server à l'aide d'une passerelle physique

Migration logique DTS : mode d'analyse des journaux

DTS lit et analyse les journaux de transaction de la base de données source pour capturer les modifications.

Procédure :

1. Créez une tâche de migration de données DTS. Définissez le paramètre SQL Server Incremental Synchronization Mode sur Incremental Synchronization Based on Logs of Source Database (Heap tables are not supported).

2. Arrêtez les écritures dans la base de données source. Une fois le dernier journal incrémentiel rejoué avec succès, basculez les charges de travail vers la destination.

Référence : Migrer des données d'une base de données SQL Server gérée par l'utilisateur vers une instance ApsaraDB RDS for SQL Server

Migration logique DTS : mode d'analyse hybride des journaux

Combine l'analyse basée sur les journaux pour les tables non heap avec Change Data Capture (CDC) pour les tables heap, élargissant ainsi la gamme des types de tables migrables.

Procédure :

1. Créez une tâche de migration de données DTS. Définissez le paramètre SQL Server Incremental Synchronization Mode sur Log-based Parsing for Non-heap Tables and CDC-based Incremental Synchronization for Heap Tables (Hybrid Log-based Parsing).

2. Arrêtez les écritures dans la base de données source. Une fois le dernier journal incrémentiel rejoué avec succès, basculez les charges de travail vers la destination.

Migration logique DTS : mode d'interrogation des instances CDC

Utilise le composant CDC natif de SQL Server pour capturer les modifications incrémentielles à partir des tables de modification plutôt que des journaux de transaction. Cette méthode offre une migration plus stable avec une bande passante réduite, sans être affectée par la troncation des journaux.

Procédure :

1. Créez une tâche de migration de données DTS. Définissez le paramètre SQL Server Incremental Synchronization Mode sur Polling and querying CDC instances for incremental synchronization.

2. Arrêtez les écritures dans la base de données source. Une fois le dernier journal incrémentiel rejoué avec succès, basculez les charges de travail vers la destination.

Migration SSMS

Exportez et importez les données manuellement à l'aide de SSMS.

Procédure :

1. Arrêtez les écritures dans la base de données source.

2. Exportez les données de la base de données source à l'aide de SSMS.

3. Importez les données exportées dans la base de données de destination.

4. Vérifiez la cohérence des données, puis basculez les charges de travail vers la destination.

Référence : Utiliser SSMS pour migrer des données vers le cloud

OSS manuel (sauvegarde physique)

• Nécessite une sauvegarde et un téléchargement manuels des journaux.

• Ne migre qu'une seule base de données à la fois.

• Interruption de service de plusieurs minutes lors du basculement final (arrêt des écritures, attente du rejeu du dernier journal incrémentiel).

• La version de la base de données de destination ne peut pas être antérieure à celle de la base de données source.

• Le mappage des noms pour les bases de données, les tables et les colonnes n'est pas pris en charge.

Data Disaster Recovery + DTS (sauvegarde physique)

• L'extension du fichier journal de sauvegarde doit être bak.

• Interruption de service de plusieurs minutes lors du basculement final.

• AliyunDBSAgent doit être installé sur le serveur de la base de données source.

• La version de la base de données de destination ne peut pas être antérieure à celle de la base de données source.

• Le mappage des noms pour les bases de données, les tables et les colonnes n'est pas pris en charge.

Mode d'analyse des journaux (logique)

• Seules certaines instructions DDL peuvent être migrées. Plus de 100 instructions DDL par heure affectent la vitesse de migration.

• Si la vitesse d'écriture des journaux dans la base de données source dépasse 10 Mo/s, 30 Go/heure ou 500 Go/jour, la tâche peut être retardée ou échouer.

• Si la fréquence de sauvegarde des journaux dépasse une fois par heure, DTS peut ne pas réussir à obtenir les journaux de sauvegarde locaux. Conservez les journaux de sauvegarde pendant trois jours sur les disques locaux.

• DTS crée un déclencheur et une table de stockage DDL dans la base de données source pour capturer les modifications DDL.

• Désactivez les contraintes FOREIGN KEY pendant la migration incrémentielle des données. Sinon, la tâche peut échouer.

• Les tables heap, les tables sans clés primaires, les tables compressées et les tables avec des colonnes calculées ne peuvent pas être migrées. FAQ sur la vérification des types de table.

• Les tables sans contrainte PRIMARY KEY ou UNIQUE peuvent contenir des données dupliquées. Si vous devez conserver ces tables, n'utilisez pas cette solution.

• DTS utilise la fonction fn_log pour extraire et analyser les journaux. Cette fonction n'est pas stable. Des opérations inattendues peuvent entraîner l'échec de la tâche.

• Maximum 10 bases de données par tâche de migration de données. Dépasser cette limite peut causer des problèmes de stabilité et de performance.

Mode d'analyse hybride des journaux (logique)

• Exigence d'édition source : SQL Server 2008 ou version ultérieure (Enterprise Edition), ou SQL Server 2016 SP1 ou version ultérieure (Standard Edition). SQL Server 2017 n'est pas pris en charge.

• Seules certaines instructions DDL peuvent être migrées. Plus de 100 instructions DDL par heure affectent la vitesse de migration.

• Si la vitesse d'écriture des journaux dans la base de données source dépasse 10 Mo/s, 30 Go/heure ou 500 Go/jour, la tâche peut être retardée ou échouer.

• Si la fréquence de sauvegarde des journaux dépasse une fois par heure, DTS peut ne pas réussir à obtenir les journaux de sauvegarde locaux. Conservez les journaux de sauvegarde pendant trois jours sur les disques locaux.

• DTS active CDC pour les bases de données et certaines tables. DTS crée également un déclencheur et une table de stockage DDL dans la base de données source pour capturer les modifications DDL.

• Désactivez les contraintes FOREIGN KEY pendant la migration incrémentielle des données. Sinon, la tâche peut échouer.

• Les tables avec des colonnes calculées ne peuvent pas être migrées. FAQ sur la vérification des types de table.

• Les tables sans contrainte PRIMARY KEY ou UNIQUE peuvent contenir des données dupliquées. Si vous devez conserver ces tables, n'utilisez pas cette solution.

• DTS utilise la fonction fn_log pour extraire et analyser les journaux. Cette fonction n'est pas stable. Des opérations inattendues peuvent entraîner l'échec de la tâche.

• Maximum 10 bases de données par tâche de migration de données. Dépasser cette limite peut causer des problèmes de stabilité et de performance.

Mode d'interrogation des instances CDC (logique)

• Exigence d'édition source pour les VM Azure : SQL Server 2008 ou version ultérieure (Enterprise Edition), ou SQL Server 2016 SP1 ou version ultérieure (Standard Edition). SQL Server 2017 n'est pas pris en charge.

• Autorisations de compte : Le compte d'accès DTS doit disposer de l'autorisation d'activer CDC au niveau de la base de données et de la table. CDC au niveau de la base de données nécessite un compte avec le rôle sysadmin. CDC au niveau de la table nécessite un compte privilégié.

  • Azure SQL Database : Un compte administrateur de serveur dispose des autorisations requises. CDC peut être activé pour toutes les bases de données achetées sous le modèle vCore. Pour le modèle DTU, les bases de données doivent avoir un niveau de service S3 ou supérieur.

  • Amazon RDS for SQL Server : Un compte privilégié dispose des autorisations requises. CDC peut être activé pour les procédures stockées au niveau de la base de données.

  • CDC ne peut pas être activé pour les index columnstore clusterisés.

  • Le pré-module DTS active CDC dans la base de données source. Ce processus provoque des verrouillages de table durant quelques secondes en raison des limitations de SQL Server.

• Maximum 1 000 tables par tâche. Dépasser cette limite peut provoquer des retards ou une instabilité.

• Maximum 10 bases de données par tâche de migration de données. Dépasser cette limite peut causer des problèmes de stabilité et de performance.

• Les tables sans contrainte PRIMARY KEY ou UNIQUE peuvent contenir des données dupliquées. Si vous devez conserver ces tables, n'utilisez pas cette solution.

• La migration incrémentielle des données présente une latence d'environ 10 secondes.

• N'ajoutez ni ne supprimez de colonnes via DDL plus de deux fois en une minute. Sinon, la tâche de migration de données peut échouer.

• Ne modifiez pas les instances CDC de la base de données source pendant la migration. Sinon, la tâche peut échouer ou des pertes de données peuvent survenir.

• La migration de plusieurs tables across plusieurs bases de données dans une seule tâche peut causer des problèmes de stabilité et de performance.

Migration SSMS

• Nécessite l'arrêt des écritures dans la base de données source avant la migration. Sinon, une incohérence des données peut survenir.

• Toutes les étapes de migration doivent être effectuées manuellement via SSMS.

SQL Server géré par l'utilisateur

Cette approche combine la rapidité de la sauvegarde physique avec la commodité de la console DTS, et prend en charge la migration de plusieurs bases de données dans une seule tâche. Migrer des données d'une base de données SQL Server gérée par l'utilisateur vers une instance ApsaraDB RDS for SQL Server à l'aide d'une passerelle physique.

Azure SQL Database

Ces deux options offrent des flux de travail guidés avec un minimum d'étapes manuelles. Migrer des données d'une base de données SQL Server sur Microsoft Azure vers ApsaraDB RDS for SQL Server.

Azure SQL Managed Instance et SQL Server sur Azure Virtual Machines

Amazon RDS for SQL Server

Migrer des données d'une instance Amazon RDS for SQL Server vers une instance ApsaraDB RDS for SQL Server.

Huawei Cloud RDS for SQL Server

Migrer les données de sauvegarde complète d'une instance SQL Server gérée par l'utilisateur vers une instance ApsaraDB RDS exécutant SQL Server 2008 R2 avec des disques cloud ou exécutant SQL Server 2012 ou version ultérieure.

Si la base de données source exécute SQL Server 2008 R2, mettez à niveau la version de la base de données avant d'effectuer cette opération. Pour obtenir des instructions sur la récupération des données de sauvegarde, consultez Creating a Manual Backup et Downloading a Backup File.

TencentDB for SQL Server

Avec prise en charge incrémentielle :

Migrer des données d'une base de données SQL Server gérée par l'utilisateur vers une instance ApsaraDB RDS for SQL Server.

Sans prise en charge incrémentielle : Utilisez la migration SSMS.

Google Cloud SQL for SQL Server

Migrer des données d'une base de données SQL Server gérée par l'utilisateur vers une instance ApsaraDB RDS for SQL Server.

Vérifier l'intégrité des données

Après la migration, vérifiez que toutes les données ont été correctement transférées vers l'instance de destination.

-- Source database
SELECT TOP 10 OrderID, OrderDate, CustomerID, TotalAmount
FROM Orders
ORDER BY OrderDate DESC;

-- Destination database
SELECT TOP 10 OrderID, OrderDate, CustomerID, TotalAmount
FROM Orders
ORDER BY OrderDate DESC;

Mettre à jour les statistiques de la base de données

Les performances des requêtes sur l'instance de destination peuvent diminuer en raison des changements dans la distribution des données. Mettez à jour toutes les statistiques dans les bases de données migrées pour restaurer les performances. Mettre à jour les statistiques de la base de données.