Préparer l’environnement pour une migration de lien Managed Instance - Migration de SQL Server dans Azure Arc

S'applique à :SQL Server

Cet article vous aide à préparer votre environnement pour une migration de lien Managed Instance de votre instance SQL Server activée par Azure Arc vers Azure SQL Managed Instance dans le portail Azure.

Avec le lien, vous pouvez migrer vos bases de données SQL Server vers Azure SQL Managed Instance à l’aide de la réplication en temps réel avec un groupe de disponibilité distribué (migration en ligne) :

Diagramme montrant la migration de liens Managed Instance.

Note

Vous pouvez fournir des commentaires sur votre expérience de migration directement vers le groupe de produits.

Prerequisites

Pour migrer vos bases de données SQL Server vers Azure SQL Managed Instance via le portail Azure, vous avez besoin des prérequis suivants :

Un abonnement Azure actif. Si vous n’en avez pas, créez un compte gratuit.
Instance prise en charge de SQL Server activée par Azure Arc avec l’extension Azure pour la version de SQL Server ou une version 1.1.3238.349 ultérieure. Vous pouvez mettre à niveau votre extension à l’aide du portail Azure ou d’Azure CLI.

Versions de SQL Server prises en charge

Les niveaux de service Usage général et Critique pour l’entreprise d’Azure SQL Managed Instance prennent en charge le lien Managed Instance. La migration avec la fonctionnalité de liaison fonctionne avec les éditions Enterprise, Developer et Standard de SQL Server sur Windows Server.

Le tableau suivant répertorie les versions minimales de SQL Server prises en charge pour le lien :

Version de SQL Server	Mise à jour minimale de maintenance requise
SQL Server 2025 (17.x)	SQL Server 2025 RTM (17.0.1000.7)
SQL Server 2022 (16.x)	SQL Server 2022 RTM (16.0.1000.6)
SQL Server 2019 (15.x)	SQL Server 2019 CU20 (15.0.4312.2)
SQL Server 2017 (14.x)	SQL Server 2017 CU31 (14.0.3456.2) ou version ultérieure et la version correspondante du pack Sql Server 2017 Azure Connect (14.0.3490.10)
SQL Server 2016 (13.x)	SQL Server 2016 SP3 (13.0.6300.2) et le pack SQL Server 2016 Azure Connect correspondant (13.0.7000.253)
SQL Server 2014 (12.x) et versions antérieures	Les versions antérieures à SQL Server 2016 ne sont pas prises en charge.

La migration inverse est prise en charge uniquement vers SQL Server 2025 et SQL Server 2022 à partir d’instances managées SQL avec la stratégie de mise à jour correspondante. Vous pouvez inverser manuellement une migration via d’autres outils tels que la sauvegarde et la restauration natives, ou configurer manuellement un lien dans SSMS.

Permissions

Cette section décrit les autorisations dont vous avez besoin pour migrer votre instance SQL Server vers SQL Managed Instance via le portail Azure.

Sur l’instance SQL Server source, vous avez besoin des autorisations suivantes :

Si vous activez le privilège minimum, les autorisations nécessaires telles que sysadmin sont accordées selon les besoins pendant le processus de migration de base de données.
Si vous ne pouvez pas utiliser le privilège minimum, la personne qui effectue la migration a besoin d’autorisations sysadmin sur l’instance SQL Server source. En outre, si vous devez annuler une migration, attribuez également manuellement des autorisations sysadmin au NT AUTHORITY\SYSTEM compte.

Pour migrer avec le lien Managed Instance, vous avez besoin de l’une des autorisations suivantes sur la cible SQL Managed Instance :

Rôle de Contributeur SQL Managed Instance
Rôle Contributeur ou Propriétaire au niveau de l’abonnement

Pour obtenir des autorisations minimales, consultez Autorisations personnalisées.

Note

Les utilisateurs disposant des autorisations SqlServerAvailabilityGroups_CreateManagedInstanceLink, SqlServerAvailabilityGroups_failoverMiLink et SqlServerAvailabilityGroups_deleteMiLink dans Azure peuvent effectuer des actions dans le volet de migration de base de données pendant le processus de migration qui élèvent les autorisations SQL Server du compte utilisé par l’extension, y compris le rôle sysadmin.

Préparer votre instance SQL Server

Pour préparer votre instance SQL Server, procédez comme suit :

