Préparer votre environnement pour un lien - Azure SQL Managed Instance

Applies to :Azure SQL Managed Instance

Cet article explique comment préparer votre environnement pour un lien Managed Instance afin de pouvoir répliquer entre SQL Server installé sur Windows ou Linux et Azure SQL Managed Instance.

Prérequis

Pour créer un lien entre SQL Server et Azure SQL Managed Instance, vous avez besoin des prérequis suivants :

• Un abonnement actif Azure. Si vous n’en avez pas, créez un compte gratuit.
• Une version prise en charge de SQL Server avec la mise à jour de service requise.
• Azure SQL Managed Instance avec une stratégie de mise à jour appropriée. Commencez si vous n’en avez pas.
• Serveur que vous envisagez d’être le serveur principal initial. Ce choix détermine l’emplacement à partir duquel vous devez créer le lien.
  • La configuration d’un lien depuis une instance gérée SQL principale vers une SQL Server 2025 secondaire est prise en charge uniquement avec les instances gérées SQL configurées avec la stratégie de mise à jour SQL Server 2025.
  • La configuration d’un lien depuis une instance managée SQL principale vers un SQL Server 2022 secondaire n’est prise en charge qu’à partir de SQL Server 2022 CU10 et avec les instances managées SQL configurées selon la politique de mise à jour SQL Server 2022.

autorisations

Pour SQL Server, vous devez disposer d’autorisations sysadmin.

Pour Azure SQL Managed Instance, vous devez être membre du SQL Managed Instance Contributeur ou disposer des autorisations suivantes pour un rôle personnalisé :

Aligner la capacité de performance entre les répliques

Lorsque vous utilisez la fonctionnalité de lien, il est important de faire correspondre la capacité de performances entre SQL Server et SQL Managed Instance. Cet alignement vous permet d’éviter les problèmes de performances si le réplica secondaire ne peut pas suivre la réplication à partir du réplica principal ou après le basculement. La capacité de performances inclut les cœurs processeur (ou vCores dans Azure), la mémoire et le débit d’E/S.

Préparer votre instance de SQL Server

Pour préparer votre instance de SQL Server, vous devez vérifier que :

• Vous êtes sur la version minimale prise en charge.
• Vous avez créé une clé principale de base de données dans la master base de données.
• Vous avez activé la fonctionnalité groupes de disponibilité.
• Vous avez ajouté les indicateurs de trace appropriés au démarrage.
• Vos sauvegardes utilisent les sommes de contrôle.
• Vous avez activé récupération de base de données accélérée si vous êtes sur SQL Server 2019 ou version ultérieure, et prévoyez de l'utiliser sur l'instance managée SQL cible.
• Vous avez activé Service Broker si vous envisagez de l’utiliser sur l’instance managée SQL cible.

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

Installer des mises à jour du service

Vérifiez que votre version de SQL Server dispose de la mise à jour de maintenance appropriée installée, comme indiqué dans la table de prise en charge version. Si vous avez besoin d’installer des mises à jour, vous devez redémarrer votre instance de 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 vous assurer 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%';

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é 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 :

1. Ouvrez Gestionnaire de configuration SQL Server.

2. Sélectionnez SQL Server Services dans le volet gauche.

3. Cliquez avec le bouton droit sur le service SQL Server, puis sélectionnez Properties.

   

4. Accédez à l’onglet Groupes de disponibilité Always On.

5. Sélectionnez la case à cocher Activer les groupes de disponibilité Always On, puis sélectionnez OK.

   

   • Si vous utilisez SQL Server 2016 (13.x) et si l'option Activer les groupes de disponibilité Always On est désactivé avec le message This computer is not a node in a failover cluster, suivez les étapes supplémentaires décrites dans Consultez la liste des prérequis pour SQL Server 2016 - lien vers Microsoft Azure SQL Managed Instance. Une fois que vous avez effectué ces autres étapes, revenez et réessayez cette étape.

6. Sélectionnez OK dans la boîte de dialogue.

7. Redémarrez le service SQL Server.

Activer les indicateurs de trace de démarrage

Pour optimiser les performances de votre liaison, nous vous recommandons d’activer les indicateurs de trace suivants au démarrage :

• -T1800 : cet indicateur de trace optimise les performances lorsque les fichiers journaux des réplicas principal et secondaire dans un groupe de disponibilité sont hébergés sur des disques avec des tailles de secteur différentes (par exemple 512 octets et 4 Ko). Si les réplicas principal et secondaire ont une taille de secteur de disque de 4 Ko, cet indicateur de trace n’est pas nécessaire. Pour plus d’informations, consultez l’article KB3009974 de la Base de connaissances.
• -T9567 : cet indicateur de suivi active la compression du flux de données pour les groupes de disponibilité lors de l'initialisation 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 :

