Partager via

Tutoriel : Migrer SQL Server vers SQL Server sur une machine virtuelle Azure avec Azure DMS (hors connexion)

Vous pouvez utiliser Azure Database Migration Service (Azure DMS) via le portail Azure pour migrer des bases de données d’une instance locale de SQL Server vers Qu’est-ce que SQL Server sur les machines virtuelles Azure Windows ? (machine virtuelle Azure) avec un temps d’arrêt minimal.

Pour connaître les méthodes de migration de base de données qui peuvent nécessiter une configuration manuelle, consultez Migration d’une instance de SQL Server vers SQL Server sur les machines virtuelles Azure.

Dans ce tutoriel, vous migrez la AdventureWorks2025 base de données d’une instance locale de SQL Server vers un serveur SQL Server sur une machine virtuelle Azure avec un temps d’arrêt minimal, à l’aide d’Azure DMS.

Note

Ce tutoriel utilise le mode de migration hors connexion, qui inclut un temps d’arrêt acceptable pendant le processus de migration. Pour obtenir des options de migration en ligne, consultez Tutoriel : Migrer SQL Server vers SQL Server sur une machine virtuelle Azure avec Azure DMS (en ligne).

Dans ce tutoriel, vous allez apprendre à :

  • Lancez l’Assistant Migrer vers Azure SQL dans le portail Azure.
  • Spécifiez les détails de votre serveur SQL Server source, de l’emplacement de sauvegarde et de votre serveur SQL Server cible sur une machine virtuelle Azure.
  • Configurez l’Assistant pour accéder au serveur source et aux sauvegardes.
  • Démarrer et superviser la progression de votre migration.
  • Effectuer le basculement de la migration lorsque vous êtes prêt.

Options de migration

La section suivante explique comment utiliser Azure Database Migration Service avec l’extension de migration Azure SQL ou dans le portail Azure.

