Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
S’applique à :Azure SQL Managed Instance
Dans ce guide, vous apprendrez à migrer vos bases de données utilisateur de SQL Server vers Azure SQL Managed Instance.
Effectuez les étapes de pré-migation avant de continuer.
Migrer
Une fois que vous avez terminé les étapes de la phase de pré-migration, vous êtes prêt à effectuer la migration des schémas et des données.
Migrez les données à l’aide de la méthode de migration de votre choix.
Cette section fournit des étapes de migration générales pour les options de migration recommandées suivantes :
- Lien d'instance gérée
- Service LRS
- Native
RESTORE DATABASE FROM URL, qui utilise des sauvegardes natives à partir de SQL Server et nécessite un temps d’arrêt - Azure Database Migration Service (DMS), qui offre une migration avec un temps d’arrêt quasi nul
- Migration SQL Server dans Azure Arc
SQL Managed Instance cible les scénarios utilisateur qui nécessitent une migration de base de données en masse à partir d’implémentations locales ou SQL Server sur des machines virtuelles Azure. Il s’agit du choix optimal lorsque vous devez lever et déplacer le back-end des applications qui utilisent régulièrement les fonctionnalités de niveau d’instance et entre bases de données. Si cela correspond à votre scénario, vous pouvez déplacer toute une instance vers un environnement correspondant dans Azure sans devoir redéfinir l’architecture de vos applications.
Pour déplacer des instances SQL Server, vous devez planifier attentivement :
- La migration de toutes les bases de données qui ont besoin d’être colocalisées (celles qui s’exécutent sur la même instance).
- La migration d’objets au niveau de l’instance dont dépend votre application, notamment les connexions, les informations d’identification, les travaux et les opérateurs SQL Server Agent et les déclencheurs au niveau du serveur.
SQL Managed Instance est un service managé qui vous permet de déléguer certaines des activités d’administration de base de données régulières à la plateforme à mesure qu’elles sont intégrées. Par conséquent, vous n’avez pas besoin de migrer certaines données au niveau de l’instance, telles que les travaux de maintenance pour les sauvegardes régulières ou la configuration Always On, car la haute disponibilité est intégrée.
Migration de base de données
Migrez votre serveur SQL Server activé par l’instance Azure Arc vers Azure SQL Managed Instance directement via le portail Azure. Pour obtenir des instructions détaillées, consultez Migrer l’instance SQL Server vers Azure SQL Managed Instance.
La migration de base de données offre une expérience de migration intégrée, en utilisant le lien Managed Instance ou les méthodes LRS (Log Replay Service) en arrière-plan, tout en simplifiant la configuration, la gestion et la surveillance du processus de migration.
Lien d'instance gérée
Cette section fournit des étapes essentielles pour migrer de SQL Server vers Azure SQL Managed Instance avec un temps d’arrêt minimal à l’aide du lien Managed Instance. Pour obtenir des instructions détaillées, consultez Migrer avec le lien.
Pour migrer avec le lien, procédez comme suit :
- Créez votre instance managée SQL cible : portail Azure, PowerShell, Azure CLI.
- Préparez votre environnement en vue de la liaison.
- Configurez la liaison avec SSMS ou les scripts.
- Arrêtez la charge de travail.
- Validez les données sur l’instance cible.
- Lien de basculement.
Service LRS
Cette section fournit des étapes générales pour migrer de SQL Server vers SQL Managed Instance avec un temps d’arrêt minimal à l’aide du service Log Replay (LRS). Pour obtenir des instructions détaillées, consultez Migrer des bases de données à partir de SQL Server à l’aide de Log Replay Service.
Pour migrer avec LRS, procédez comme suit :
- Créez un compte de stockage Azure avec un conteneur d’objets blob.
- Authentifiez-vous auprès de votre compte de stockage Blob à l’aide d’un jeton SAP ou d’une identité managée et validez l’accès.
- Veillez à configurer correctement votre structure de dossiers si vous envisagez de migrer plusieurs bases de données.
- Chargez vos sauvegardes sur votre compte de stockage en copiant vos sauvegardes ou en effectuant des sauvegardes directement à l’aide de l’URL BACKUP TO.
- Déterminez si vous souhaitez exécuter LRS en mode autocomplétion ou continu.
- Démarrez LRS.
- Supervisez la progression de la migration.
- Terminez la migration (si elle est en mode continu).
Sauvegarde et restauration
Une fonctionnalité clé de SQL Managed Instance est la possibilité de restaurer en mode natif des fichiers de sauvegarde.bak de base de données () stockés dans stockage Azure. Cette fonctionnalité simplifie la migration de base de données. La sauvegarde et la restauration sont des opérations asynchrones, en fonction de la taille de votre base de données.
Le diagramme suivant fournit une vue d’ensemble du processus :
Remarque
Le temps nécessaire pour effectuer la sauvegarde, le charger dans le stockage Azure et effectuer une opération de restauration native sur SQL Managed Instance dépend de la taille de la base de données. Prévoir un temps d'arrêt suffisant pour permettre l'opération sur les bases de données volumineuses.
Le tableau suivant fournit plus d’informations sur les méthodes que vous pouvez utiliser, en fonction de la version source de SQL Server que vous exécutez :
| Étape | Moteur SQL et version | Méthode de sauvegarde/restauration |
|---|---|---|
| Placer la sauvegarde sur le stockage Azure | Avant 2012 avec Service Pack 1 CU2 | Charger le fichier .bak directement sur le stockage Azure |
| 2012 SP1 CU2 - 2016 | Sauvegarde directe utilisant la syntaxe WITH CREDENTIAL dépréciée | |
| 2016 et versions ultérieures | Sauvegarde directe utilisant WITH SAS CREDENTIAL | |
| Restaurer à partir du stockage Azure vers une instance managée | RESTORE FROM URL avec SAS CREDENTIAL |
Importante
Lorsque vous migrez une base de données protégée par le chiffrement transparent des données (TDE) vers une instance managée SQL à l’aide de l’option de restauration native, vous devez migrer le certificat correspondant à partir de l’instance SQL Server (locale ou SQL Server sur une machine virtuelle Azure) avant de restaurer la base de données. Pour plus d’informations, consultez Migrer un certificat d’une base de données protégée par TDE vers Azure SQL Managed Instance.
La restauration des bases de données système n’est pas prise en charge. Pour migrer des objets au niveau de l’instance (stockés dans master ou msdb bases de données), exécutez des scripts Transact-SQL (T-SQL) sur l’instance de destination.
Pour effectuer une migration à l’aide de la fonctionnalité de sauvegarde et restauration, suivez les étapes ci-dessous :
Sauvegardez votre base de données sur le Stockage Blob Azure. Par exemple, utilisez la fonctionnalité de sauvegarde vers une URL dans SQL Server Management Studio. Utilisez l’outil Microsoft Azure pour prendre en charge les bases de données antérieures à SQL Server 2012 avec Service Pack 1 CU2.
Connectez-vous à votre instance managée SQL à l’aide de SQL Server Management Studio (SSMS).
Créez des informations d’identification à l’aide d’une signature d’accès partagé pour accéder à votre compte Stockage Blob Azure avec vos sauvegardes de base de données. Par exemple :
CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases] WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = '<secret>'Restaurez la sauvegarde à partir du conteneur Azure Storage Blob. Par exemple :
RESTORE DATABASE [TargetDatabaseName] FROM URL = 'https://mitutorials.blob.core.windows.net/databases/WideWorldImporters-Standard.bak'Une fois la restauration terminée, affichez la base de données dans l’Explorateur d’objets dans SSMS.
Pour en savoir plus sur cette option de migration, consultez Démarrage rapide : restaurer une base de données dans Azure SQL Managed Instance avec SSMS.
Remarque
Une opération de restauration de base de données est asynchrone et peut être retentée. Vous risquez d’obtenir une erreur dans SSMS si la connexion s’arrête ou si un délai d’expiration expire. Azure SQL Database tente de restaurer la base de données en arrière-plan et vous pouvez suivre la progression de la restauration à l’aide des vues sys.dm_exec_requests et sys.dm_operation_status .
Azure Database Migration Service (Azure DMS)
Cette section fournit des étapes générales pour migrer de SQL Server vers SQL Managed Instance avec un temps d’arrêt minimal à l’aide d’Azure DMS. Pour plus d’informations, consultez Tutoriel : Migrer SQL Server vers Azure SQL Managed Instance en ligne.
Pour migrer à l’aide de DMS à partir du portail Azure, procédez comme suit :
Ouvrez le portail Azure.
Ouvrez Azure DMS et sélectionnez l’instance DMS si vous en avez déjà créé un, ou créez-en une.
Dans le tableau de bord de l’instance DMS, sélectionnez Démarrer la migration, choisissez votre type de serveur source, définissez votre type de serveur cible sur Azure SQL Managed Instance, puis sélectionnez l’emplacement de stockage du fichier de sauvegarde de migration et le mode de migration.
Fournissez les détails de suivi SQL Server source pour Azure, tels que l’abonnement, le groupe de ressources, l’emplacement et le nom de l’instance SQL Server. Cette étape crée une instance SQL Server activée par Azure Arc.
Fournissez l’abonnement cible et le groupe de ressources, puis choisissez l’instance managée SQL cible.
Fournissez les détails de l’emplacement de sauvegarde, tels que le groupe de ressources, le compte de stockage, le conteneur d’objets blob, le dossier, le dernier fichier de sauvegarde (pour le mode de migration hors connexion) et la base de données cible.
Facultatif : Si vos sauvegardes se trouvent sur un partage réseau local, téléchargez et installez le runtime d’intégration auto-hébergé sur une machine qui peut se connecter au serveur SQL Server source et à l’emplacement contenant les fichiers de sauvegarde.
Vous devrez peut-être fournir les détails et les informations d’identification de l’instance SQL Server source pour vous y connecter.
En outre, sélectionnez les bases de données et l’emplacement du partage de fichiers SMB réseau où les fichiers de sauvegarde sont conservés et les informations d’identification pour se connecter à celui-ci.
Démarrez la migration de base de données et surveillez la progression dans le portail Azure à partir de votre tableau de bord de supervision d’instance DMS.
Effectuez 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 les sauvegardes du journal de fin pour la base de données source à l’emplacement de sauvegarde spécifié.
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.
Pour obtenir des instructions détaillées, consultez Tutoriel : Migrer SQL Server vers Azure SQL Managed Instance avec DMS.
Pour migrer à l’aide de DMS avec Azure Data Studio, procédez comme suit :
Téléchargez et installez Azure Data Studio et l’extension de migration Azure SQL pour Azure Data Studio.
Lancez Migrer vers Azure SQL dans l’Assistant Migration Azure SQL de l’extension dans Azure Data Studio.
Sélectionnez des bases de données pour évaluation, et consultez l’état de préparation ou les problèmes de la migration (le cas échéant). Collectez aussi des données de performances et obtenez une recommandation Azure pour une taille appropriée.
Sélectionnez votre compte Azure et votre instance managée Azure SQL cible à partir de votre abonnement.
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 Stockage Blob Azure.
Créez une instance Azure DMS à l’aide de l’Assistant dans Azure Data Studio. Si vous avez précédemment créé une instance DMS à l’aide d’Azure Data Studio, vous pouvez réutiliser la même instance si vous le souhaitez.
Facultatif : si vos sauvegardes se trouvent sur un partage réseau local, téléchargez et installez le runtime d’intégration auto-hébergé sur un ordinateur qui peut se connecter à l’instance SQL Server source et l’emplacement contenant les fichiers de sauvegarde.
Démarrez la migration de la base de données et surveillez la progression dans Azure Data Studio. Vous pouvez également surveiller la progression sous la ressource DMS dans le portail Azure.
Effectuez 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 les sauvegardes du journal de fin pour la base de données source à l’emplacement de sauvegarde spécifié.
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.
Migration SQL Server dans Azure Arc
Migrez des instances SQL Server activées par Azure Arc vers SQL Managed Instance via le portail Azure. SQL Managed Instance fournit une solution PaaS entièrement managée pour les migrations lift-and-shift. Le processus inclut l’évaluation de la préparation, la sélection d’une cible, la migration des données et la progression de la surveillance.
Deux méthodes intégrées sont disponibles :
Lien Managed Instance pour la réplication en quasi temps réel avec un temps d’arrêt minimal,
Service Log Replay pour la sauvegarde et la restauration continues.
Microsoft Copilot aide tout au long de la migration. La migration prend en charge SQL Server 2012 et versions ultérieures et automatise la plupart des étapes.
Pour plus d’informations, consultez Migration vers Azure SQL Managed Instance - Migration sql Server dans Azure Arc.
Synchronisation des données et basculement
Lorsque vous utilisez des options de migration qui répliquent ou synchronisent en continu les modifications de données de la source vers la cible, les données sources et le schéma peuvent changer et dériver de la cible. Pendant la synchronisation des données, assurez-vous que le processus de migration capture et applique toutes les modifications sur la source à la cible.
Une fois que vous avez vérifié que les données sont identiques sur la source et la cible, vous pouvez effectuer le basculement de l’environnement source vers l’environnement cible. Planifiez le processus de basculement avec les équipes métier et d’applications pour garantir une interruption minimale pendant le basculement et qu’il n’affecte pas la continuité de l’activité.
Importante
Pour plus d’informations sur les étapes spécifiques associées à l’exécution d’un basculement dans le cadre de migrations à l’aide du service DMS, consultez Exécution du basculement de migration.
Postmigration
Une fois que vous avez réussi la phase de migration, vous devez effectuer toute une série de tâches post-migration pour vérifier que tout fonctionne de manière fluide et efficace.
La phase postmigration est cruciale pour résoudre les problèmes de justesse et d’exhaustivité des données ainsi que pour gérer les problèmes de performances liés à la charge de travail.
Surveiller et corriger les applications
Après avoir migré vers une instance managée SQL, suivez le comportement et les performances de l’application de votre charge de travail. Ce processus comporte les activités suivantes :
- Comparer les performances de la charge de travail s’exécutant sur l’instance Managed Instance avec celles du référentiel de performance que vous avez créé sur l’instance SQL Server source.
- Surveillez en permanence les performances de votre charge de travail pour identifier les problèmes potentiels et les améliorations.
Effectuer des tests
L’approche de test pour la migration de base de données comprend les activités suivantes :
Développer des tests de validation : pour tester la migration de base de données, utilisez des requêtes T-SQL. Créez les requêtes de validation à exécuter sur les bases de données source et cible. Vos requêtes de validation doivent couvrir l’étendue que vous avez définie.
Configurer un environnement de test: l’environnement de test doit contenir une copie de la base de données source et de la base de données cible. Veillez à isoler l’environnement de test.
Exécuter des tests de validation : exécutez les tests de validation sur la source et la cible, puis analysez les résultats.
Exécuter des tests de performances : exécutez des tests de performances sur la source et la cible, puis analysez et comparez les résultats.
Utiliser des fonctionnalités avancées
Tirez parti des fonctionnalités avancées basées sur le cloud offertes par SQL Managed Instance, telles que la haute disponibilité intégrée, la détection des menaces et la surveillance et le réglage de votre charge de travail.
Azure SQL Analytics vous permet de surveiller un grand ensemble d’instances managées SQL de manière centralisée.
Certaines fonctionnalités de SQL Server sont disponibles uniquement lorsque vous modifiez le niveau de compatibilité de la base de données en niveau de compatibilité le plus récent.
Contenu connexe
- Services et outils disponibles pour les scénarios de migration de données
- Niveaux de service dans Azure SQL Managed Instance
- Différences T-SQL entre SQL Server et Azure SQL Managed Instance
- Migrer des bases de données avec l’extension de migration Azure SQL pour Azure Data Studio
- Tutoriel : Migrer SQL Server vers Azure SQL Managed Instance avec DMS
- Cloud Adoption Framework pour Azure
- Meilleures pratiques pour l’évaluation des coûts et le dimensionnement des charges de travail migrées vers Azure