Tutoriel : Migrer SQL Server vers Azure SQL Managed Instance avec DMS
Vous pouvez utiliser Azure Database Migration Service (DMS) et l’extension de migration Azure SQL dans Azure Data Studio pour migrer des bases de données d’une instance SQL Server vers Azure SQL Managed Instance 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 Guide de migration : SQL Server vers Azure SQL Managed Instance.
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.
Dans ce tutoriel, vous migrez la base de données AdventureWorks2022 d’une instance SQL Server locale vers une instance Azure SQL Managed Instance, à l’aide d’Azure Data Studio et 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 allez apprendre à :
- 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 instance SQL Server source, de l’emplacement de sauvegarde et de l’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 afin de 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 Azure SQL Managed Instance est suspendue avant le redémarrage du processus de migration.
Prérequis
Pour suivre ce didacticiel, vous devez effectuer les opérations suivantes :
Installer l’extension de migration Azure SQL pour Azure Data Studio à partir de la place de marché Azure Data Studio
Disposer d’un compte Azure affecté à l’un des rôles intégrés suivants :
Contributeur pour l’instance cible d’Azure SQL Managed Instance 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) et rôle Lecteur pour les groupes de ressources Azure qui contiennent l’instance cible d’Azure SQL Managed Instance ou votre compte de stockage Azure.
Rôle Propriétaire ou Contributeur pour l’abonnement Azure (requis si vous créez une instance 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é.
Important
Un compte Azure n’est requis que lorsque vous configurez les étapes de migration. Un compte Azure n’est pas nécessaire pour l’évaluation ou pour afficher les recommandations Azure dans l’Assistant Migration dans Azure Data Studio.
Créez une instance cible d’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.Fournissez un partage réseau SMB, un partage de fichiers de compte Stockage Azure ou un conteneur d’objets blob de compte Stockage Azure contenant vos fichiers de sauvegarde complète de base de données et de sauvegarde des journaux de transactions suivants. Database Migration Service utilise l’emplacement de sauvegarde pendant la migration de la base de données.
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 les fichiers de sauvegarde de votre base de données se trouvent dans un partage réseau PME, créez un compte de stockage Azure qui permette au service DMS de charger les fichiers de sauvegarde de la base de données et de migrer les bases de données. Veillez à créer le compte de stockage Azure dans la même région que celle où vous créez votre instance de Database Migration Service.
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 Transparent Data Encryption (TDE), le certificat de l’instance source SQL Server doit être migré vers votre instance cible Azure SQL 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.
Si votre base de données contient des données sensibles protégées par la fonctionnalité Always Encrypted, le processus de migration effectue automatiquement la migration de vos clés Always Encrypted vers votre instance cible Azure SQL.
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é.
Pour préparer la migration, assurez-vous que l’ordinateur sur lequel vous prévoyez d’installer le runtime d’intégration auto-hébergé possède les règles de pare-feu sortantes et les noms de domaine suivants activés :
Noms de domaine Port sortant Description 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.cn443 Requis par l’IR auto-hébergé pour se connecter au service de migration des données.
Pour une fabrique de données nouvellement créée dans le 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.com443 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.net443 Utilisé par le runtime d’intégration 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.
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 Database Migration Service pour la première fois, assurez-vous que le fournisseur de ressources
Microsoft.DataMigrationest 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
Pour ouvrir l’Assistant Migrer vers Azure SQL :
Dans Azure Data Studio, accédez à Connexions. Sélectionnez et connectez-vous à votre instance locale SQL Server. Vous pouvez également vous connecter à SQL Server sur une machine virtuelle Azure.
Cliquez avec le bouton droit sur la connexion au serveur, puis sélectionnez Gérer.
Dans le menu du serveur, sous Général, sélectionnez Migration Azure SQL.
Dans le tableau de bord de l’extension de migration Azure SQL, sélectionnez Migrer vers Azure SQL pour ouvrir l’Assistant Migration.
Sur la première page de l’Assistant, démarrez une nouvelle session ou reprenez une session précédemment enregistrée.
Exécution de l’évaluation de la base de données, collecte de données de performances et recommandation Azure
Sélectionnez les bases de données que vous souhaitez évaluer, puis sélectionnez Suivant.
Sélectionnez Azure SQL Managed Instance en tant que cible.
Sélectionnez Afficher/Sélectionner pour afficher les résultats de l’évaluation.
Dans les résultats de l’évaluation, sélectionnez la base de données, puis passez en revue le rapport d’évaluation pour vous assurer qu’aucun problème n’a été détecté.
Sélectionnez Obtenir la recommandation Azure pour ouvrir le volet de recommandations.
Sélectionnez Collecter les données de performance maintenant. Choisissez un dossier sur votre ordinateur local pour stocker les journaux de performances, puis sélectionnez Démarrer.
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.
Après 10 minutes, Azure Data Studio indique qu’une recommandation est disponible pour Azure SQL Managed Instance. Vous pouvez aussi cliquer sur le lien Actualiser la recommandation après les 10 minutes initiales pour actualiser et affiner la recommandation à l’aide des données supplémentaires collectées. Une évaluation étendue est particulièrement utile si vos modèles d’utilisation varient au fil du temps.
Dans la cible Azure SQL Managed Instance sélectionnée, cliquez sur Afficher les détails pour ouvrir le rapport de recommandation de référence SKU détaillé.
Dans Passer en revue les recommandations Azure SQL Managed Instance, passez en revue la recommandation. Pour enregistrer une copie de la recommandation, cochez la case Enregistrer le rapport de recommandations.
Sélectionnez Fermer pour fermer le sous-onglet de recommandations.
Sélectionnez Suivant pour poursuivre la migration de votre base de données dans l’Assistant.
Configurer les paramètres de migration
Spécifiez votre instance Azure SQL Managed Instance en sélectionnant votre abonnement, votre emplacement, votre groupe de ressources dans les listes déroulantes correspondantes, puis sélectionnez Suivant.
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.
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 situées sur un partage réseau, entrez ou sélectionnez les informations suivantes :
| 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 pendant le processus de migration. |
| Détails du compte de stockage | Groupe de ressources et compte de stockage où les fichiers de sauvegarde seront chargés. Vous n’avez pas besoin de créer un conteneur. Database Migration Service (DMS) crée un conteneur d’objets blob dans le compte de stockage spécifié pendant le processus de chargement. |
Pour les sauvegardes stockées dans un conteneur d’objets blob du Stockage Azure, entrez ou sélectionnez les informations suivantes :
| 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 :
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 de 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.
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. Un nouveau panneau 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 de 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 de Database Migration Service
Créez une instance d’Azure Database Migration Service, ou réutilisez un service existant que vous avez créé.
Si vous avez précédemment créé une instance Database Migration Service à l’aide du Portail Azure, vous ne pouvez pas réutiliser l’instance dans l’Assistant de migration dans Azure Data Studio. Vous pouvez réutiliser une instance uniquement si vous l’avez créée à l’aide d’Azure Data Studio.
Utiliser une instance existante de Database Migration Service
Pour utiliser une instance existante de Database Migration Service :
Dans Groupe de ressources, sélectionnez le groupe de ressources qui contient une instance existante de Database Migration Service.
Dans Azure Database Migration Service, sélectionnez une instance existante de Database Migration Service qui se trouve dans le groupe de ressources sélectionné.
Sélectionnez Suivant.
Créer une instance de Database Migration Service
Pour créer une instance de Database Migration Service :
Dans Groupe de ressources, créez un groupe de ressources pour contenir une nouvelle instance de Database Migration Service.
Sous Azure Database Migration Service, sélectionnez Créer.
Dans Créer Azure Database Migration Service, entrez un nom pour votre instance de Database Migration Service, puis sélectionnez Créer.
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.
Sélectionnez 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.
Une fois l’installation effectuée, le Gestionnaire de configuration de Microsoft Integration Runtime s’ouvre automatiquement pour débuter le processus d’inscription.
Dans le tableau Clé d’authentification, copiez l’une des clés d’authentification fournies dans l’Assistant et collez-la dans Azure Data Studio. 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.
Notes
Pour plus d’informations sur l’utilisation du runtime d’intégration auto-hébergé, consultez Créer et configurer un runtime d’intégration auto-hébergé.
Dans Créer Azure Database Migration Service dans Azure Data Studio, sélectionnez Tester la connexion pour valider que l’instance de Database Migration Service nouvellement créée est connectée au runtime d’intégration auto-hébergé nouvellement enregistré.
Revenez à l’Assistant Migration dans Azure Data Studio.
Démarrer la migration de base de données
Passez en revue la configuration que vous avez créée, puis sélectionnez Démarrer la migration pour démarrer la migration de base de données.
Surveiller la migration de base de données
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).
Sélectionnez Migrations de base de données en cours pour afficher les migrations actives.
Pour obtenir plus d’informations sur une migration spécifique, sélectionnez le nom de la base de données.
Le volet des détails de la migration affiche les fichiers de sauvegarde et leur é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 sur le compte de stockage Azure. Chargé Le fichier de sauvegarde a été chargé sur le compte de stockage Azure. Restauration Le service restaure le fichier de sauvegarde sur Azure SQL Managed Instance. Restauré Le fichier de sauvegarde a été correctement restauré sur Azure SQL Managed Instance. 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. 
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 :
- Arrêtez toutes les transactions entrantes vers la base de données source.
- 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.
- Effectuez une dernière sauvegarde de journal pour la base de données source à l’emplacement de sauvegarde spécifié.
- 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.
- Vérifiez que toutes les sauvegardes de base de données sont à l’état Restauré dans la page des détails de la supervision.
- 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
Important
Les migrations en ligne avec l’extension Azure SQL utilisent la même technologie que le service de relecture des journaux (LRS) et présentent les mêmes limitations. Avant de migrer des bases de données vers le niveau de service Critique pour l’entreprise, tenez compte de ces limitations, qui ne s’appliquent pas au niveau de service Usage général.
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 un dossier racine du conteneur), et les dossiers ne peuvent pas être imbriqués, car cela n’est pas pris 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.
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 effectuez une migration vers une instance managée SQL dans le niveau de service Critique pour l’entreprise, tenez compte du délai de mise en ligne des bases de données sur le réplica principal pendant qu’elles sont synchronisées avec les réplicas secondaires. Cela est particulièrement vrai pour les bases de données plus volumineuses. S’il est important que les bases de données soient disponibles dès la fin du basculement, tenez compte des solutions de contournement suivantes :
Migrez d’abord vers le niveau de service Usage général, puis effectuez une mise à niveau vers le niveau de service critique pour les entreprises. La mise à niveau de votre niveau de service est une opération en ligne qui conserve vos bases de données en ligne jusqu’à un basculement court comme étape finale de l’opération de mise à niveau.
Utilisez le lien Managed Instance pour une migration en ligne vers une instance critique pour l’entreprise sans avoir à attendre que les bases de données soient disponibles après le basculement.
Si vous avez reçu l’erreur suivante :
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û à la conception. L’OLTP en mémoire n’est pas prise en charge au niveau du service Usage général d’Azure SQL Managed Instance. Pour poursuivre la migration, une méthode consiste à effectuer une mise à niveau vers le niveau critique pour l’entreprise qui prend en charge l’OLTP en mémoire. 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.