1. Ouvrez Gestionnaire de configuration SQL Server.

2. Sélectionnez SQL Server Services dans le volet gauche.

3. Cliquez avec le bouton droit sur le service SQL Server, puis sélectionnez Properties.

   

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

   

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

Utiliser des sauvegardes avec des sommes de contrôle

Lorsque vous créez un lien, l’amorçage initial entre les réplicas principaux et secondaires est effectué en effectuant une sauvegarde complète de la base de données sur le réplica principal, en la transférant vers le réplica secondaire et en la restaurant. Lorsque vous effectuez la sauvegarde complète, nous vous recommandons d’utiliser l’option WITH CHECKSUM pour vous assurer que la sauvegarde est valide et n’a aucune altération. Pour plus d’informations, consultez BACKUP (Transact-SQL).

Redémarrez SQL Server et validez la configuration

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

1. Ouvrez Gestionnaire de configuration SQL Server.

2. Sélectionnez SQL Server Services dans le volet gauche.

3. Cliquez avec le bouton droit sur le service SQL Server, puis sélectionnez Restart.

   

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 SQL Server doit être l’une des versions prises en charge appliquées avec les mises à jour de service appropriées, la fonctionnalité groupes de disponibilité Always On doit être activée et vous devez avoir les indicateurs de trace -T1800 et -T9567 activé. La capture d’écran suivante illustre le résultat attendu d’une instance SQL Server correctement configurée :

Activer la récupération de base de données accélérée

Pour les versions SQL Server 2019 et ultérieures, activez la récupération de base de données accérée et vérifiez que le magasin de versions persistantes (PVS) est défini sur PRIMARY. Si la récupération accélérée de la base de données n'est pas activée sur la base de données source SQL Server, vous ne pouvez pas l'activer sur l'instance managée SQL cible après la migration de la base de données. Si le magasin de versions persistantes (PVS) n’est pas défini sur PRIMARY, vous pouvez rencontrer des problèmes lors des opérations de restauration sur l’instance gérée SQL cible.

Pour SQL Server versions 2017 et antérieures, la récupération accélérée de la base de données n'est pas prise en charge. Cette étape n'est donc pas nécessaire.

Pour configurer correctement la récupération de base de données accélérée sur la base de données source SQL Server, procédez comme suit :

1. Activez la récupération de base de données accélérée en exécutant le script Transact-SQL suivant sur SQL Server :

   ALTER DATABASE [<database name>] SET ACCELERATED_DATABASE_RECOVERY = ON;
   

2. Le magasin de versions persistantes (PVS) doit être défini PRIMARY sur la base de données source, qui est la configuration par défaut. Si cela a été modifié précédemment, vous devez le remplacer par PRIMARY avant de commencer la migration.

Activer Service Broker

Service Broker est activé par défaut pour toutes les versions de SQL Server. Si Service Broker a été désactivé et que vous envisagez de l’utiliser sur SQL Managed Instance, activez Service Broker sur la base de données source SQL Server avant de migrer vers SQL Managed Instance. Si Service Broker n'est pas activé sur la base de données source SQL Server, vous ne pouvez pas l'utiliser sur l'instance managée SQL cible.

Pour vérifier si Service Broker est activé, exécutez le script Transact-SQL suivant sur SQL Server instance :

SELECT name AS [Database Name], is_broker_enabled AS [Service Broker Enabled]
FROM sys.databases
WHERE name = '<database name>';

Si Service Broker est désactivé, activez-le en exécutant le script Transact-SQL suivant sur la base de données source SQL Server :

USE master;
GO

ALTER DATABASE [<database name>]
    SET ENABLE_BROKER;
GO

Configurer la connectivité réseau

Pour que le lien fonctionne, vous devez disposer d’une connectivité réseau entre SQL Server et SQL Managed Instance. L’option réseau que vous choisissez varie selon que votre instance de SQL Server se trouve sur un réseau Azure.

Serveur SQL sur Machines Virtuelles Azure

Le déploiement SQL Server sur les 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 Quickstart : Configure an Azure VM to connect to Azure SQL Managed Instance.

Si votre instance de SQL Server sur les 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.

Il existe 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 global de réseaux virtuels 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).

SQL Server en dehors de Azure

Si votre instance de SQL Server est hébergée en dehors de Azure, établissez une connexion VPN entre SQL Server et SQL Managed Instance à l’aide de l’une des options suivantes :

• Connexion VPN site à site
• Azure ExpressRoute connexion

Ports réseau entre les environnements

Quel que soit le mécanisme de connexion, il existe des exigences qui doivent être satisfaites 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 hébergeant SQL Managed Instance doivent autoriser :

