Partager via

Tutoriel : Migrer SQL Server vers Azure SQL Database (hors connexion)

Vous pouvez utiliser Azure Database Migration Service via le portail Azure pour migrer des bases de données d’une instance locale de SQL Server vers Azure SQL Database (hors connexion).

Dans ce tutoriel, découvrez comment migrer l’exemple AdventureWorks2022 de base de données d’une instance locale de SQL Server vers Azure SQL Database à l’aide de Database Migration Service. Ce tutoriel se concentre sur le mode de migration hors connexion, qui prend en compte un temps d’arrêt acceptable durant le processus de migration.

Dans ce tutoriel, vous allez apprendre à :

  • Créer une instance Azure Database Migration Service
  • Démarrer votre migration et suivre sa progression jusqu’à son achèvement

Importante

Actuellement, les migrations en ligne pour les cibles Azure SQL Database ne sont pas disponibles avec Azure Database Migration Service. Lors d’une migration hors connexion, le temps d’arrêt de l’application commence quand la migration commence. Le test d’une migration hors connexion est recommandé pour déterminer si le temps d’arrêt est acceptable.

Options de migration

La section suivante explique comment utiliser Azure Database Migration Service avec le portail Azure.

Prérequis

Avant de commencer le tutoriel :

  • Vérifiez que vous pouvez accéder au portail Azure.

  • Assurez-vous que le fournisseur de ressources Microsoft.DataMigration est inscrit dans votre abonnement.

  • Disposer d’un compte Azure affecté à l’un des rôles intégrés suivants :

    • Contributeur pour la base de données Azure SQL cible
    • Rôle lecteur pour le groupe de ressources Azure qui contient la base de données Azure SQL cible
    • Rôle propriétaire ou contributeur pour l’abonnement Azure (requis si vous créez une instance Azure Database Migration Service)

    En guise d’alternative à l’utilisation de l’un de ces rôles intégrés, vous pouvez attribuer un rôle personnalisé.

  • Créez une Azure SQL Database cible.

  • Assurez-vous que le compte de connexion SQL Server qui se connecte à l’instance SQL Server source est membre du rôle db_datareader et que le compte de connexion de l’instance SQL Server cible est membre du rôle db_owner.

  • Pour migrer le schéma de base de données de la source vers azure SQL Database cible à l’aide de Database Migration Service, la version minimale prise en charge de SHIR est 5.37 ou ultérieure.

  • Pour la migration de schéma, les autorisations minimales sur le serveur SQL Server source sont db_owner pour accéder à la base de données et sur la base de données Azure SQL cible, l’utilisateur doit être membre de tous les rôles au niveau du serveur dans le tableau suivant :

Rôles Descriptif
##MS_DatabaseManager## Les membres du rôle serveur fixe ##MS_DatabaseManager## peuvent créer et supprimer des bases de données. Membre du rôle ##MS_DatabaseManager## qui crée une base de données devient le propriétaire de cette base de données, ce qui permet à cet utilisateur de se connecter à cette base de données en tant qu’utilisateur dbo. L'utilisateur dbo possède toutes les autorisations sur la base de données. Les membres du rôle ##MS_DatabaseManager## n’ont pas nécessairement l’autorisation d’accéder aux bases de données qu’ils ne possèdent pas. Il est recommandé d’utiliser ce rôle serveur sur le rôle de niveau base de données dbmanager qui existe dans la master base de données.
##MS_DatabaseConnector## Les membres du rôle serveur fixe ##MS_DatabaseConnector## peuvent se connecter à n’importe quelle base de données sans nécessiter de compte d’utilisateur dans la base de données pour se connecter.
##MS_DefinitionReader## Les membres du rôle serveur fixe ##MS_DefinitionReader## peuvent lire toutes les vues de catalogue couvertes par VIEW ANY DEFINITION n’importe quelle base de données sur laquelle le membre de ce rôle a un compte d’utilisateur.
##MS_LoginManager## Les membres du rôle serveur fixe ##MS_LoginManager## peuvent créer et supprimer des connexions. Il est recommandé d’utiliser ce rôle serveur sur le rôle de niveau base de données loginmanager qui existe dans la master base de données.

Préparer la base de données Azure SQL cible

Pour créer la connexion et l’utilisateur sur la base de données Azure SQL Database cible, exécutez le script suivant sur la master base de données :