Vérifiez que vous êtes sur la version prise en charge.
Créez une clé principale de base de données dans la master base de données.
Activez la fonctionnalité groupes de disponibilité.
Ajoutez les indicateurs de trace appropriés au démarrage.
Redémarrez SQL Server et validez la configuration.
Configurer la base de données sur le modèle de récupération complète.
Importez des clés d’autorité de certification racine approuvées par Azure dans SQL Server.

Vous devez redémarrer SQL Server pour que ces modifications prennent effet.

Installer des mises à jour du service

Assurez-vous que la version de SQL Server dispose de la mise à jour appropriée installée, comme indiqué dans la table de compatibilité de version. Si vous devez installer des mises à jour, vous devez redémarrer votre instance SQL Server pendant la mise à jour.

Pour vérifier votre version de SQL Server, exécutez le script Transact-SQL (T-SQL) suivant sur SQL Server :

-- Run on SQL Server
-- Shows the version and CU of the SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';

Créer une clé principale de base de données dans la base de données master

Le lien utilise des certificats pour chiffrer l’authentification et la communication entre SQL Server et SQL Managed Instance. La clé principale de base de données protège les certificats utilisés par le lien. Si vous disposez déjà d’une clé principale de base de données, vous pouvez ignorer cette étape.

Créez une clé principale de base de données dans la master base de données. Insérez votre mot de passe à la place de <strong_password> dans le script suivant et conservez-le dans un lieu confidentiel et sûr. Exécutez ce script T-SQL sur SQL Server :

-- Run on SQL Server
-- Create a master key
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>';

Pour vérifier que vous disposez de la clé principale de base de données, utilisez le script T-SQL suivant sur SQL Server :

-- Run on SQL Server
USE master;
GO
SELECT * FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%';

Préparer des instances SQL Server 2016

Pour SQL Server 2016 (13.x), vous devez suivre les étapes supplémentaires décrites dans les prérequis de préparation de SQL Server 2016 pour le lien. Ces étapes supplémentaires ne sont pas requises pour SQL Server 2017 (14.x) et les versions ultérieures prises en charge par le lien.

Activer des groupes de disponibilité

La fonction de liaison repose sur la fonction de groupes de disponibilité Always On, qui est désactivée par défaut. Pour plus d’informations, consultez Activer la fonctionnalité Groupes de disponibilité AlwaysOn.

Pour confirmer que la fonctionnalité de groupes de disponibilité est activée, exécutez le script T-SQL suivant sur SQL Server :

-- Run on SQL Server
-- Is the availability groups feature enabled on this SQL Server
DECLARE @IsHadrEnabled sql_variant = (select SERVERPROPERTY('IsHadrEnabled'))
SELECT
    @IsHadrEnabled as 'Is HADR enabled',
    CASE @IsHadrEnabled
        WHEN 0 THEN 'Availability groups DISABLED.'
        WHEN 1 THEN 'Availability groups ENABLED.'
        ELSE 'Unknown status.'
    END
    as 'HADR status'

Si la fonctionnalité de groupes de disponibilité n’est pas activée, procédez comme suit pour l’activer :

Ouvrez Gestionnaire de configuration SQL Server.
Sélectionnez Services SQL Server dans le volet gauche.
Cliquez avec le bouton droit sur le service SQL Server, puis sélectionnez Propriétés :
Accédez à l’onglet Groupes de disponibilité Always On.
Cochez la case Activer les groupes de disponibilité Always On , puis sélectionnez OK.
- Si vous utilisez SQL Server 2016 (13.x) et que l’option Activer les groupes de disponibilité Always On est désactivée avec le message This computer is not a node in a failover cluster, suivez les étapes décrites dans Préparer les prérequis de SQL Server 2016 pour le lien. Une fois ces étapes terminées, revenez à cette étape et réessayez.
Sélectionnez OK dans la boîte de dialogue.
Redémarrez le service SQL Server.

Activer les indicateurs de trace de démarrage

Pour optimiser les performances de votre lien, activez les indicateurs de trace suivants au démarrage :