• Port entrant 5022 et plage de ports 11000-11999 pour recevoir le trafic provenant de la source SQL Server IP
• Port sortant 5022 pour envoyer le trafic vers l’adresse IP de destination SQL Server

Tous les pare-feu sur le réseau hébergeant SQL Server, et le système d’exploitation hôte doit 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 tableau suivant décrit les actions de port pour chaque environnement :

Pour ouvrir des ports dans Windows Pare-feu, 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 les pare-feu alles dans l’environnement doivent avoir des ports ouverts, y compris le pare-feu du système d’exploitation hébergeant le SQL Server, ainsi que les pare-feu d’entreprise et/ou les passerelles :

Ajouter des URL à la liste autorisée

Selon vos paramètres de sécurité réseau, il peut être nécessaire d’ajouter des URL à votre liste d'autorisation pour le nom de domaine complet SQL Managed Instance et certains des points de terminaison de Resource Management complet utilisés par Azure.

Les éléments suivants répertorient les ressources qui doivent être ajoutées à votre liste verte :

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

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

Testez la connectivité réseau

La connectivité réseau bidirectionnelle entre SQL Server et SQL Managed Instance est nécessaire pour que le lien fonctionne. Après avoir ouvert des ports côté SQL Server et configuré une règle de groupe de sécurité réseau côté SQL Managed Instance, testez la connectivité à l’aide de SQL Server Management Studio (SSMS) ou de Transact-SQL.

Testez le réseau en créant un travail SQL Agent temporaire sur SQL Server et SQL Managed Instance pour vérifier la connexion entre les deux instances. Lorsque vous utilisez Vérificateur de réseau dans SSMS, le projet est automatiquement créé pour vous et supprimé une fois le test terminé. Vous devez supprimer manuellement le projet SQL Agent si vous testez votre réseau à l’aide de T-SQL.

Pour utiliser SQL Agent pour tester la connectivité réseau, vous avez besoin des exigences suivantes :

• L’utilisateur qui effectue le test doit avoir permissions pour créer un travail (soit en tant que sysadmin ou appartient au rôle SQLAgentOperator pour msdb) pour SQL Server et SQL Managed Instance.
• Le service SQL Server Agent doit être running sur SQL Server. Étant donné que l’agent est activé par défaut sur SQL Managed Instance, aucune action supplémentaire n’est nécessaire.

Tenez compte des éléments 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 propriétaire SQL Server. 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 permettre correctement le trafic entre SQL Server et SQL Managed Instance.

-- Run on SQL Server
-- Create the certificate needed for the test endpoint
USE MASTER
CREATE CERTIFICATE TEST_CERT
WITH SUBJECT = N'Certificate for SQL Server',
EXPIRY_DATE = N'3/30/2051'
GO

-- Create the test endpoint on SQL Server
USE MASTER
CREATE ENDPOINT TEST_ENDPOINT
    STATE=STARTED
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE TEST_CERT,
        ENCRYPTION = REQUIRED ALGORITHM AES
    )

tnc localhost -port 5022

-- Run on SQL managed instance
-- SQL_SERVER_IP_ADDRESS should be an IP address that could be accessed from the SQL Managed Instance host machine.
DECLARE @SQLServerIpAddress NVARCHAR(MAX) = '<SQL_SERVER_IP_ADDRESS>'; -- insert your SQL Server IP address in here
DECLARE @tncCommand NVARCHAR(MAX) = 'tnc ' + @SQLServerIpAddress + ' -port 5022 -InformationLevel Quiet';
DECLARE @jobId BINARY(16);

IF EXISTS (
        SELECT *
        FROM msdb.dbo.sysjobs
        WHERE name = 'NetHelper'
        ) THROW 70000,
    'Agent job NetHelper already exists. Please rename the job, or drop the existing job before creating it again.',
    1
    -- To delete NetHelper job run: EXEC msdb.dbo.sp_delete_job @job_name=N'NetHelper'
    EXEC msdb.dbo.sp_add_job @job_name = N'NetHelper',
        @enabled = 1,
        @description = N'Test SQL Managed Instance to SQL Server network connectivity on port 5022.',
        @category_name = N'[Uncategorized (Local)]',
        @owner_login_name = N'sa',
        @job_id = @jobId OUTPUT;

EXEC msdb.dbo.sp_add_jobstep @job_id = @jobId,
    @step_name = N'TNC network probe from SQL MI to SQL Server',
    @step_id = 1,
    @os_run_priority = 0,
    @subsystem = N'PowerShell',
    @command = @tncCommand,
    @database_name = N'master',
    @flags = 40;

EXEC msdb.dbo.sp_update_job @job_id = @jobId,
    @start_step_id = 1;

EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId,
    @server_name = N'(local)';