CREATE LOGIN testuser WITH PASSWORD = '<password>';

ALTER SERVER ROLE ##MS_DefinitionReader## ADD MEMBER [testuser];
GO

ALTER SERVER ROLE ##MS_DatabaseConnector## ADD MEMBER [testuser];
GO

ALTER SERVER ROLE ##MS_DatabaseManager## ADD MEMBER [testuser];
GO

ALTER SERVER ROLE ##MS_LoginManager## ADD MEMBER [testuser];
GO

CREATE USER testuser FOR LOGIN testuser;
EXECUTE sp_addRoleMember 'dbmanager', 'testuser';
EXECUTE sp_addRoleMember 'loginmanager', 'testuser';

À présent, vous pouvez migrer le schéma de base de données et les données à l’aide de Database Migration Service. Vous pouvez également utiliser d’autres outils tels que l’extension Projets SQL Database dans Visual Studio Code pour migrer le schéma avant de sélectionner la liste des tables à migrer.

Remarque

Si aucune table n’existe sur la cible Azure SQL Database ou qu’aucune table n’est sélectionnée avant de démarrer la migration, le bouton Suivant n’est pas disponible pour lancer la migration. Si aucune table n’existe sur la cible, vous devez sélectionner l’option de migration de schéma pour avancer.

Créer une instance de Database Migration Service

Étape 1 : Sur le portail Azure, accédez à la page Azure Database Migration Service. Créez une instance d’Azure Database Migration Service ou réutilisez une instance existante que vous avez créée précédemment.

Utiliser une instance existante de Database Migration Service

Pour utiliser une instance existante de Database Migration Service :

  • Sur le portail Azure, sous Azure Database Migration Services, sélectionnez une instance existante de Database Migration Service que vous souhaitez utiliser, en vous assurant qu’elle est présente dans le groupe de ressources et la région appropriés.

    Capture d’écran montrant la vue d’ensemble de Database Migration Service.

Créer une instance de Database Migration Service

Pour créer une instance de Database Migration Service :

  1. Sur le portail Azure, sous Azure Database Migration Service, sélectionnez Créer.

    Capture d’écran montrant l’option de création de Database Migration Service.

  2. Dans Sélectionner le scénario de migration et Database Migration Service, sélectionnez l’entrée souhaitée, comme le type de serveur source et cible, choisissez Database Migration Service, puis Sélectionner.

    Capture d’écran montrant les scénarios de migration de Database Migration Service.

  3. Dans l’écran suivant, Créer une instance de Data Migration Service, sélectionnez votre abonnement et votre groupe de ressources, puis sélectionnez Emplacement et entrez le nom de l’instance de Database Migration Service. Sélectionnez Vérifier + créer. Ce processus permet de créer l’instance d’Azure Database Migration Service.

    Capture d’écran montrant les détails de l’entrée requis par le Database Migration Service.

  4. Si le runtime d’intégration auto-hébergé (SHIR) est requis, dans la page de vue d’ensemble de votre instance Database Migration Service, sous Paramètres, sélectionnez Runtime d’intégration et effectuez les étapes suivantes :

    1. Sélectionnez Configurer le runtime d'intégration et choisissez le lien Télécharger et installer le runtime d’intégration pour ouvrir le lien de téléchargement dans un navigateur web. Téléchargez le runtime d’intégration, puis installez-le sur un ordinateur qui remplit les conditions préalables pour se connecter à l’instance SQL Server source. Pour plus d’informations, consultez runtime d’intégration auto-hébergé pour les migrations de base de données.

      Capture d’écran montrant le lien Télécharger et installer le runtime d’intégration.

      Une fois l’installation effectuée, le Gestionnaire de configuration de Microsoft Integration Runtime s’ouvre automatiquement pour débuter le processus d’inscription.

    2. Dans le tableau Clé d’authentification, copiez l’une des clés d’authentification fournies dans l’Assistant et collez-la dans Microsoft Integration Runtime Configuration Manager.

      Capture d’écran mettant en évidence la table de clés d’authentification dans l’Assistant.

      Si la clé d’authentification est valide, une icône de contrôle verte apparaît dans le Gestionnaire de configuration Integration Runtime. Un indicateur vert signifie que vous pouvez vous Inscrire.

      Après avoir enregistré le runtime d’intégration auto-hébergé, fermez Microsoft Integration Runtime Configuration Manager. La prise en compte des détails du nœud sur le portail Azure pour le Database Migration Service peut prendre plusieurs minutes, dans Paramètres > Environnement d'intégration.

      Capture d’écran mettant en évidence le statut SHIR sur le portail Azure.

      Remarque

      Pour plus d’informations sur le runtime d’intégration auto-hébergé, consultez Créer et configurer un runtime d’intégration auto-hébergé.

