Tutoriel : Migrer SQL Server vers SQL Server sur les machines virtuelles Azure en ligne avec Azure Data Studio

Utilisez l’extension de migration Azure SQL dans Azure Data Studio pour migrer les bases de données d’une instance SQL Server vers une instance SQL Server sur une machine virtuelle Azure (SQL Server 2016 et versions ultérieures) avec un temps d’arrêt minimal. Pour connaître les méthodes qui peuvent nécessiter un effort manuel, consultez l’article Migration d’une instance de SQL Server vers SQL Server sur les machines virtuelles Azure.

Dans ce tutoriel, vous migrez la base de données AdventureWorks d’une instance locale de SQL Server vers SQL Server sur une machine virtuelle Azure avec un temps d’arrêt minimal à l’aide d’Azure Data Studio avec Azure Database Migration Service.

Dans ce tutoriel, vous apprenez à effectuer les opérations suivantes :

  • Lancer l’Assistant Migration vers Azure SQL dans Azure Data Studio.
  • Exécuter une évaluation de vos bases de données SQL Server sources
  • Collecter les données de performances de votre instance SQL Server source
  • Obtenez une recommandation du Serveur SQL sur la référence SKU de machine virtuelle Azure la mieux adaptée à votre charge de travail
  • Spécifier les détails de votre serveur SQL Server source, de l’emplacement de sauvegarde et de votre instance cible de SQL Server sur les machines virtuelles Azure
  • Créer une instance d’Azure Database Migration Service et installer le runtime d’intégration autohébergé 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.

Cet article décrit une migration en ligne de SQL Server vers SQL Server sur les machines virtuelles Azure. Pour une migration hors connexion, consultez Migrer SQL Server vers SQL Server sur les machines virtuelles Azure hors connexion à l’aide d’Azure Data Studio et de DMS.

Prérequis