-T1800: cet indicateur de trace optimise les performances lorsque les fichiers de journal pour les réplicas primaire et secondaire d’un groupe de disponibilité se trouvent sur des disques avec des tailles de secteur différentes, par exemple 512 octets et 4 Ko. Si les réplicas principaux et secondaires utilisent une taille de secteur de disque de 4 Ko, vous n’avez pas besoin de cet indicatif de trace. Pour plus d’informations, consultez l’article KB3009974 de la Base de connaissances.
-T9567 : cet indicateur de trace active la compression du flux de données pour les groupes de disponibilité au cours de l’amorçage automatique. La compression augmente la charge sur le processeur, mais peut réduire considérablement le temps de transfert pendant l’amorçage.

Pour activer ces indicateurs de trace au démarrage, effectuez les étapes suivantes :

Ouvrez le Gestionnaire de configuration SQL Server.
Sélectionnez Services SQL Server dans le volet gauche.
Cliquez avec le bouton droit sur le service SQL Server, puis sélectionnez Propriétés.
Accédez à l’onglet Paramètres de démarrage. Dans Spécifier un paramètre de démarrage, entrez -T1800, puis sélectionnez Ajouter pour ajouter le paramètre de démarrage. Ensuite, entrez -T9567 et sélectionnez Ajouter pour ajouter l’autre indicateur de trace. Sélectionnez Appliquer pour enregistrer vos modifications.
Cliquez sur OK pour fermer la fenêtre Propriétés.

Pour en savoir plus, reportez-vous à la syntaxe permettant d’activer les indicateurs de trace.

Redémarrer SQL Server et valider la configuration

Si vous n’avez pas besoin de mettre à niveau la version de SQL Server, activez la fonctionnalité de groupe de disponibilité ou ajoutez des indicateurs de trace de démarrage, vous pouvez ignorer cette section.

Après avoir vérifié que vous êtes sur une version prise en charge de SQL Server, activez la fonctionnalité groupes de disponibilité Always On et ajoutez vos indicateurs de trace de démarrage, redémarrez votre instance SQL Server pour appliquer toutes ces modifications :

Ouvrez Gestionnaire de configuration SQL Server.
Sélectionnez Services SQL Server dans le volet gauche.
Cliquez avec le bouton droit sur le service SQL Server, puis sélectionnez Redémarrer.

Après le redémarrage, exécutez le script T-SQL suivant sur SQL Server pour valider la configuration de votre instance de SQL Server :

-- Run on SQL Server
-- Shows the version and CU of SQL Server
USE master;
GO
SELECT @@VERSION as 'SQL Server version';
GO
-- Shows if the Always On availability groups feature is enabled
SELECT SERVERPROPERTY ('IsHadrEnabled') as 'Is Always On enabled? (1 true, 0 false)';
GO
-- Lists all trace flags enabled on SQL Server
DBCC TRACESTATUS;

Votre version de SQL Server doit être l’une des versions prises en charge avec les mises à jour de service appropriées appliquées. La fonctionnalité groupes de disponibilité Always On doit être activée et les -T1800-T9567 indicateurs de trace doivent être activés. La capture d’écran suivante illustre le résultat attendu d’une instance SQL Server correctement configurée :

Capture d’écran montrant le résultat attendu dans SSMS.

Définir la base de données sur un modèle de récupération complète

Les bases de données migrées via le lien doivent se trouver dans le modèle de récupération complète et avoir au moins une sauvegarde.

Exécutez le code suivant sur SQL Server pour toutes les bases de données que vous souhaitez migrer. Remplacez <DatabaseName> par le nom de votre base de données.

-- Run on SQL Server
-- Set full recovery model for all databases you want to migrate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to migrate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Importer des clés d’autorité de certification racine approuvée par Azure dans SQL Server

Pour approuver les certificats de clé publique SQL Managed Instance qu’Azure émet, vous devez importer des clés d’autorité de certification racine approuvées par Azure dans SQL Server.

Vous pouvez télécharger les clés d’autorité de certification racine à partir des détails de l’autorité de certification Azure. Au minimum, téléchargez les certificats DigiCert Global Root G2 et Microsoft RSA Root Certificate Authority 2017 et importez-les dans votre instance SQL Server.

Note

Le certificat racine dans le chemin de certification d’un certificat de clé publique SQL Managed Instance est émis par une autorité de certification racine approuvée Azure. L’autorité de certification racine spécifique peut changer au fil du temps, car Azure met à jour sa liste d’autorité de certification approuvée. Pour une configuration simplifiée, installez tous les certificats d’autorité de certification racine répertoriés dans les autorités de certification racine Azure. Vous pouvez installer uniquement la clé d’autorité de certification requise en identifiant l’émetteur d’une clé publique SQL Managed Instance précédemment importée.