Prerequisites

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 l’instance cible de SQL Server sur une machine virtuelle Azure et pour le compte de stockage où vous chargez vos fichiers de sauvegarde de base de données à partir d’un partage réseau SMB (Server Message Block).

    • Rôle lecteur pour le groupe de ressources Azure qui contient l’instance cible de SQL Server sur une machine virtuelle Azure ou pour votre compte de stockage Azure.

    • Rôle Propriétaire ou Contributeur pour l’abonnement Azure.

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

    Lorsque vous utilisez le portail Azure pour migrer, l’utilisateur connecté doit disposer d’un accès lecteur de données blob de stockage sur le conteneur d’objets blob qui contient les fichiers de sauvegarde, pour pouvoir répertorier les fichiers et dossiers pendant la configuration de la migration.

  • Créer une instance cible de SQL Server sur les machines virtuelles Azure.

    Si vous disposez d’une machine virtuelle Azure existante, inscrivez-la auprès de l’extension SQL Server IaaS Agent en mode de gestion complète.

  • Vérifiez que les connexions que vous utilisez pour vous connecter à l’instance SQL Server source sont membres du rôle serveur sysadmin, ou disposent de l’autorisation CONTROL SERVER.

  • Fournissez un partage réseau SMB, un partage de fichiers de compte de stockage Azure ou un conteneur de blobs de compte de stockage Azure contenant vos fichiers de sauvegarde complète de la base de données et les fichiers de sauvegarde de journal des transactions justificatifs. Azure DMS utilise l’emplacement de sauvegarde pendant la migration de base de données.

    • Utilisez toujours un compte de stockage dédié pour la migration. Le partage avec d’autres charges de travail peut entraîner des conflits et des risques de sécurité.

    • Une fois la migration effectuée, faites pivoter la clé de compte de stockage pour sécuriser les sauvegardes ou supprimez le compte de stockage s’il n’est plus nécessaire.

    • Azure DMS ne prend pas de sauvegardes de base de données et ne lance aucune sauvegarde de base de données en votre nom. Au lieu de cela, le service utilise des fichiers de sauvegarde de base de données existants pour la migration.

    • Si vos fichiers de sauvegarde de base de données se trouvent dans un partage réseau SMB, créez un compte de stockage Azure qui permet à Azure DMS de charger les fichiers de sauvegarde de base de données et de migrer des bases de données. Veillez à créer le compte stockage Azure dans la même région que celle où vous créez votre instance d’Azure DMS.

    • Vous pouvez écrire chaque sauvegarde dans un fichier de sauvegarde distinct ou dans plusieurs fichiers de sauvegarde. L’ajout de plusieurs sauvegardes, comme des journaux de transaction et complets à un seul support de sauvegarde n’est pas pris en charge.

    • Vous pouvez fournir des sauvegardes compressées pour réduire le risque de rencontrer des problèmes de migration de sauvegardes volumineuses.

  • Assurez-vous que le compte de service exécutant l’instance source SQL Server dispose des autorisations en lecture et en écriture sur le partage réseau SMB qui contient les fichiers de sauvegarde de base de données.

  • Si vous migrez une base de données protégée par le chiffrement transparent des données (TDE), migrez le certificat de l’instance SQL Server source vers SQL Server sur une machine virtuelle Azure avant de migrer des données. Pour plus d’informations, consultez Déplacer une base de données protégée par TDE vers un autre serveur SQL Server.

    Conseil / Astuce

    Si votre base de données contient des données sensibles protégées par Always Encrypted, le processus de migration migre automatiquement vos clés Always Encrypted vers votre instance cible de SQL Server sur une machine virtuelle Azure.

  • Si vos sauvegardes de base de données se trouvent dans un partage de fichiers réseau, fournissez un ordinateur sur lequel installer l’IR auto-hébergé pour accéder et migrer les sauvegardes de base de données. L’Assistant Migration vous fournit le lien de téléchargement et les clés d’authentification pour télécharger et installer votre IR auto-hébergé.

    En prévision de la migration, vérifiez que les règles de pare-feu sortantes et les noms de domaine suivants sont activés sur l’ordinateur où vous installez le runtime d’intégration autohébergé :

    Noms de domaine Port sortant Descriptif
    Cloud public : {datafactory}.{region}.datafactory.azure.net
    ou*.frontend.clouddatahub.net

    Azure Government : {datafactory}.{region}.datafactory.azure.us
    Microsoft Azure géré par 21Vianet : {datafactory}.{region}.datafactory.azure.cn    		 443 Requis par le runtime d’intégration auto-hébergé pour se connecter à Azure DMS.
    Pour une fabrique de données nouvellement créée dans un cloud public, recherchez le nom de domaine complet (FQDN) de votre clé de runtime d’intégration auto-hébergée, au format {datafactory}.{region}.datafactory.azure.net.
    Pour une fabrique de données existante, si vous ne voyez pas le nom de domaine complet dans votre clé d’intégration auto-hébergée, utilisez *.frontend.clouddatahub.net à la place.
    download.microsoft.com 443 Exigé par le runtime d’intégration auto-hébergé pour télécharger les mises à jour. Si vous désactivez la mise à jour automatique, vous pouvez ignorer la configuration de ce domaine.
    *.core.windows.net 443 Utilisé par le runtime d’intégration auto-hébergé qui se connecte au compte stockage Azure pour charger des sauvegardes de base de données à partir de votre partage réseau

    Conseil / Astuce

    Si vous stockez déjà vos fichiers de sauvegarde de base de données dans un compte de stockage Azure, vous n’avez pas besoin d’un runtime d’intégration auto-hébergé pendant le processus de migration.

  • Lorsque vous utilisez l’IR auto-hébergé, assurez-vous que l’ordinateur sur lequel le runtime est installé peut se connecter à l’instance SQL Server et au partage de fichiers réseau source où se trouvent les fichiers de sauvegarde.

  • Activez le port de sortie 445 pour autoriser l’accès au partage de fichiers réseau. Pour plus d’informations, consultez Recommandations relatives à l’utilisation d’un runtime d’intégration auto-hébergé.

  • Si vous utilisez Azure DMS pour la première fois, vérifiez que le Microsoft.DataMigrationfournisseur de ressources est inscrit dans votre abonnement.