-- Run on managed instance
IF EXISTS(SELECT * FROM sys.objects WHERE name = 'ExecuteNetHelper')
    THROW 70001, 'Stored procedure ExecuteNetHelper already exists. Rename or drop the existing procedure before creating it again.', 1
GO
CREATE PROCEDURE ExecuteNetHelper AS
-- To delete the procedure run: DROP PROCEDURE ExecuteNetHelper
BEGIN
    -- Start the job.
    DECLARE @NetHelperstartTimeUtc DATETIME = GETUTCDATE();
    DECLARE @stop_exec_date DATETIME = NULL;

    EXEC msdb.dbo.sp_start_job @job_name = N'NetHelper';

    -- Wait for job to complete and then see the outcome.
    WHILE (@stop_exec_date IS NULL)
    BEGIN
        -- Wait and see if the job has completed.
        WAITFOR DELAY '00:00:01'

        SELECT @stop_exec_date = sja.stop_execution_date
        FROM msdb.dbo.sysjobs sj
        INNER JOIN msdb.dbo.sysjobactivity sja
            ON sj.job_id = sja.job_id
        WHERE sj.name = 'NetHelper'

        -- If job has completed, get the outcome of the network test.
        IF (@stop_exec_date IS NOT NULL)
        BEGIN
            SELECT sj.name JobName,
                sjsl.date_modified AS 'Date executed',
                sjs.step_name AS 'Step executed',
                sjsl.log AS 'Connectivity status'
            FROM msdb.dbo.sysjobs sj
            LEFT JOIN msdb.dbo.sysjobsteps sjs
                ON sj.job_id = sjs.job_id
            LEFT JOIN msdb.dbo.sysjobstepslogs sjsl
                ON sjs.step_uid = sjsl.step_uid
            WHERE sj.name = 'NetHelper'
        END

        -- In case of operation timeout (90 seconds), print timeout message.
        IF (datediff(second, @NetHelperstartTimeUtc, getutcdate()) > 90)
        BEGIN
            SELECT 'NetHelper timed out during the network check. Please investigate SQL Agent logs for more information.'

            BREAK;
        END
    END
END;

-- Run on managed instance
EXEC ExecuteNetHelper;

-- Run on SQL Server
DROP ENDPOINT TEST_ENDPOINT;
GO
DROP CERTIFICATE TEST_CERT;
GO

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 la machine virtuelle locale ou Azure machine virtuelle SQL Server instance vers l'instance managée SQL avant d'utiliser le lien. Pour obtenir des instructions détaillées, consultez Migrater un certificat d’une base de données protégée par TDE pour Azure SQL Managed Instance.

SQL Managed Instance bases de données chiffrées avec des clés TDE géré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 elle a été 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.

Installation de SSMS

SQL Server Management Studio (SSMS) est le moyen le plus simple d’utiliser le lien Managed Instance. Installez la dernière version de SQL Server Management Studio (SSMS) sur votre ordinateur client.

Une fois l’installation terminée, ouvrez SSMS et connectez-vous à votre instance de SQL Server prise en charge. Cliquez avec le bouton droit sur une base de données utilisateur et vérifiez que l’option Azure SQL Managed Instance apparaît dans le menu.

Configurer SSMS pour les clouds du secteur public

Si vous souhaitez déployer votre SQL Managed Instance sur un cloud public, vous devez modifier vos paramètres de SQL Server Management Studio (SSMS) pour utiliser le cloud approprié. Si vous ne déployez pas votre SQL Managed Instance sur un cloud gouvernemental, ignorez cette étape.

Pour mettre à jour vos paramètres SSMS, effectuez ces étapes :

1. Ouvrez SSMS.
2. Dans le menu, choisissez Outils, puis choisissez Options.
3. Développez Azure Services et sélectionnez Azure Cloud.
4. Sous Select an Azure Cloud, utilisez la liste déroulante pour choisir AzureUSGovernment ou un autre cloud gouvernemental, tel que AzureChinaCloud :

Si vous souhaitez revenir au cloud public, choisissez AzureCloud dans la liste déroulante.

Contenu connexe

Pour utiliser le lien :

• Configurer le lien entre SQL Server et SQL Managed Instance avec SSMS
• Configurer la connexion entre SQL Server et SQL Managed Instance avec des scripts
• Basculez le lien
• Migrer avec le lien
• Meilleures pratiques pour préserver la liaison

Pour en savoir plus sur le lien :

• Vue d’ensemble des liens Managed Instance
• Reprise après sinistre avec lien vers Managed Instance

Pour d’autres scénarios de réplication et de migration, considérez :

• Réplication transactionnelle avec SQL Managed Instance
• Service de Relecture de Journaux (LRS)