Tutoriel : Migrer SQL Server vers Azure SQL Managed Instance en ligne dans Azure Data Studio

  • Article

Utilisez l’extension de migration Azure SQL dans Azure Data Studio pour migrer les bases de données d’une instance de SQL Server vers Azure SQL Managed Instance avec un temps d’arrêt minimal. Pour connaître les méthodes qui peuvent demander un effort manuel, consultez l’article Migration d’une instance de SQL Server vers Azure SQL Managed Instance.

Dans ce tutoriel, vous allez migrer la base de données AdventureWorks d’une instance locale de SQL Server vers Azure SQL Managed Instance avec un temps d’arrêt minimal en utilisant Azure Data Studio et Azure Database Migration Service (DMS). Ce tutoriel se concentre sur le mode de migration en ligne où le temps d’arrêt des applications est limité à un basculement rapide à la fin de la migration.

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
  • Obtenir une recommandation sur la référence SKU Azure SQL Managed Instance 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 d’Azure SQL Managed Instance
  • Créer une instance 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

Important

Préparez la migration et réduisez autant que possible la durée du processus de migration en ligne pour limiter le risque d’une interruption provoquée par une reconfiguration ou une maintenance planifiée de l’instance. Dans le cas d’un tel événement, le processus de migration reprend dès le début. En cas de maintenance planifiée, il existe une période de grâce de 36 heures pendant laquelle la configuration ou la maintenance d’une instance cible d’Azure SQL Managed Instance est suspendue avant le redémarrage du processus de migration.

Conseil

Dans Azure Database Migration Service, vous pouvez migrer vos bases de données hors connexion ou pendant qu’elles sont en ligne. Lors d’une migration hors connexion, le temps d’arrêt de l’application commence quand la migration commence. Pour limiter le temps d’arrêt au temps nécessaire pour basculer vers le nouvel environnement après la migration, utilisez une migration en ligne. Nous vous recommandons de tester une migration hors connexion pour déterminer si le temps d’arrêt est acceptable. Si le temps d’arrêt attendu n’est pas acceptable, effectuez une migration en ligne.