Démarrer une nouvelle migration

Ce tutoriel décrit une migration hors connexion de SQL Server vers SQL Server sur une machine virtuelle Azure.

Pour démarrer une nouvelle migration :

  1. Accédez à Azure Database Migration Service dans le portail Azure. Utilisez +Créer pour créer une instance de Database Migration Service ou sélectionnez une instance existante. Ensuite, accédez à votre instance Database Migration Service.

  2. Dans le volet Vue d’ensemble de votre instance Azure DMS, sélectionnez Nouvelle migration.

  3. Sous Sélectionner un nouveau scénario de migration, choisissez votre source, le type de serveur cible, l’emplacement de stockage de fichiers de sauvegarde, le mode de migration en tant que migration hors connexion, puis sélectionnez Sélectionner.

    Vos sauvegardes de base de données peuvent être situées soit sur un partage réseau local, soit dans un conteneur d'objets blob Azure Storage.

    Capture d’écran du nouveau scénario de migration.

    En mode de migration hors connexion, la base de données SQL Server source ne doit pas être utilisée pour l’activité d’écriture alors que les fichiers de sauvegarde de base de données sont restaurés sur l’instance cible de SQL Server sur une machine virtuelle Azure. Le temps d’arrêt de l’application persiste du début du processus de migration jusqu’à ce qu’il soit terminé.

  4. Dans l’Assistant Migration Azure SQL Virtual Machine Online Blob, 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.

    2. Sous l’onglet Sélectionner la cible de migration , entrez les détails de l’abonnement, du groupe de ressources et de la machine virtuelle SQL Server cible. Sélectionnez Ensuite Suivant : Configuration de la source de données.

      Capture d’écran de l’Assistant de migration de blob hors connexion.

      • Utilisez toujours un compte de stockage dédié pour la migration. Le partage avec d’autres charges de travail peut entraîner des conflits et des risques de sécurité.

      • Une fois la migration effectuée, faites pivoter la clé de compte de stockage pour sécuriser les sauvegardes ou supprimez le compte de stockage s’il n’est plus nécessaire.

      • Azure DMS ne prend pas de sauvegardes de base de données et ne lance aucune sauvegarde de base de données en votre nom. Au lieu de cela, le service utilise des fichiers de sauvegarde de base de données existants pour la migration.

      • Si vos fichiers de sauvegarde de base de données se trouvent dans un partage réseau SMB, créez un compte de stockage Azure qui permet à Azure DMS de charger les fichiers de sauvegarde de base de données et de migrer des bases de données. Veillez à créer le compte stockage Azure dans la même région que celle où vous créez votre instance d’Azure DMS.

      • Vous pouvez écrire chaque sauvegarde dans un fichier de sauvegarde distinct ou dans plusieurs fichiers de sauvegarde. L’ajout de plusieurs sauvegardes, comme des journaux de transaction et complets à un seul support de sauvegarde n’est pas pris en charge.

      • Vous pouvez fournir des sauvegardes compressées pour réduire le risque de rencontrer des problèmes de migration de sauvegardes volumineuses.

    3. À l’étape de configuration de la source de données , sélectionnez l’emplacement de vos sauvegardes de base de données. Vos sauvegardes de base de données peuvent être situées sur un partage réseau local ou dans un conteneur de blobs dans Azure Storage.

      Si vous fournissez vos sauvegardes de base de données dans un partage réseau local, configurez un runtime d'intégration auto-hébergé à l'étape suivante de l'assistant. Vous avez besoin d’un runtime d’intégration auto-hébergé pour accéder à vos sauvegardes de base de données source, vérifier la validité du jeu de sauvegarde et charger des sauvegardes sur le compte de stockage Azure. Si vos sauvegardes de base de données se trouvent déjà dans un conteneur de blobs de stockage Azure, vous n'avez pas besoin d'un système d'intégration auto-hébergé.

      • Pour les sauvegardes stockées dans un conteneur d’objets blob Azure Storage, entrez ou sélectionnez les informations suivantes :

        Nom Descriptif
        Groupe de ressources Groupe de ressources où se trouvent les fichiers de sauvegarde.
        Détails du compte de stockage Compte de stockage où se trouvent les fichiers de sauvegarde.
        Conteneur d’objets blob Conteneur d’objets blob où se trouvent les fichiers de sauvegarde.
        Folder Dossier où se trouvent les fichiers de sauvegarde.
        Dernier fichier de sauvegarde Nom de fichier de la dernière sauvegarde de la base de données que vous migrez.
        Nom de la base de données cible Vous pouvez modifier le nom de la base de données cible pendant le processus de migration.

        Si la fonctionnalité de vérification de boucle locale est activée et que le serveur SQL Server source et le partage de fichiers se trouvent sur le même ordinateur, la source ne peut pas accéder au partage de fichiers avec le FQDN. Pour résoudre ce problème, désactivez la fonctionnalité du contrôle de bouclage.

        Capture d’écran de la configuration de la source de données de l’Assistant de Migration BLOB hors connexion.

      • Pour les sauvegardes situées sur un partage réseau, entrez les informations supplémentaires suivantes sur les pages respectives.

        Nom Descriptif
        Nom du serveur source Nom de domaine complet (FQDN) ou adresse IP du serveur source. Vérifiez que le compte de service exécutant l’instance SQL Server source dispose de privilèges de lecture sur le partage réseau.
        Type d’authentification Sélectionnez le type d’authentification : SQL ou Windows
        Informations d’identification de la source - Nom d’utilisateur Informations d’identification (authentification Windows et SQL) permettant de se connecter à l’instance source de SQL Server et de valider les fichiers de sauvegarde.
        Informations d’identification de la source - Mot de passe utilisateur Informations d’identification (authentification Windows et SQL) permettant de se connecter à l’instance source de SQL Server et de valider les fichiers de sauvegarde.
        Emplacement de partage réseau qui contient les sauvegardes Emplacement de partage réseau qui contient les fichiers de sauvegarde complète et de sauvegarde des journaux de transactions. Le processus de migration ignore automatiquement les fichiers non valides ou les fichiers de sauvegarde dans le partage réseau qui n’appartiennent pas au jeu de sauvegarde valide.
        Compte d’utilisateur Windows avec accès en lecture à l’emplacement du partage réseau Informations d’identification Windows (nom d’utilisateur) du compte ayant accès en lecture au partage réseau pour récupérer les fichiers de sauvegarde.
        Mot de passe Informations d’identification Windows (Mot de passe) du compte ayant accès en lecture au partage réseau pour récupérer les fichiers de sauvegarde.
        Nom de la base de données cible Vous pouvez modifier le nom de la base de données cible pendant le processus de migration.

