Partager via

Guide de migration : de SQL Server vers SQL Database

  • Article

S’applique à : SQL Server Base de données Azure SQL

Dans ce guide, vous allez apprendre à migrer votre instance SQL Server vers Azure SQL Database.

Passez en revue les conditions préalables et effectuez les phases de pré-migration avant de continuer.

Migrer

Une fois que vous avez terminé les étapes de la phase de pré-migration, vous êtes prêt à effectuer la migration des schémas et des données.

Migrez les données à l’aide de la méthode de migration de votre choix.

Effectuer une migration avec l’extension Azure SQL Migration pour Azure Data Studio

Pour effectuer une migration hors connexion en utilisant Azure Data Studio, suivez les étapes générales ci-dessous. Pour un tutoriel détaillé étape par étape, consultez Tutoriel : Migrer SQL Server vers Azure SQL Database (hors connexion).

  1. Téléchargez et installez Azure Data Studio et l’extension de migration Azure SQL.
  2. Lancez Migrer vers Azure SQL dans l’Assistant Migration Azure SQL de l’extension dans Azure Data Studio.
  3. Sélectionnez des bases de données pour évaluation, et consultez l’état de préparation ou les problèmes de la migration (le cas échéant). Collectez aussi des données de performances et obtenez une recommandation Azure pour une taille appropriée.
  4. Sélectionnez votre compte Azure et votre cible Azure SQL Database dans votre abonnement.
  5. Sélectionnez la liste des tables à migrer.
  6. Créez un service Azure Database Migration Service en utilisant l’Assistant dans Azure Data Studio. Si vous avez déjà créé un service Azure Database Migration Service en utilisant Azure Data Studio, vous pouvez réutiliser le même si vous le souhaitez.
  7. Facultatif : Si vos sauvegardes se trouvent sur un partage réseau local, téléchargez et installez le runtime d’intégration auto-hébergé sur une machine qui peut se connecter au serveur SQL Server source et à l’emplacement contenant les fichiers de sauvegarde.
  8. Démarrez la migration de la base de données et surveillez la progression dans Azure Data Studio. Vous pouvez aussi surveiller la progression sous la ressource Azure Database Migration Service dans le portail Azure.

Synchronisation des données et basculement

Quand vous utilisez des options de migration qui répliquent/synchronisent en permanence les changements apportés aux données de la source vers la cible, les données et le schéma sources peuvent varier et dériver par rapport à la cible. Pendant la synchronisation des données, vérifiez que tous les changements apportés à la source sont capturés et appliqués à la cible au cours du processus de migration.

Après avoir vérifié que les données sont identiques sur la source et la cible, vous pouvez effectuer le basculement de l’environnement source vers l’environnement cible. Il est important de planifier le processus de basculement avec les équipes métier/applicatives de façon à garantir que l’interruption minimale lors du basculement n’affecte pas la continuité de l’activité.

Important

Pour plus d’informations sur les étapes spécifiques associées à l’exécution d’un basculement dans le cadre des migrations à l’aide de DMS, consultez Tutoriel : Migrer SQL Server vers Azure SQL Database à l’aide de DMS (classique).

Migrer avec la réplication transactionnelle

Quand vous ne pouvez pas vous permettre de supprimer votre base de données SQL Server de la production durant la migration, vous pouvez utiliser la réplication transactionnelle SQL Server comme solution de migration. Pour que vous puissiez utiliser cette méthode, la base de données source doit remplir les conditions requises pour la réplication transactionnelle et être compatible avec Azure SQL Database. Pour plus d’informations sur la réplication SQL avec des groupes de disponibilité, consultez Configurer la réplication avec les groupes de disponibilité Always On.

Pour utiliser cette solution, vous devez configurer votre base de données dans Azure SQL Database en tant qu’abonné à l’instance SQL Server que vous souhaitez migrer. Le distributeur de réplication transactionnelle synchronise les données nécessaires de la base de données (l’éditeur), de nouvelles transactions continuant d’avoir lieu.

Avec la réplication transactionnelle, toutes les modifications apportées à vos données ou à votre schéma apparaissent dans votre base de données dans Azure SQL Database. Une fois la synchronisation terminée, lorsque vous êtes prêt à migrer, modifiez la chaîne de connexion de vos applications de façon à ce qu’elle pointe vers votre base de données. Quand la réplication transactionnelle a vidé toutes les modifications restant sur votre base de données source et que toutes vos applications pointent vers une base de données Azure SQL, vous pouvez désinstaller la réplication transactionnelle. Votre base de données dans Azure SQL Database est maintenant votre système de production.

Conseil

Vous pouvez également utiliser la réplication transactionnelle pour migrer un sous-ensemble de votre base de données source. La publication que vous répliquez sur Azure SQL Database peut être limitée à un sous-ensemble des tables dans la base de données en cours de réplication. Pour chaque table répliquée, vous pouvez limiter les données à un sous-ensemble de lignes et/ou un sous-ensemble de colonnes.

Workflow de réplication de transaction

Important

Utilisez la dernière version de SQL Server Management Studio pour rester synchronisé avec les mises à jour d’Azure et de SQL Database. Les versions antérieures de SQL Server Management Studio ne peuvent pas configurer SQL Database en tant qu’abonné. Obtenez la dernière version de SQL Server Management Studio.

Étape Méthode
Configurer la distribution SQL Server Management Studio | Transact-SQL
Créer une publication SQL Server Management Studio | Transact-SQL
Créer un abonnement SQL Server Management Studio | Transact-SQL