Cet article décrit une migration de base de données en ligne de SQL Server vers Azure SQL Managed Instance. Pour une migration de base de données hors connexion, consultez Migrer SQL Server vers SQL Managed Instance 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 Azure SQL Managed Instance cible (et compte 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 Azure SQL Managed Instance cible ou le compte de stockage Azure.
    • Rôle Propriétaire ou Contributeur pour l’abonnement Azure (obligatoire en cas de création d’un nouveau service DMS).
    • 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 cible Azure SQL Managed Instance.

  • 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.
    • Chaque sauvegarde peut être enregistrée dans un fichier de sauvegarde distinct ou dans plusieurs fichiers de sauvegarde. Toutefois, l’ajout de plusieurs sauvegardes (c’est-à-dire, 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 d’instance source SQL Server d’une base de données protégée par Transparent Data Encryption (TDE) doit être migré vers Azure SQL Managed Instance ou SQL Server cible sur une machine virtuelle Azure avant de migrer les données. Pour plus d’informations sur la migration des bases de données avec TDE activé, consultez Tutoriel : Migrer des bases de données avec TDE (Transparent Data Encryption) activé (préversion) vers Azure SQL dans Azure Data Studio.

    Conseil

    Si votre base de données contient des données sensibles qui sont protégées par Always Encrypted, le processus de migration à l’aide d’Azure Data Studio avec DMS migre automatiquement vos clés Always Encrypted vers votre Azure SQL Managed Instance ou SQL Server cible 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 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.

  • 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. 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. La première page de l’Assistant vous permet de démarrer une nouvelle session ou de reprendre une session enregistrée précédemment. Choisissez la première option pour démarrer une nouvelle session.

Exécuter l’évaluation de base de données, collecter les données de performances et obtenir la recommandation Azure

  1. Sélectionnez la ou les bases de données à évaluer, puis sélectionnez Suivant.
  2. Sélectionnez Azure SQL Managed Instance en tant que cible. 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. Si des problèmes s’affichent dans les résultats de l’évaluation, vous devez les corriger avant de passer aux étapes suivantes. Database assessment details
  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 Azure SQL Managed Instance 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 Azure SQL Managed Instance* 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 managée Azure SQL Managed Instance en sélectionnant l’abonnement, l’emplacement et le groupe de ressources 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 d’Azure SQL Managed Instance. Le temps d’arrêt de l’application se limite à la durée du basculement à la fin de la migration.

  3. 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. Si le runtime d’intégration autohébergé est nécessaire pour accéder aux sauvegardes de votre base de données source, vérifiez la validité du jeu de sauvegarde et chargez ce dernier vers votre 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.
    Détails du compte de stockage Groupe de ressources et compte de stockage où les fichiers de sauvegarde sont chargés. Vous n’avez pas besoin de créer de conteneur, car DMS crée automatiquement un conteneur d’objets blob dans le compte de stockage spécifié durant le processus de chargement.

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

    Important

    Si la fonctionnalité de 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. 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.
  5. 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.
  6. 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.
  7. Une fois l’installation effectuée, le Gestionnaire de configuration de Microsoft Integration Runtime se lance automatiquement pour débuter le processus d’inscription.
  8. 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.
  9. 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.
  10. 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. Test connection integration runtime
  11. Passez en revue le récapitulatif de la migration, 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 le fichier de sauvegarde sur Azure SQL Managed Instance
    Restaurée Le fichier de sauvegarde a été correctement restauré sur Azure SQL Managed Instance
    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

    backup restore details

Terminer le basculement de la migration

La dernière étape du tutoriel consiste à effectuer le basculement de la migration pour vérifier que la base de données migrée dans Azure SQL Managed Instance est prête à l’emploi. Ce processus est la seule partie qui demande un temps d’arrêt pour les applications qui se connectent à la base de données. Il convient donc de bien réfléchir au moment où le basculement sera effectué avec les parties prenantes liées à l’activité ou à l’application.

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 qu’elles pointent vers la base de données cible dans Azure SQL Managed Instance.
  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. Une fois le processus de basculement effectué, l’état de la migration passe à opération réussie pour indiquer que la migration de la base de données s’est correctement déroulée et que la base de données migrée est prête à être utilisée.

Important

Après le basculement, la disponibilité de SQL Managed Instance avec le niveau de service critique pour l’entreprise peut prendre beaucoup plus de temps que l’usage général, car trois réplicas secondaires doivent être amorcés pour le groupe de disponibilité Always On. La durée de cette opération dépend de la taille des données. Pour plus d’informations, consultez Durée des opérations de gestion.

Limites

La migration vers Azure SQL Managed Instance à 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 le 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 Azure SQL Managed Instance cible n’est pas pris en charge.
  • DMS ne prend pas en charge la configuration de la haute disponibilité et 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
    • 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.
  • Un travail LRS unique (créé par DMS) peut s’exécuter pendant un maximum de 30 jours. Lorsque cette période arrive à expiration, la tâche est automatiquement annulée et votre base de données cible est automatiquement supprimée.
  • Si vous recevez l’erreur suivant : Memory-optimized filegroup must be empty in order to be restored on General Purpose tier of SQL Database Managed Instance. Ce problème est dû à sa conception. Hekaton (également connu comme SQL Server OLTP en mémoire) n’est pas pris en charge sur un niveau d’usage général d’Instance gérée Azure SQL. Pour poursuivre la migration, une méthode consiste à effectuer une mise à niveau vers le niveau critique pour l’entreprise qui prend en charge Hekaton. Une autre méthode consiste à veiller à ce que la base de données source ne l’utilise pas quand l’Instance gérée Azure SQL est en usage général.

Étapes suivantes