Lancement d’une nouvelle migration

  1. Pour démarrer une nouvelle migration, accédez à Azure Database Migration Service dans le portail Azure, puis utilisez +Créer pour créer une instance de Database Migration Service, ou sélectionnez une instance existante, puis accédez à votre instance Azure Database Migration Service.

  2. Dans le volet Vue d’ensemble de votre instance Azure Database Migration Service, sélectionnez Nouvelle migration :

    Capture d’écran du tableau de bord de migration de base de données Azure.

  3. Sous le scénario Sélectionner une nouvelle migration, choisissez votre type de serveur source, cible, le mode de migration, puis Sélectionner.

    Capture d’écran de la sélection d’un nouveau scénario de migration.

  4. Dans l’Assistant Migration hors connexion d’Azure SQL Database, procédez comme suit :

    1. Sous l’onglet Détails de la source, entrez les détails de l’instance SQL Server source, puis sélectionnez Suivant : Se connecter à sql Server source :

      Capture d’écran du suivi des sources.

    2. Sous l’onglet Se connecter à sql Server source, fournissez les détails de connexion, puis sélectionnez Suivant : Sélectionner des bases de données pour la migration :

      Capture d’écran de Connexion à la source.

    3. Sous l’onglet Sélectionner des bases de données pour la migration , cochez la case en regard des bases de données que vous souhaitez migrer. Le remplissage de la liste des bases de données peut prendre un certain temps. Sélectionnez Suivant : Se connecter à Azure SQL Database Cible.

      Capture d’écran de la base de données sélectionnée.

    4. Sous l’onglet Se connecter à la base de données Azure SQL Database cible , fournissez les détails de connexion, puis sélectionnez Suivant : Mapper les bases de données sources et cibles :

      Capture d’écran de la cible de connexion.

    5. Sous l’onglet Mapper les bases de données source et cible , mappez les bases de données entre la source et la cible.

      Capture d’écran des bases de données mappées.

    6. (Facultatif) Cochez la case en regard de Migrer le schéma manquant pour déployer des objets de schéma manquants de la source vers la cible Azure SQL Database pour migrer les objets de schéma suivants avec une case à cocher unique :

      • Schémas
      • Tables (sélectionnées)
      • Index
      • Points de vue
      • Procédures stockées (StoredProcedures)
      • Synonymes
      • Déclencheurs DDL (DdlTriggers)
      • Valeurs par défaut
      • Catalogues de texte intégral (FullTextCatalogs)
      • Repères de plan (PlanGuides)
      • Rôles
      • Règles
      • Rôles d’application (ApplicationRoles)
      • Agrégats définis par l’utilisateur (UserDefinedAggregates)
      • Types de données définis par l’utilisateur (UserDefinedDataTypes)
      • Fonctions définies par l’utilisateur (UserDefinedFunctions)
      • Types de tables définis par l’utilisateur (UserDefinedTableTypes)
      • Types définis par l’utilisateur (UserDefinedTypes)
      • Utilisateurs* (pas tous les types d’utilisateurs)
      • Collections de schémas XML

      Remarque

      • Si vous sélectionnez Migrer le schéma manquant, le service Migration de base de données effectue la migration du schéma avant la migration des données.
      • DMS poursuit la phase de migration des données même si la migration de schéma rencontre des erreurs, sauf s’il existe des problèmes avec les objets de table.

      Ensuite, utilisez Sélectionner toutes les tables pour migrer toutes les tables, ou utilisez la zone d’entrée de texte pour filtrer la liste des tables et sélectionner des tables individuelles à migrer. Ensuite, sélectionnez Suivant : Résumé de la migration de base de données.

      Capture d’écran de la sélection du schéma et des tables.

    7. Sous l’onglet Résumé de la migration de base de données , passez en revue les détails, puis sélectionnez Démarrer la migration, qui démarre la migration de base de données et vous ramène automatiquement au tableau de bord Database Migration Service.

      Capture d’écran du résumé.

      Remarque

      Pour une migration hors connexion, le temps d’arrêt de l’application démarre au démarrage de la migration.