Scénarios de stockage de sauvegarde

L’extension de migration Azure SQL pour Azure Data Studio ne nécessite pas de configurations spécifiques sur les paramètres réseau de votre compte stockage Azure pour migrer vos bases de données SQL Server vers Azure.

Assurez-vous que vos ressources peuvent accéder au compte stockage Azure. Selon l’emplacement de sauvegarde de votre base de données et les paramètres réseau de compte de stockage souhaités, reportez-vous au tableau suivant pour connaître les différents scénarios de migration et configurations réseau :

Scénario Partage réseau SMB Conteneur de compte Stockage Azure
Activé à partir de tous les réseaux Aucune étape supplémentaire Aucune étape supplémentaire
Activé à partir de réseaux virtuels et d’adresses IP sélectionnés Runtime d'intégration sur site auto-hébergé (SHIR) Sauvegardes stockées dans le conteneur stockage Azure
Activé à partir de réseaux virtuels et d’adresses IP sélectionnés + point de terminaison privé Runtime d’intégration auto-hébergé de machine virtuelle Azure (SHIR) Sauvegardes stockées dans le conteneur stockage Azure (point de terminaison privé)

Runtime d'intégration sur site auto-hébergé (SHIR)

Si vous installez votre SHIR sur votre réseau local, procédez comme suit :

  1. Connectez-vous au portail Azure à partir de la machine SHIR.

  2. Ouvrez votre compte stockage Azure, puis accédez au volet Mise en réseau .

  3. Vérifiez que l’accès au réseau public est activé à partir de réseaux virtuels et d’adresses IP sélectionnés.

  4. Dans la section Pare-feu , cochez la case Ajouter votre adresse IP cliente .

  5. Entrez l’adresse IP du client de l’ordinateur hôte, puis sélectionnez Enregistrer.

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 Recommandations sur le SHIR.

      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. Une coche verte indique 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 Database Migration Service peut prendre plusieurs minutes, sous Paramètres > Runtime d'intégration.

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

      Note

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