Pour suivre ce didacticiel, vous devez effectuer les opérations suivantes :

  • Télécharger et installer Azure Data Studio

  • Installer l’extension de migration Azure SQL à partir de la place de marché Azure Data Studio

  • Disposer d’un compte Azure affecté à l’un des rôles intégrés listés ci-dessous :

    • Contributeur pour le Serveur SQL cible sur la machine virtuelle Azure (et le compte de Stockage pour charger vos fichiers de sauvegarde de base de données à partir d’un partage réseau SMB).
    • Rôle de lecteur pour les groupes de ressources Azure contenant le Serveur SQL sur une Machine virtuelle Azure ou le compte de stockage Azure.
    • Rôle de propriétaire ou de contributeur pour l’abonnement Azure.
    • Au lieu d’utiliser les rôles intégrés ci-dessus, vous pouvez attribuer un rôle personnalisé, comme défini dans cet article.

    Important

    Le compte Azure n’est requis que lors de la configuration des étapes de migration. Il n’est pas obligatoire pour les étapes d’évaluation et de recommandation Azure de l’Assistant Migration.

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

    Important

    Si vous disposez d’une machine virtuelle Azure existante, elle doit être inscrite avec l’extension SQL IaaS Agent en mode Administration complète.

  • Vérifiez que les comptes de connexion utilisés pour connecter l’instance SQL Server source sont membres du rôle serveur sysadmin ou ont l’autorisation CONTROL SERVER.

  • Utilisez l’une des options de stockage suivantes pour la base de données complète et les fichiers de sauvegarde du journal des transactions :

    • Partage réseau SMB
    • Partage de fichiers de compte de stockage Azure ou conteneur d’objets blob

    Important

    • L’extension de migration Azure SQL pour Azure Data Studio n’effectue pas de sauvegardes de base de données et n’initie 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 sont fournis dans un partage réseau SMB, Créez un compte de stockage Azure qui permet au service DMS de charger les fichiers de sauvegarde de la base de données. Veillez à créer le compte de stockage Azure dans la même région que celle où l’instance d’Azure Database Migration Service est créée.
    • Azure Database Migration Service ne lance pas les sauvegardes. Il utilise les sauvegardes existantes (qui peuvent déjà faire partie de votre plan de récupération d'urgence) pour la migration.
    • Chaque sauvegarde peut être enregistrée dans un fichier de sauvegarde distinct ou dans plusieurs fichiers de sauvegarde. Toutefois, l’ajout de plusieurs sauvegardes (par exemple, full et t-log) sur un seul support de sauvegarde n’est pas pris en charge.
    • Utilisez des sauvegardes compressées pour réduire le risque de problèmes liés à la 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.

  • Le certificat de l’instance source de SQL Server provenant d’une base de données protégée par un chiffrement TDE (Transparent Data Encryption) doit être migré vers l’instance cible de SQL Server sur les machines virtuelles Azure avant la migration des données. Pour en savoir plus, consultez Déplacer une base de données protégée par TDE vers un autre serveur SQL Server.

    Conseil

    Si votre base de données contient des données sensibles protégées par la fonctionnalité Always Encrypted, le processus de migration à l’aide d’Azure Data Studio et de DMS effectue automatiquement la migration de vos clés Always Encrypted vers votre instance cible de SQL Server sur les machines virtuelles Azure.

  • Si vos sauvegardes de base de données se trouvent dans un partage de fichiers réseau, fournissez un ordinateur pour installer l’IR auto-hébergé pour accéder et migrer les sauvegardes de base de données. L’Assistant Migration fournit le lien de téléchargement et les clés d’authentification pour télécharger et installer votre IR auto-hébergé. Pour préparer la migration, assurez-vous que l’ordinateur sur lequel vous prévoyez d’installer l’IR auto-hébergé possède les règles de pare-feu sortantes et les noms de domaine suivants activés :

    Noms de domaine Ports sortants Description
    Cloud public : {datafactory}.{region}.datafactory.azure.net
    ou *.frontend.clouddatahub.net
    Azure Government : {datafactory}.{region}.datafactory.azure.us
    Chine : {datafactory}.{region}.datafactory.azure.cn
    443 Requis par l’IR auto-hébergé pour se connecter au service de migration des données.
    Pour les nouvelles Data Factory créées dans le cloud public, localisez le nom de domaine complet à partir de votre clé de runtime d'intégration auto-hébergée, qui est au format {datafactory}.{region}.datafactory.azure.net. Pour une ancienne fabrique de données, 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 avez désactivé la mise à jour automatique, vous pouvez ignorer la configuration de ce domaine.
    *.core.windows.net 443 Utilisé par l’IR auto-hébergé qui se connecte au compte de stockage Azure pour charger les sauvegardes de base de données à partir de votre partage réseau

    Conseil

    Si vos fichiers de sauvegarde de base de données sont déjà fournis dans un compte de stockage Azure, l’IR auto-hébergé n’est pas requis pendant le processus de migration.

  • Le runtime est installé sur la machine à l’aide du runtime d’intégration autohébergé. La machine se connecte à l’instance source de SQL Server et au partage de fichiers réseau où se trouvent les fichiers de sauvegarde. Le port de sortie 445 doit être activé pour autoriser l’accès au partage de fichiers réseau. Consultez également les recommandations d’utilisation du runtime d’intégration autohébergé

  • Si vous utilisez l’Azure Database Migration Service pour la première fois, assurez-vous que le fournisseur de ressources Microsoft.DataMigration est inscrit dans votre abonnement. Vous pouvez suivre les étapes pour inscrire le fournisseur de ressources

Lancer l’Assistant Migration vers Azure SQL dans Azure Data Studio

  1. Ouvrez Azure Data Studio, puis sélectionnez l’icône de serveur pour vous connecter à votre serveur SQL Server local (ou à SQL Server sur les machines virtuelles Azure).
  2. Cliquez avec le bouton droit sur la connexion au serveur, puis sélectionnez Gérer.
  3. Dans la page d’accueil du serveur, sélectionnez l’extension Migration Azure SQL.
  4. Dans le tableau de bord de l’extension de migration Azure SQL, sélectionnez Migrer vers Azure SQL pour lancer l’Assistant Migration. Launch Migrate to Azure SQL wizard
  5. Dans la première étape de l’Assistant Migration, liez votre nouveau compte ou votre compte Azure existant à Azure Data Studio.

Exécution de l’évaluation de la base de données, collecte de données de performances et recommandation Azure

  1. Sélectionnez la ou les bases de données à évaluer, puis sélectionnez Suivant.
  2. Sélectionnez SQL Server sur les machines virtuelles Azure en tant que cible. Screenshot of assessment confirmation.
  3. Sélectionnez le bouton Afficher/Sélectionner pour voir les détails des résultats de l’évaluation de vos bases de données, sélectionnez les bases de données à migrer, puis sélectionnez OK.
  4. Sélectionnez le bouton Obtenir une recommandation Azure.
  5. Sélectionnez l’option Collecter les données de performances maintenant et entrez le chemin d’accès pour les journaux d’activité de performances à collecter, puis sélectionnez le bouton Démarrer.
  6. Azure Data Studio collecte ensuite les données de performances jusqu’à ce que vous arrêtiez le processus, appuyiez sur le bouton Suivant dans l’Assistant ou fermiez Azure Data Studio.
  7. Une configuration recommandée pour votre machine virtuelle Azure SQL s’affiche au bout de 10 minutes. Vous pouvez aussi appuyer sur le lien Actualiser la recommandation après les 10 minutes initiales pour actualiser la recommandation avec les données supplémentaires collectées.
  8. Dans la zone SQL Server sur les machines virtuelles Azure ci-dessus, sélectionnez le bouton Afficher les détails pour obtenir davantage d’informations sur votre recommandation.
  9. Fermez la zone Afficher les détails et appuyez sur le bouton Suivant.

Configurer les paramètres de migration

  1. Spécifiez votre instance cible de SQL Server sur machine virtuelle Azure en sélectionnant l’abonnement, l’emplacement et le groupe de ressources appropriés dans les listes déroulantes correspondantes, puis sélectionnez Suivant.
  2. Sélectionnez le mode de migration Migration en ligne.

    Notes

    En mode de migration en ligne, la base de données SQL Server source est disponible pour des activités de lecture et d’écriture pendant la restauration en continu des sauvegardes de base de données sur l’instance cible de SQL Server sur les machines virtuelles Azure. Le temps d’arrêt de l’application se limite à la durée du basculement à la fin de la migration.

  3. À l’étape 5, sélectionnez l’emplacement de vos sauvegardes de base de données. Vos sauvegardes de base de données peuvent se trouver sur un partage réseau local ou dans un conteneur Azure Storage Blob.

    Notes

    Si vos sauvegardes de base de données se trouvent sur un partage réseau local, DMS vous demande de configurer le runtime d’intégration autohébergé à l’étape suivante de l’Assistant. Le runtime d’intégration autohébergé est nécessaire pour accéder aux sauvegardes de votre base de données source, vérifier la validité du jeu de sauvegarde et charger ce dernier vers le compte Stockage Azure.
    Si vos sauvegardes de base de données se trouvent déjà dans un conteneur Azure Storage Blob, vous n’avez pas besoin de configurer le runtime d’intégration autohébergé.

  • Pour les sauvegardes stockées sur un partage réseau, spécifiez les détails ci-dessous concernant l’instance SQL Server source, l’emplacement de la sauvegarde source, le nom de la base de données cible et le compte de stockage Azure où les fichiers de sauvegarde seront chargés.

    Champ Description
    Informations d’identification de la source - Nom d’utilisateur Informations d’identification (authentification Windows/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/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. Les fichiers non valides ou les fichiers de sauvegarde du partage réseau qui n’appartiennent pas au jeu de sauvegarde valide sont automatiquement ignorés durant le processus de migration.
    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 si vous souhaitez changer le nom de la base de données sur la cible durant le processus de migration.
  • Pour les sauvegardes stockées dans un conteneur d’objets blob Stockage Azure, spécifiez les détails ci-dessous concernant le nom de la base de données cible, le groupe de ressources, le compte de stockage Azure et le conteneur d’objets blob, en utilisant les listes déroulantes correspondantes.

    Champ Description
    Nom de la base de données cible Vous pouvez modifier le nom de la base de données cible si vous souhaitez changer le nom de la base de données sur la cible durant le processus de migration.
    Détails du compte de stockage Groupe de ressources, compte de stockage et conteneur où se trouvent les fichiers de sauvegarde.
  1. Sélectionnez Suivant pour continuer.

    Important

    Si la fonctionnalité du contrôle de bouclage est activée et que le 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 à l’aide du FQDN. Pour résoudre ce problème, désactivez la fonctionnalité du contrôle de bouclage à l’aide des instructions indiquées ici

  • L’extension de migration Azure SQL pour Azure Data Studio n’exige plus de configurations spécifiques au niveau des paramètres réseau de votre compte Stockage Azure pour la migration de vos bases de données SQL Server vers Azure. Cependant, selon l’emplacement de sauvegarde de votre base de données et la configuration souhaitée des paramètres réseau du compte de stockage, quelques étapes sont nécessaires pour permettre à vos ressources d’accéder au compte Stockage Azure. Consultez le tableau suivant pour découvrir les différents scénarios de migration et les différentes 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 Voir 1a Voir 2a
    Activé à partir de réseaux virtuels et d’adresses IP sélectionnés + point de terminaison privé Voir 1b Voir 2b

    1a – Configuration réseau de Stockage Blob Azure

    Si votre runtime d’intégration auto-hébergé (SHIR) est installé sur une machine virtuelle Azure, consultez la section 1b – Configuration réseau de Stockage Blob Azure. Si votre runtime d'intégration auto-hébergé (SHIR) est installé sur votre réseau local, vous devez ajouter votre adresse IP cliente de la machine d’hébergement dans votre compte Stockage Azure comme suit :

    Screenshot that shows the storage account network details.

    Pour appliquer cette configuration spécifique, connectez-vous au portail Azure à partir de la machine SHIR, ouvrez la configuration du compte Stockage Azure, sélectionnez Réseau, puis cochez la case Ajouter l’adresse IP de votre client. Sélectionnez Enregistrer pour rendre la modification persistante. Pour les étapes restantes, consultez la section 2a – Configuration réseau de Stockage Blob Azure (point de terminaison privé).

    1b – Configuration réseau de Stockage Blob Azure

    Si votre SHIR est hébergé sur une machine virtuelle Azure, vous devez ajouter le réseau virtuel de la machine virtuelle au compte Stockage Azure, car la machine virtuelle a une adresse IP non publique qui ne peut pas être ajoutée à la section Plage d’adresses IP.

    Screenshot that shows the storage account network firewall configuration.

    Pour appliquer cette configuration spécifique, localisez votre compte Stockage Azure. Ensuite, dans le panneau Stockage des données, sélectionnez Réseau, puis cochez la case Ajouter un réseau virtuel existant. Dans le nouveau panneau qui s’ouvre, sélectionnez l’abonnement, le réseau virtuel et le sous-réseau de la machine virtuelle Azure qui héberge le runtime d’intégration. Vous trouverez ces informations dans la page Vue d’ensemble de la machine virtuelle Azure. Il se peut que le sous-réseau indique Point de terminaison de service obligatoire. Si c’est le cas, sélectionnez Activer. Une fois que tout est prêt, enregistrez les mises à jour. Pour les étapes restantes nécessaires, reportez-vous à la section 2a – Configuration réseau de Stockage Blob Azure (point de terminaison privé).

    2a – Configuration réseau de Stockage Blob Azure (point de terminaison privé)

    Si vos sauvegardes sont placées directement dans un conteneur Stockage Azure, toutes les étapes précédentes sont inutiles, car aucun runtime d’intégration ne communique avec le compte Stockage Azure. Cependant, il nous reste encore à vérifier que l’instance cible de SQL Server peut communiquer avec le compte Stockage Azure pour restaurer les sauvegardes à partir du conteneur. Pour appliquer cette configuration spécifique, suivez les instructions de la section 1b – Configuration réseau de Stockage Blob Azure, en spécifiant le réseau virtuel de l’instance SQL cible au moment de compléter la fenêtre contextuelle « Ajouter un réseau virtuel existant ».

    2b – Configuration réseau de Stockage Blob Azure (point de terminaison privé)

    Si vous avez configuré un point de terminaison privé sur votre compte Stockage Azure, suivez les étapes décrites dans la section 2a – Configuration réseau de Stockage Blob Azure (point de terminaison privé). Cependant, vous devez sélectionner le sous-réseau du point de terminaison privé, et pas seulement le sous-réseau cible SQL Server. Vérifiez que le point de terminaison privé est hébergé dans le même réseau virtuel que l’instance cible de SQL Server. Si ce n’est pas le cas, créez un autre point de terminaison privé en suivant le processus de la section Configuration du compte Stockage Azure.

Créer une instance d’Azure Database Migration Service

  1. Créez une instance d’Azure Database Migration Service, ou réutilisez un service existant que vous avez créé.

    Notes

    Si vous avez créé une instance de DMS à l’aide du portail Azure, vous ne pouvez pas la réutiliser dans l’Assistant Migration d’Azure Data Studio. Seule l’instance de DMS créée à l’aide d’Azure Data Studio peut être réutilisée.

  2. Sélectionnez le groupe de ressources où vous avez déjà une instance de DMS, ou dans lequel vous devez en créer une. La liste déroulante Azure Database Migration Service liste les instances existantes de DMS dans le groupe de ressources sélectionné.
  3. Pour réutiliser une instance existante de DMS, sélectionnez-la dans la liste déroulante. L’état du runtime d’intégration autohébergé s’affiche ensuite au bas de la page.
  4. Pour créer une instance de DMS, sélectionnez Créer.
  5. Dans l’écran Créer une instance d’Azure Database Migration Service, indiquez le nom de l’instance de DMS, puis sélectionnez Créer.
  6. Une fois la création de l’instance de DMS réussie, vous recevez les détails nécessaires pour configurer le runtime d’intégration.
  7. Sélectionnez Télécharger et installer le runtime d’intégration pour ouvrir le lien de téléchargement dans un navigateur web. Effectuez le téléchargement. Installez le runtime d’intégration sur une machine qui respecte les prérequis de connexion au serveur SQL Server source et à l’emplacement contenant la sauvegarde source.
  8. Une fois l’installation effectuée, le Gestionnaire de configuration de Microsoft Integration Runtime se lance automatiquement pour débuter le processus d’inscription.
  9. Copiez et collez l’une des clés d’authentification fournies dans l’écran de l’Assistant au sein d’Azure Data Studio. Si la clé d’authentification est valide, une icône représentant une coche verte s’affiche dans le Gestionnaire de configuration d’Integration Runtime pour indiquer que vous pouvez passer à l’inscription.
  10. Une fois l’inscription du runtime d’intégration autohébergé réussie, fermez le Gestionnaire de configuration de Microsoft Integration Runtime, puis revenez à l’Assistant Migration dans Azure Data Studio.
  11. Sélectionnez Tester la connexion dans l’écran Créer une instance d’Azure Database Migration Service au sein d’Azure Data Studio pour vérifier que l’instance de DMS créée est connectée au runtime d’intégration autohébergé récemment inscrit, puis sélectionnez Terminé. Test connection integration runtime
  12. Passez en revue le récapitulatif, puis sélectionnez Terminé pour démarrer la migration de base de données.

Superviser la migration

  1. Dans l’État de la migration de base de données, vous pouvez suivre les migrations en cours, les migrations effectuées et les migrations non réussies (le cas échéant).

    monitor migration dashboard

  2. Sélectionnez Migrations de base de données en cours pour voir les migrations en cours et obtenir plus de détails en sélectionnant le nom de la base de données.

  3. La page des détails de la migration affiche les fichiers de sauvegarde et l’état correspondant :

    Statut Description
    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
    Téléchargé Le fichier de sauvegarde est chargé vers le service Stockage Azure
    Restoring Azure Database Migration Service restaure actuellement le fichier de sauvegarde sur le Serveur SQL sur une machine virtuelle Azure
    Restaurée Le fichier de sauvegarde est correctement restauré sur le Serveur SQL sur une machine virtuelle Azure
    Opération annulée 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

    online vm backup restore details

Terminer le basculement de la migration

La dernière étape du tutoriel consiste à effectuer le basculement de la migration. L’étape de finalisation permet de garantir que la base de données migrée vers SQL Server sur les machines virtuelles Azure est prête à l’emploi. Un temps d’arrêt est nécessaire pour les applications qui se connectent à la base de données. Ainsi, la planification du basculement doit être soigneusement effectuée avec les parties prenantes liées à l’entreprise ou aux applications.

Pour effectuer le basculement :

  1. Arrêtez toutes les transactions entrantes vers la base de données source.
  2. Apportez les changements de configuration nécessaires aux applications pour pointer vers la base de données cible dans SQL Server sur les machines virtuelles Azure.
  3. Effectuez une dernière sauvegarde de journal pour la base de données source à l’emplacement de sauvegarde spécifié.
  4. Définissez la base de données source en mode lecture seule. Ainsi, les utilisateurs peuvent lire des données dans la base de données, mais ne peuvent pas les modifier.
  5. Vérifiez que toutes les sauvegardes de base de données sont à l’état Restauré dans la page des détails de la supervision.
  6. Sélectionnez Terminer le basculement dans la page des détails de la supervision.

Durant le processus de basculement, l’état de la migration passe de en cours à fin. L’état de la migration passe à opération réussie, une fois le processus de basculement effectué. La migration de base de données a réussi, et la base de données migrée est prête à l’emploi.

Limites

La migration vers SQL Server sur des machines virtuelles Azure à l’aide de l’extension Azure SQL pour Azure Data Studio présente les limitations suivantes :

  • Si vous migrez une base de données unique, les sauvegardes de base de données doivent être placées dans une structure de fichiers plats à l’intérieur d’un dossier de base de données (contenant un dossier racine conteneur), et les dossiers ne peuvent pas être imbriqués, car cela n’est pas pris en charge.
  • Lors de la migration de 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.
  • Le remplacement des bases de données existantes à l’aide de DMS dans votre SQL Server cible sur une machine virtuelle Azure n’est pas pris 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 n’est pas prise en charge par DMS.
  • Les objets serveur suivants ne sont pas pris en charge :
    • travaux de l'Agent SQL Server
    • Informations d'identification
    • Packages SSIS
    • Audit de serveur
  • Vous ne pouvez pas utiliser un runtime d’intégration auto-hébergé existant créé à partir d’Azure Data Factory pour les migrations de base de données avec DMS. Au départ, le runtime d’intégration auto-hébergé doit être créé à l’aide de l’extension de migration Azure SQL dans Azure Data Studio, et il peut être réutilisé pour des migrations de base de données supplémentaires.
  • Les machines Virtuelles avec SQL Server 2008 et les versions antérieures ne sont pas pris en charge pour la migration vers SQL Server sur des machines virtuelles 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 sur un conteneur Azure Storage Blob 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 2016 et versions ultérieures.
  • Vous devez vous assurer que l’extension IAAS SQL Agent dans la machine virtuelle Azure cible est en mode Complet au lieu du mode Léger.
  • L’extension d’agent IaaS SQL prend uniquement en charge la gestion de l’instance de serveur par défaut ou de l’instance nommée unique.
  • Le nombre de bases de données que vous pouvez migrer vers une machine virtuelle Azure SQL Server dépend de la spécification matérielle et de la charge de travail, mais aucune limite n’est appliquée. Toutefois, 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, la migration de 100 bases de données peut prendre environ 200 (2 x 100) minutes pour créer la file d’attente de migration et environ 100 (1 x 100) minutes pour basculer toutes les 100 bases de données (à l’exclusion du délai de sauvegarde et de restauration). Par conséquent, la migration devient plus lente à mesure que le nombre de bases de données augmente. Microsoft recommande de planifier une fenêtre de migration plus longue à l’avance en fonction de tests de migration rigoureux ou de partitionner un grand nombre de bases de données en lots lors de leur migration vers une machine virtuelle Azure SQL Server.
  • Outre la configuration du réseau/pare-feu de votre compte de stockage Azure pour permettre à votre machine virtuelle d’accéder aux fichiers de sauvegarde. Vous devez également configurer la mise en réseau/le pare-feu de votre SQL Server sur une machine virtuelle Azure pour autoriser la connexion sortante à votre compte de stockage.
  • Vous devez conserver la SQL Server cible sur la machine virtuelle Azure sous tension pendant que la migration SQL est en cours. En outre, lors de la création d’une migration, basculez ou annulez la migration.
  • Erreur : Login failed for user 'NT Service\SQLIaaSExtensionQuery. Raison : SQL Server instance est en mode mono-utilisateur. L’une des raisons possibles est que la SQL Server cible sur une machine virtuelle Azure est en mode de mise à niveau. Solution : attendez que le SQL Server cible sur la machine virtuelle Azure quitte le mode de mise à niveau et recommencez la migration.
  • Erreur : Ext_RestoreSettingsError, message: Failed to create restore job.;Cannot create file 'F:\data\XXX.mdf' because it already exists. Solution : Connectez-vous au SQL Server cible sur la machine virtuelle Azure et supprimez le fichier XXX.mdf. Ensuite, redémarrez la migration.

Étapes suivantes