Surveiller la migration de base de données

  1. Pour surveiller votre migration de base de données, dans le volet Vue d’ensemble de votre instance Database Migration Service, sélectionnez Surveiller les migrations.

    Capture d’écran de la vue d’ensemble d’Azure Database Migration Service dans le portail Azure.

  2. Sous l’onglet Migrations, vous pouvez suivre les migrations en cours, terminées et ayant échoué (le cas échéant), ou vous pouvez afficher toutes les migrations de base de données. Dans la barre de menus, sélectionnez Actualiser pour mettre à jour l’état de la migration.

    Capture d’écran de la surveillance du tableau de bord DMS.

    Database Migration Service retourne l’état de migration connu le plus récent à chaque actualisation de l’état de la migration. Le tableau suivant décrit les états possibles :

    Statut Descriptif
    Créer Le service démarre la migration.
    Préparation de la copie Le service désactive les autostats, les déclencheurs et les index dans la table cible.
    Copie Les données sont copiées de la base de données source vers la base de données cible.
    Copie terminée La copie des données est terminée. Le service attend que d’autres tables terminent la copie pour commencer les dernières étapes pour retourner les tables à leur schéma d’origine.
    Regénération des index Le service régénère les index sur les tables cibles.
    Réussi Toutes les données sont copiées et les index sont reconstruits.

  3. Sous Nom de la source, sélectionnez un nom de base de données pour ouvrir la vue table. Dans cette vue détaillée, vous voyez l’état actuel de la migration, le nombre de tables qui se trouvent actuellement dans cet état et un état détaillé de chaque table :

    Capture d’écran de la surveillance détaillée de la migration.

  4. Une fois que toutes les données de table sont migrées vers la cible Azure SQL Database, Database Migration Service passe l’état de la migration de En cours à Réussi.

    Capture d’écran de la réussite de la migration détaillée.

Remarque

Database Migration Service optimise la migration en ignorant les tables sans données (0 lignes). Les tables qui n’ont pas de données n’apparaissent pas dans la liste, même si vous avez sélectionné les tables lors de la création de la migration.

Vous avez effectué la migration vers Azure SQL Database. Passez par une série de tâches post-migration pour vous assurer que tout fonctionne correctement et efficacement.

Limites

La migration hors connexion Azure SQL Database utilise des pipelines ADF (Azure Data Factory) pour le déplacement des données, et respecte donc les limitations ADF. Un ADF correspondant est créé lorsqu’un service de migration de base de données est également créé. Ainsi, les limites d’usine s’appliquent par service.

  • La machine sur laquelle le SHIR est installé sert de calcul pour la migration. Assurez-vous que cette machine peut gérer la charge du processeur et de la mémoire de la copie de données. Pour en savoir plus, consultez Créer et configurer un runtime d’intégration auto-hébergé.
  • Limite de 100 000 tables par base de données.
  • 10 000 migrations de base de données simultanées par service.
  • La vitesse de migration dépend fortement de la référence SKU Azure SQL Database cible et de l’hôte de runtime d’intégration auto-hébergé.
  • La migration Azure SQL Database évolue mal avec le nombre de tables en raison de la surcharge ADF lors du démarrage des activités. Si une base de données contient des milliers de tables, le processus de démarrage de chaque table peut prendre plusieurs secondes, même si elles sont composées d’une ligne avec un bit de données.
  • Les noms des tables Azure SQL Database avec des caractères codés sur deux octets ne sont actuellement pas pris en charge pour la migration. L’atténuation consiste à renommer les tables avant la migration ; leur nom d’origine pourra être rétabli après une migration réussie.
  • La migration des tables dotées de grandes colonnes BLOB peut échouer en raison d’un délai d’expiration.
  • Les noms de base de données avec SQL Server réservés ne sont actuellement pas pris en charge.
  • Les noms de base de données qui incluent des points-virgules ne sont actuellement pas pris en charge.
  • Les colonnes calculées ne sont pas migrées.
  • Les colonnes de la base de données source qui ont des contraintes par défaut et contiennent des NULL valeurs, sont migrées avec leurs valeurs par défaut définies sur la base de données Azure SQL cible, plutôt que de conserver les VALEURS NULL.

Contenu connexe

  • Last updated on