Démarrer la migration de base de données

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. Le service démarre la migration de base de données et vous ramène automatiquement au tableau de bord Azure DMS.

Capture d’écran du résumé de la migration des données de l’Assistant de migration hors ligne d’objets blob.

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 DMS, sélectionnez Surveiller les migrations.

  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 de la migration.

Azure DMS retourne le dernier état de migration connu chaque fois que l’état de la migration est actualisé. Le tableau suivant décrit les états possibles :

Statut Descriptif
Arrivé Le fichier de sauvegarde est arrivé à l’emplacement de sauvegarde de la source et a été validé.
Chargement Le runtime d’intégration charge le fichier de sauvegarde vers le service Stockage Azure.
Chargé Le fichier de sauvegarde a été chargé dans le stockage Azure.
Restauration Le service restaure le fichier de sauvegarde sur SQL Server sur une machine virtuelle Azure.
Restauré Le fichier de sauvegarde a été restauré avec succès sur SQL Server sur une machine virtuelle Azure.
Annulé Le processus de migration a été annulé.
Ignoré Le fichier de sauvegarde a été ignoré, car il n’appartient à aucune chaîne de sauvegarde de base de données valide.

Une fois toutes les sauvegardes de base de données restaurées sur l’instance de SQL Server sur une machine virtuelle Azure, Azure DMS lance un basculement de migration automatique pour s’assurer que la base de données migrée est prête à être utilisée. L’état de la migration passe de En cours à Réussi.

Limites

Si vous migrez une base de données unique, vous devez placer les sauvegardes de base de données dans une structure de fichiers plats à l’intérieur d’un dossier de base de données (y compris le dossier racine du conteneur). Vous ne pouvez pas imbriquer ces dossiers, car l’imbrication n’est pas prise en charge.

Si vous migrez plusieurs bases de données à l’aide du même conteneur de Stockage Blob Azure, vous devez placer les fichiers de sauvegarde de différentes bases dans des dossiers distincts dans le conteneur.

Vous ne pouvez pas remplacer les bases de données existantes dans votre serveur SQL Server cible sur une machine virtuelle Azure à l’aide de DMS.

Azure DMS ne prend pas en charge la configuration de la haute disponibilité et de la récupération d’urgence sur votre cible pour qu’elle corresponde à la topologie source.

Les objets serveur suivants ne sont pas pris en charge :

  • travaux de l'Agent SQL Server
  • Credentials
  • Packages des Services d'Intégration SQL Server (SSIS)
  • Audit de serveur