Enregistrez les certificats locaux dans l’instance SQL Server, par exemple dans l’exemple C:\certs\<name of certificate>.crt de chemin d’accès, puis importez les certificats à partir de ce chemin à l’aide du script Transact-SQL suivant. Remplacez <name of certificate> par le nom de certificat réel : DigiCert Global Root G2 et Microsoft RSA Root Certificate Authority 2017, qui sont les noms requis pour ces deux certificats.

-- Run on SQL Server-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
CREATE CERTIFICATE [DigiCertPKI] FROM FILE = 'C:\certs\DigiCertGlobalRootG2.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('DigiCertPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO
CREATE CERTIFICATE [MicrosoftPKI] FROM FILE = 'C:\certs\Microsoft RSA Root Certificate Authority 2017.crt'
DECLARE @CERTID int
SELECT @CERTID = CERT_ID('MicrosoftPKI')
EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net';
GO

Conseil / Astuce

Si la sp_certificate_add_issuer procédure stockée est manquante dans votre environnement SQL Server, votre instance SQL Server n’a probablement pas installé la mise à jour de service appropriée.

Enfin, vérifiez tous les certificats créés à l’aide de la vue de gestion dynamique suivante (DMV) :

-- Run on SQL Server
USE master
SELECT * FROM sys.certificates

Configurer la connectivité réseau

Pour que la liaison fonctionne, vous devez disposer d’une connectivité réseau entre SQL Server et SQL Managed Instance. L’option de réseau que vous choisissez dépend du fait que votre instance SQL Server se trouve ou non sur un réseau Azure.

SQL Server en dehors d’Azure

Si vous hébergez votre instance SQL Server en dehors d’Azure, vous pouvez établir une connexion VPN entre SQL Server et SQL Managed Instance à l’aide de l’une des options suivantes :

Conseil / Astuce

Pour obtenir les meilleures performances réseau lors de la réplication de données, utilisez ExpressRoute. Provisionnez une passerelle avec assez de bande passante pour votre cas d’usage.

SQL Server sur les machines virtuelles Azure

Le déploiement de SQL Server sur des machines virtuelles Azure dans le même réseau virtuel Azure qui héberge SQL Managed Instance est la méthode la plus simple, car la connectivité réseau existe automatiquement entre les deux instances. Pour plus d’informations, consultez Démarrage rapide : Configurer une machine virtuelle Azure pour qu’elle se connecte à Azure SQL Managed Instance.

Si votre instance SQL Server sur des machines virtuelles Azure se trouve dans un réseau virtuel différent de votre instance managée SQL, vous devez connecter les deux réseaux virtuels. Les réseaux virtuels n’ont pas besoin d’être dans le même abonnement pour que ce scénario fonctionne.

Vous avez deux options pour connecter des réseaux virtuels :

Appairage de réseaux virtuels Azure
Passerelle VPN de réseau virtuel à réseau virtuel (portail Azure, PowerShell, Azure CLI)

Le peering est préférable, car il utilise le réseau principal Microsoft. Par conséquent, du point de vue de la connectivité, il n'y a aucune différence notable de latence entre les machines virtuelles dans un réseau virtuel appairé et celles dans le même réseau virtuel. Le couplage de réseaux virtuels est pris en charge entre les réseaux de la même région. L’appairage de réseaux virtuels global est pris en charge pour les instances hébergées dans des sous-réseaux créés après le 22 septembre 2020. Pour plus d’informations, consultez la Foire aux questions (FAQ).

Ports réseau entre les environnements

Quel que soit le mécanisme de connectivité, vous devez répondre aux exigences suivantes pour que le trafic réseau circule entre les environnements :

Les règles de groupe de sécurité réseau (NSG) sur le sous-réseau qui héberge SQL Managed Instance doivent autoriser :

Port entrant 5022 et plage de ports 11000-11999 pour recevoir le trafic à partir de l’adresse IP SQL Server source
Port sortant 5022 pour envoyer le trafic à l’adresse IP sql Server de destination

Le port 5022 ne peut pas être modifié sur SQL Managed Instance.

Tous les pare-feu sur le réseau qui héberge SQL Server et le système d’exploitation hôte doivent autoriser :