Quelques conseils et différences pour la migration vers SQL Database

  • Utilisez un distributeur local
    • Cela a un impact sur les performances du serveur.
    • Si l’impact sur les performances est inacceptable, vous pouvez utiliser un autre serveur, mais cela contribue à compliquer la gestion et l’administration.
  • Lorsque vous sélectionnez un dossier d’instantanés, assurez-vous qu’il est suffisamment grand pour contenir un BCP de chaque table que vous souhaitez répliquer.
  • La création d’instantanés verrouille les tables associées jusqu’à la fin de l’opération. Par conséquent, prenez soin de bien planifier votre instantané.
  • Seuls les abonnements par push sont pris en charge dans Azure SQL Database. Vous pouvez uniquement ajouter des abonnés à partir de la base de données source.

Recommandations en matière de migration

Pour accélérer la migration vers Azure SQL Database, vous devez prendre en compte les recommandations suivantes :

Contention de ressources Recommandation
Source (généralement en local) Le goulot d’étranglement principal durant la migration à partir de la source est dû aux E/S et à la latence du fichier de données, qui doivent être attentivement surveillées. En fonction des E/S et de la latence du fichier de données et selon qu’il s’agit d’une machine virtuelle ou d’un serveur physique, vous devrez peut-être faire appel à l’administrateur du stockage et explorer les options permettant d’atténuer le goulot d’étranglement.
Cible (Azure SQL Database) Le plus grand facteur limitant est le taux de génération de journaux et la latence de votre fichier journal de base de données. Avec Azure SQL Database, vous pouvez obtenir un taux de génération de journaux maximal de 96 Mo/s. Pour accélérer la migration, effectuez un scale-up de la base de données Azure SQL cible vers le niveau Critique pour l’entreprise Gen5 8 vCores pour obtenir le taux maximal de génération de journaux de 96 Mo/s et ainsi une faible latence pour les fichiers journaux. Le niveau de service Hyperscale fournit un taux de journalisation de 100 Mo/s quel que soit le niveau de service choisi.
Réseau La bande passante réseau nécessaire est égale au taux maximal d’ingestion des journaux de 96 Mo/s (768 Mo/s). En fonction de la connectivité réseau entre votre centre de données local et Azure, vérifiez que la bande passante réseau (en général Azure ExpressRoute) prend en charge le taux maximal d’ingestion des journaux.

Vous pouvez également tenir compte de ces recommandations pour optimiser les performances pendant le processus de migration.

  • Choisissez le niveau de service et la taille de calcul les plus élevés dans la limite de votre budget, afin d’optimiser les performances de transfert. Vous pourrez descendre en puissance une fois la migration terminée pour économiser de l’argent.
  • Si vous utilisez des fichiers BACPAC, réduisez la distance entre votre fichier BACPAC et le centre de données de destination.
  • Désactivez les statistiques de mise à jour automatique et de création automatique pendant la migration.
  • Tables et index de partition.
  • Supprimez les vues indexées et recréez-les quand la migration est terminée.
  • Déplacez les données historiques rarement interrogées vers une autre base de données et migrez ces données historiques vers un base de données distincte dans Azure SQL Database. Vous pourrez ensuite interroger ces données historiques à l’aide de requêtes élastiques.

Post-migration

Après avoir réussi la phase de migration, vous devez effectuer les tâches de postmigration suivantes pour vérifier que tout fonctionne de manière fluide et efficace.

La phase postmigration est cruciale pour résoudre les problèmes de justesse et d’exhaustivité des données ainsi que pour gérer les problèmes de performances liés à la charge de travail.

Mettre à jour les statistiques

Mettez à jour les statistiques avec une analyse complète une fois la migration terminée.

Corriger les applications

Une fois les données migrées vers l’environnement cible, toutes les applications qui consommaient la source doivent commencer à consommer la cible. Dans certains cas, cela vous oblige à apporter des changements aux applications.

Effectuer des tests

L’approche de test pour la migration de base de données comprend les activités suivantes :

  1. Développer des tests de validation : pour tester la migration d’une base de données, vous devez utiliser des requêtes SQL. Vous devez créer les requêtes de validation à exécuter sur les bases de données source et cible. Vos requêtes de validation doivent couvrir l’étendue que vous avez définie.
  2. Configurer un environnement de test: l’environnement de test doit contenir une copie de la base de données source et de la base de données cible. Veillez à isoler l’environnement de test.
  3. Exécuter des tests de validation : exécutez les tests de validation sur la source et sur la cible, puis analysez les résultats.
  4. Exécuter des tests de performances: exécutez un test de performances sur la source et sur la cible, puis analysez et comparez les résultats.

Utiliser des fonctionnalités avancées

Veillez à tirer parti des fonctionnalités cloud avancées offertes par SQL Database, notamment la haute disponibilité intégrée, la détection des menaces ainsi que la supervision et le paramétrage de votre charge de travail.

Certaines fonctionnalités SQL Server sont disponibles uniquement après le passage du niveau de compatibilité de la base de données au dernier niveau.

Pour en savoir plus, consultez Gestion d’Azure SQL Database après la migration.

Résoudre les problèmes de compatibilité de migration de la base de données

Vous pouvez rencontrer une grande variété de problèmes de compatibilité, selon la version de SQL Server dans la base de données source et la complexité de la base de données que vous êtes en train de migrer. Les versions antérieures de SQL Server ont plus de problèmes de compatibilité. Utilisez les ressources suivantes en plus d’une recherche Internet ciblée dans le moteur de recherche de votre choix :

Important

Azure SQL Managed Instance vous permet de migrer une instance existante et ses bases de données avec peu voire pas de problèmes de compatibilité. Consultez Qu’est-ce qu’Azure SQL Managed Instance ?

Contenu connexe