Vous ne pouvez pas utiliser un runtime d’intégration auto-hébergé existant créé à partir d’Azure Data Factory (ADF) pour les migrations de base de données avec DMS. Au départ, vous devez créer le runtime d’intégration auto-hébergé à l’aide de l’extension de migration Azure SQL dans Azure Data Studio. Vous pouvez la réutiliser pour d’autres migrations de base de données.

Les machines virtuelles avec des versions cibles de SQL Server 2008 et antérieures ne sont pas prises en charge lors de la migration vers SQL Server sur une machine virtuelle Azure.

Si vous utilisez une machine virtuelle avec SQL Server 2012 ou SQL Server 2014, vous devez stocker vos fichiers de sauvegarde de base de données source dans un conteneur Blob Azure Storage au lieu d’utiliser l’option de partage réseau. Stockez les fichiers de sauvegarde en tant qu’objets blob de pages, car les objets blob de blocs ne sont pris en charge que dans SQL Server 2016 et versions ultérieures.

Vous devez vous assurer que l’extension de l’agent IaaS SQL Server dans la machine virtuelle Azure cible est en mode plein au lieu du mode Léger.

La migration vers une machine virtuelle Azure SQL à l’aide de DMS utilise l’agent IaaS SQL Server en interne. L’extension d’agent IaaS SQL Server prend uniquement en charge la gestion de l’instance de serveur par défaut ou de l’instance nommée unique.

Vous pouvez migrer au maximum 100 bases de données vers la même machine virtuelle Azure que la cible à l’aide d’une ou plusieurs migrations simultanément. De plus, une fois qu’une migration avec 100 bases de données est terminée, attendez au moins 30 minutes avant de commencer une nouvelle migration vers le même serveur SQL Server sur une machine virtuelle Azure que la cible. De plus, chaque opération de migration (démarrer la migration, basculement) pour chaque base de données prend quelques minutes de manière séquentielle. Par exemple, pour migrer 100 bases de données, il peut prendre environ 200 (2 x 100) minutes pour créer les files d'attente de migration et environ 100 (1 x 100) minutes pour transférer l'ensemble des 100 bases de données (à l'exception de la durée de la sauvegarde et de la restauration). Par conséquent, la migration devient plus lente à mesure que le nombre de bases de données augmente. Vous devez planifier une fenêtre de migration plus longue à l’avance en fonction de tests de migration rigoureux, ou partitionner un grand nombre de bases de données en lots lors de leur migration vers SQL Server sur une machine virtuelle Azure.

Outre la configuration du réseau/pare-feu de votre compte stockage Azure pour permettre à votre machine virtuelle d’accéder aux fichiers de sauvegarde, vous devez également configurer le réseau/pare-feu de votre serveur SQL Server sur une machine virtuelle Azure pour autoriser la connexion sortante à votre compte de stockage.

Vous devez maintenir la machine virtuelle Azure cible activée pendant que la migration de SQL Server est en cours. En outre, lors de la création d’une migration, basculez ou annulez la migration.

Messages d’erreur possibles

Échec de la connexion pour l’utilisateur « NT Service\SQLIaaSExtensionQuery »

Erreur : Login failed for user 'NT Service\SQLIaaSExtensionQuery

Raison : SQL Server instance est en mode mono-utilisateur. Une des raisons possibles est que la machine virtuelle SQL Server cible est en mode de mise à niveau.

Solution : attendez que la machine virtuelle SQL Server cible quitte le mode de mise à niveau, puis recommencez la migration.

Échec de la création d’une tâche de restauration

Erreur : Ext_RestoreSettingsError, message: Failed to create restore job.;Cannot create file 'F:\data\XXX.mdf' because it already exists.

Solution : Connectez-vous à la machine virtuelle SQL Server cible et supprimez le XXX.mdf fichier. Ensuite, redémarrez la migration.

Contenu connexe

  • Last updated on