Port entrant 5022 ouvert pour recevoir le trafic à partir de la plage IP source du sous-réseau MI /24 (par exemple 10.0.0.0/24)
Ports sortants 5022 et plage de ports 11000-11999 ouverts pour envoyer le trafic vers la plage IP de destination du sous-réseau MI (exemple 10.0.0.0/24)

Le port 5022 peut être personnalisé côté SQL Server, mais la plage de ports 11000-11999 doit être ouverte telle quelle.

Le tableau suivant décrit les actions de port pour chaque environnement :

Environnement	Procédure à suivre
SQL Server (en dehors d’Azure)	Ouvrez le trafic entrant et sortant sur le port 5022 pour le pare-feu réseau vers la plage d’adresses IP de sous-réseau entière de SQL Managed Instance. Si nécessaire, effectuez la même opération sur le pare-feu Windows du système d’exploitation hôte SQL Server.
SQL Server (dans Azure)	Ouvrez le trafic entrant et sortant sur le port 5022 pour le pare-feu réseau vers la plage d’adresses IP de sous-réseau entière de SQL Managed Instance. Si nécessaire, effectuez la même opération sur le pare-feu Windows du système d’exploitation hôte SQL Server. Pour autoriser la communication sur le port 5022, créez une règle de groupe de sécurité réseau (NSG) dans le réseau virtuel qui héberge la machine virtuelle.
Instance managée SQL	Créez une règle de groupe de sécurité réseau dans le portail Azure pour autoriser le trafic entrant et sortant à partir de l’adresse IP et la mise en réseau qui héberge SQL Server sur le port 5022 et la plage de ports 11000-11999.

Pour ouvrir des ports dans le Pare-feu Windows, utilisez le script PowerShell suivant sur le système d’exploitation hôte Windows de l’instance SQL Server :

New-NetFirewallRule -DisplayName "Allow TCP port 5022 inbound" -Direction inbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP
New-NetFirewallRule -DisplayName "Allow TCP port 5022 outbound" -Direction outbound -Profile Any -Action Allow -LocalPort 5022 -Protocol TCP

Le diagramme suivant illustre un exemple d’environnement réseau local, indiquant que tous les pare-feu de l’environnement doivent avoir des ports ouverts, y compris le pare-feu du système d’exploitation qui héberge l’instance SQL Server et tous les pare-feu et passerelles d’entreprise :

Important

Vous devez ouvrir des ports dans chaque pare-feu dans l’environnement de mise en réseau, y compris le serveur hôte, ainsi que tous les pare-feu ou passerelles d’entreprise sur le réseau. Dans les entreprises, il se peut que vous deviez montrer à votre administrateur réseau les informations de cette section pour l’aider à ouvrir des ports supplémentaires dans la couche réseau de l’entreprise.
Bien que vous puissiez choisir de personnaliser le point de terminaison côté SQL Server, vous ne pouvez pas modifier ni personnaliser les numéros de port pour SQL Managed Instance.
Les plages d’adresses IP des sous-réseaux hébergeant les instances managées et SQL Server ne doivent pas se chevaucher.

Ajouter des URL à la liste d’autorisation

Selon vos paramètres de sécurité réseau, vous devrez peut-être ajouter des URL à votre liste d'autorisation pour le FQDN de SQL Managed Instance et certains des points de terminaison de gestion des ressources d'Azure.

Ajoutez les ressources suivantes à votre liste verte :

Nom de domaine complet (FQDN) de votre SQL Managed Instance. Par exemple : managedinstance.a1b2c3d4e5f6.database.windows.net.
Autorité Microsoft Entra
ID de la ressource du point de terminaison Microsoft Entra
Point de terminaison Resource Manager
Point de terminaison de service

Suivez les étapes de la section Configurer SSMS pour les clouds gouvernementaux pour accéder à l’interface Outils dans SQL Server Management Studio (SSMS) et identifier des URL spécifiques pour les ressources de votre cloud que vous devez ajouter à votre liste verte.

Migrer un certificat d’une base de données protégée par TDE (facultatif)

Si vous liez une base de données SQL Server protégée par Transparent Data Encryption (TDE) à une instance managée SQL, vous devez migrer le certificat de chiffrement correspondant de l’instance SQL Server locale ou de machine virtuelle Azure vers l’instance managée SQL avant d’utiliser le lien. Pour des étapes détaillées, consultez Migrer vers Azure SQL Managed Instance un certificat d’une base de données protégée par TDE.

Les bases de données SQL Managed Instance qui sont chiffrées avec des clés TDE managées par le service ne peuvent pas être liées à SQL Server. Vous ne pouvez lier une base de données chiffrée qu’à SQL Server si vous l’avez chiffrée avec une clé gérée par le client et que le serveur de destination a accès à la même clé utilisée pour chiffrer la base de données. Pour plus d’informations, consultez Configurer SQL Server TDE avec Azure Key Vault.

Note

Azure Key Vault est pris en charge par SQL Server sur Linux à partir de la mise à jour cumulative 14 pour SQL Server 2022.

Tester la connectivité réseau

Avant de commencer la migration, testez la connectivité réseau entre votre instance SQL Server et SQL Managed Instance. Vous pouvez tester la connectivité directement à partir du portail Azure dans le cadre du processus de migration. Toutefois, vous pouvez également tester la connectivité manuellement à l’aide de Transact-SQL et de SQL Server Agent. Pour plus d’informations, consultez Tester la connectivité réseau.

Pour tester la connectivité via le portail Azure, procédez comme suit :

Sélectionnez Migrer des données dans le volet Migration de base de données pour votre ressource d’instance SQL Server.
Sélectionnez l’option lien MI.
Sélectionnez les bases de données cibles que vous souhaitez migrer, puis utilisez Suivant : Paramètres pour accéder à l’onglet suivant.
Sous l’onglet Paramètres , indiquez le nom du lien et du groupe de disponibilité source. Utilisez ensuite test de connexion pour valider la connectivité réseau entre SQL Server et SQL Managed Instance :

Tenez compte des points suivants :

Pour éviter les faux négatifs, tous les pare-feu le long du chemin d’accès réseau doivent autoriser le trafic ICMP (Internet Control Message Protocol).
Pour éviter les faux positifs, tous les pare-feu le long du chemin réseau doivent autoriser le trafic sur le protocole UCS SQL Server propriétaire. Le blocage du protocole peut entraîner un test de connexion réussi, mais le lien ne parvient pas à créer.
Les configurations avancées de pare-feu avec des garde-fous au niveau des paquets doivent être correctement configurées pour autoriser le trafic entre SQL Server et SQL Managed Instance.

Limites

Tenez compte des limitations suivantes :

Les limitations du lien Managed Instance s’appliquent aux migrations via le portail Azure.
L’annulation d’une migration nécessite des autorisations sysadmin sur l’instance SQL Server source. Si votre instance SQL Server n’utilise pas de privilège minimum, attribuez manuellement des autorisations sysadmin au NT AUTHORITY\SYSTEM compte.
La configuration d’un lien via le portail Azure à des fins de migration n’est pas compatible avec les liens créés manuellement, via SQL Server Management Studio (SSMS) ou Transact-SQL (T-SQL). Passez en revue le problème connu pour en savoir plus.
La surveillance de la migration via le portail Azure est disponible uniquement pour les instances SQL Server qui répondent aux exigences de gestion des licences.

Résolution des problèmes courants

Pour résoudre les problèmes courants lors de la migration vers Azure SQL Managed Instance, consultez Résoudre les problèmes de migration.

Commentaires

Est-ce que cette page vous a été utile?

Last updated on 2025-12-12

Partage via

Préparer l’environnement pour une migration de lien Managed Instance - Migration de SQL Server dans Azure Arc

Prerequisites

Versions de SQL Server prises en charge

Permissions

Préparer votre instance SQL Server

Installer des mises à jour du service

Créer une clé principale de base de données dans la base de données master

Préparer des instances SQL Server 2016

Activer des groupes de disponibilité

Activer les indicateurs de trace de démarrage

Redémarrer SQL Server et valider la configuration

Définir la base de données sur un modèle de récupération complète

Importer des clés d’autorité de certification racine approuvée par Azure dans SQL Server

Configurer la connectivité réseau

SQL Server en dehors d’Azure

SQL Server sur les machines virtuelles Azure

Ports réseau entre les environnements

Ajouter des URL à la liste d’autorisation

Migrer un certificat d’une base de données protégée par TDE (facultatif)

Tester la connectivité réseau

Limites

Résolution des problèmes courants

Contenu connexe

Commentaires

Ressources supplémentaires