Preparare l'ambiente per un collegamento - Azure SQL Managed Instance

Applica a:Azure SQL Managed Instance

Questo articolo illustra come preparare l'ambiente per un collegamento Managed Instance in modo da poter eseguire la replica tra SQL Server installate in Windows o Linux e Azure SQL Managed Instance.

Prerequisiti

Per creare un collegamento tra SQL Server e Azure SQL Managed Instance, sono necessari i prerequisiti seguenti:

• Sottoscrizione attiva Azure. Se non se ne ha una, creare un account gratuito.
• Versione supportata di SQL Server con l'aggiornamento del servizio richiesto.
• Azure SQL Managed Instance con un criterio di aggiornamento appropriato. Iniziare se non ne hai uno.
• Un server destinato a essere il server primario iniziale. Questa scelta determina da dove creare il collegamento.
  • La configurazione di un collegamento da un'istanza gestita SQL primaria a un secondario SQL Server 2025 è supportata solo con le istanze gestite SQL configurate con i criteri di aggiornamento SQL Server 2025.
  • La configurazione di un collegamento da un'istanza gestita di SQL primario a un'istanza secondaria di SQL Server 2022 è supportata solo a partire da SQL Server 2022 CU10 e con le istanze gestite di SQL configurate con il criterio di aggiornamento SQL Server 2022.

Autorizzazioni

Per SQL Server è necessario disporre delle autorizzazioni sysadmin.

Per Azure SQL Managed Instance, è necessario essere membri del SQL Managed Instance Collaboratore oppure disporre delle autorizzazioni seguenti per un ruolo personalizzato:

Allineare la capacità di prestazione tra le repliche

Quando si utilizza la funzionalità di collegamento, è importante armonizzare la capacità di prestazione tra SQL Server e SQL Managed Instance. Questo abbinamento consente di evitare problemi di prestazioni se la replica secondaria non riesce a sincronizzarsi con la sincronizzazione dalla replica primaria o in seguito al failover. La capacità delle prestazioni include core CPU (o vCore in Azure), memoria e velocità effettiva di I/O.

Preparare l'istanza di SQL Server

Per preparare l'istanza di SQL Server, è necessario verificare che:

• Sei sulla versione minima supportata.
• Hai creato una chiave master del database nel database master.
• È stata abilitata la funzionalità dei gruppi di disponibilità.
• Hai aggiunto i flag di traccia appropriati all'avvio.
• I tuoi backup utilizzano i checksum.
• È stato abilitato il ripristino del database accelerato se si è in SQL Server 2019 o versione successiva e si prevede di usarlo nell'istanza gestita di SQL di destinazione.
• È stato abilitato Service Broker se si prevede di usarlo nell'istanza gestita di SQL di destinazione.

Per rendere effettive queste modifiche, è necessario riavviare SQL Server.

Installare gli aggiornamenti di manutenzione

Assicurarsi che la versione SQL Server abbia installato l'aggiornamento di manutenzione appropriato, come indicato nella tabella version supportability. Se è necessario installare eventuali aggiornamenti, è necessario riavviare l'istanza di SQL Server durante l'aggiornamento.

Per controllare la versione SQL Server, eseguire lo script di Transact-SQL (T-SQL) seguente in SQL Server:

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

Creare una chiave principale nel database master

Il collegamento usa i certificati per crittografare l'autenticazione e la comunicazione tra SQL Server e SQL Managed Instance. La chiave master del database protegge i certificati usati dal collegamento. Se si dispone già di una chiave master del database, è possibile ignorare questo passaggio.

Creare la chiave master del database nel master database. Inserire la password al posto di <strong_password> nello script seguente e mantenerla in un luogo riservato e sicuro. Eseguire questo script T-SQL in SQL Server:

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

Per assicurarsi di disporre della chiave master del database, usare lo script T-SQL seguente in SQL Server:

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

Abilitare i gruppi di disponibilità

La funzionalità di collegamento è basata sulla funzionalità Gruppi di disponibilità Always On, disabilitata per impostazione predefinita. Per altre informazioni, vedere Abilitare la funzionalità Gruppi di disponibilità AlwaysOn.

Per verificare che la funzionalità dei gruppi di disponibilità sia abilitata, eseguire lo script T-SQL seguente in 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'

Se la funzionalità dei gruppi di disponibilità non è abilitata, seguire questa procedura per abilitarla:

1. Aprire SQL Server Configuration Manager.

2. Selezionare SQL Server Services nel riquadro sinistro.

3. Fare clic con il pulsante destro del mouse sul servizio SQL Server, quindi scegliere Proprietà.

   

4. Passare alla scheda Gruppi di disponibilità AlwaysOn.

5. Selezionare la casella di controllo Abilita gruppi di disponibilità Always On, quindi scegliere OK.

   

   • Se si usa SQL Server 2016 (13.x) e se Enable Always On Availability Groups opzione è disabilitata con il messaggio This computer is not a node in a failover cluster, seguire i passaggi aggiuntivi descritti in Prepare SQL Server 2016 prerequisiti - Azure SQL Managed Instance link. Dopo aver completato questi altri passaggi, tornare indietro e riprovare a eseguire questo passaggio.

6. Nella finestra di dialogo, selezionare OK.

7. Riavviare il servizio SQL Server.

Abilitare i segnalibri di traccia all'avvio

Per ottimizzare le prestazioni del collegamento, è consigliabile abilitare i seguenti flag di traccia all'avvio:

• -T1800: Questo flag di traccia ottimizza le prestazioni quando i file di log per le repliche primarie e secondarie in un gruppo di disponibilità sono ospitati su dischi con settori di dimensioni diverse, ad esempio 512 byte e 4 KB. Se le repliche primarie e secondarie hanno entrambe una dimensione del settore del disco di 4 KB, questa flag di traccia non è necessaria. Per altre informazioni, vedere KB3009974.
• -T9567: Il trace flag abilita la compressione del flusso di dati per i gruppi di disponibilità durante il seeding automatico. La compressione aumenta il carico sul processore, ma può ridurre significativamente i tempi di trasferimento durante il seeding.

Per abilitare questi flag di traccia all'avvio, seguire questa procedura:

1. Aprire SQL Server Configuration Manager.

2. Selezionare SQL Server Services nel riquadro sinistro.

3. Fare clic con il pulsante destro del mouse sul servizio SQL Server, quindi scegliere Proprietà.

   

4. Passare alla scheda Parametri di avvio. In Specificare un parametro di avvio, digitare il parametro -T1800 e selezionare Aggiungi per aggiungere il parametro di avvio. Immettere, quindi, -T9567 e selezionare Aggiungi per aggiungere l'altro flag di traccia. Selezionare Applica per salvare le modifiche.

   

5. Selezionare OK per chiudere la finestra Proprietà.

Per altre informazioni, vedere la sintassi per abilitare i flag di traccia.

Usare i backup con checksum

Quando si crea un collegamento, il seeding iniziale tra le repliche primarie e secondarie viene eseguito eseguendo un backup completo del database nella replica primaria, trasferendolo nella replica secondaria e ripristinandolo. Quando si esegue il backup completo, è consigliabile usare l'opzione WITH CHECKSUM per assicurarsi che il backup sia valido e non abbia alcun danneggiamento. Per altre informazioni, vedere BACKUP (Transact-SQL).

Riavviare SQL Server e convalidare la configurazione

Dopo aver verificato di essere in una versione supportata di SQL Server, aver abilitato la funzionalità Gruppi di disponibilità AlwaysOn e aggiunto i flag di traccia di avvio, riavviare l'istanza di SQL Server per applicare tutte le modifiche seguenti:

1. Aprire SQL Server Configuration Manager.

2. Selezionare SQL Server Services nel riquadro sinistro.

3. Fare clic con il pulsante destro del mouse sul servizio SQL Server e quindi selezionare Restart.

   

Dopo il riavvio, eseguire lo script T-SQL seguente in SQL Server per convalidare la configurazione dell'istanza di 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;

La versione di SQL Server deve essere una delle versioni supportate e deve avere applicati gli aggiornamenti del servizio appropriati; inoltre, la funzionalità gruppi di disponibilità Always On deve essere abilitata e devono essere abilitati i flag di traccia -T1800 e -T9567. Lo screenshot seguente è un esempio del risultato previsto per un'istanza di SQL Server configurata correttamente:

Abilitare il ripristino accelerato del database

Per SQL Server 2019 e versioni successive, abilitare il ripristino del database accelerato e assicurarsi che l'archivio versioni permanente sia impostato su PRIMARY. Se il ripristino accelerato del database non è abilitato nel database di SQL Server di origine, non è possibile abilitarlo nell'istanza gestita di SQL di destinazione dopo la migrazione del database. Se l'archivio versioni permanenti (PVS) non è impostato su PRIMARY, è possibile riscontrare problemi con le operazioni di ripristino nell'istanza gestita di SQL di destinazione.

Per SQL Server 2017 e versioni precedenti, il ripristino accelerato del database non è supportato, quindi questo passaggio non è necessario.

Per configurare correttamente il ripristino accelerato del database nel database di SQL Server di origine, seguire questa procedura:

1. Abilitare il ripristino accelerato del database eseguendo lo script di Transact-SQL seguente in SQL Server:

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

2. L'archivio versioni permanenti (PVS) deve essere impostato su PRIMARY nel database di origine, ovvero la configurazione predefinita. Se è stato modificato in precedenza, è necessario tornare a PRIMARY prima di avviare la migrazione.

Abilitare Service Broker

Service Broker è abilitato per impostazione predefinita per tutte le versioni di SQL Server. Se Service Broker è stato disabilitato e si prevede di usarlo in SQL Managed Instance, abilitare Service Broker nel database di origine SQL Server prima di eseguire la migrazione a SQL Managed Instance. Se Service Broker non è abilitato nel database SQL Server di origine, non è possibile usarlo nell'istanza gestita di SQL di destinazione.

Per verificare se Service Broker è abilitato, eseguire lo script di Transact-SQL seguente nell'istanza di SQL Server:

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

Se Service Broker è disabilitato, abilitarlo eseguendo lo script di Transact-SQL seguente nel database di origine SQL Server:

USE master;
GO

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

Configurare la connettività di rete

Per il funzionamento del collegamento, è necessario disporre della connettività di rete tra SQL Server e SQL Managed Instance. L'opzione di rete scelta dipende dal fatto che l'istanza di SQL Server si trovi in una rete Azure.

SQL Server su Macchine Virtuali Azure

La distribuzione di SQL Server on Azure Virtual Machines nella stessa rete virtuale Azure che ospita SQL Managed Instance è il metodo più semplice, perché la connettività di rete esiste automaticamente tra le due istanze. Per altre informazioni, vedere Quickstart: Configurare una macchina virtuale Azure per la connessione a Azure SQL Managed Instance.

Se l'istanza di SQL Server on Azure Virtual Machines si trova in una rete virtuale diversa dall'istanza gestita di SQL, è necessario connettere le due reti virtuali. Per il funzionamento di questo scenario, le reti virtuali non devono trovarsi nella stessa sottoscrizione.

Sono disponibili due opzioni per connettere le reti virtuali:

• Peering di rete virtuale di Azure
• Gateway VPN tra reti virtuali (portale Azure, PowerShell, Azure CLI)

Il peering è preferibile perché usa la rete backbone Microsoft. Quindi, dal punto di vista della connettività, non esiste alcuna differenza evidente nella latenza tra le macchine virtuali in una rete virtuale con peering e nella stessa rete virtuale. Il peering di rete virtuale è supportato tra reti nella stessa regione. Il peering globale di reti virtuali è supportato per le istanze ospitate nelle subnet create a partire dal 22 settembre 2020. Per ulteriori informazioni, vedere Domande frequenti (FAQ).

SQL Server all'esterno di Azure

Se l'istanza di SQL Server è ospitata all'esterno di Azure, stabilire una connessione VPN tra SQL Server e SQL Managed Instance usando una di queste opzioni:

• Connessione VPN da sito a sito
• Connessione Azure ExpressRoute

Porte di rete tra ambienti

Indipendentemente dal meccanismo di connettività, è necessario soddisfare i requisiti per il flusso del traffico di rete tra ambienti:

Le regole del gruppo di sicurezza di rete (NSG) nella subnet che ospitano SQL Managed Instance devono consentire:

• Porta in ingresso 5022 e intervallo di porte 11000-11999 per ricevere traffico dall'indirizzo IP di origine SQL Server
• Porta in uscita 5022 per inviare traffico alla destinazione SQL Server IP

Tutti i firewall nella rete che ospitano SQL Server e il sistema operativo host deve consentire:

• Porta in ingresso 5022 aperta per ricevere traffico dall'intervallo IP di origine della subnet MI /24 (ad esempio 10.0.0.0/24)
• Le porte in uscita 5022 e l'intervallo di porte 11000-11999 sono aperte per inviare il traffico all'intervallo IP di destinazione della sottorete MI (ad esempio 10.0.0.0/24)

La tabella seguente descrive le azioni delle porte per ciascun ambiente:

Per aprire le porte in Windows Firewall, usare lo script di PowerShell seguente nel sistema operativo host Windows dell'istanza di 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

Il diagramma seguente mostra un esempio di ambiente di rete locale, che indica che tutti i firewall nell'ambiente devono avere porte aperte, incluso il firewall del sistema operativo che ospita il SQL Server ed eventuali firewall e/o gateway aziendali:

Aggiungere URL a una lista di accesso consentito

A seconda delle impostazioni di sicurezza di rete, potrebbe essere necessario aggiungere URL all'elenco elementi consentiti per l'FQDN SQL Managed Instance e alcuni degli endpoint di Gestione risorse usati da Azure.

Di seguito sono elencate le risorse che devono essere aggiunte all'elenco elementi consentiti:

• Nome di dominio completo (FQDN) del SQL Managed Instance. Ad esempio: managedinstance.a1b2c3d4e5f6.database.windows.net.
• Autorità Microsoft Entra
• ID risorsa endpoint Microsoft Entra
• Endpoint di Resource Manager
• Endpoint del servizio

Seguire la procedura descritta nella sezione Configurare SSMS per i cloud per enti pubblici per accedere all'interfaccia Tools in SQL Server Management Studio (SSMS) e identificare gli URL specifici per le risorse all'interno del cloud da aggiungere all'elenco di elementi consentiti.

Testare la connettività di rete

La connettività di rete bidirezionale tra SQL Server e SQL Managed Instance è necessaria per il funzionamento del collegamento. Dopo aver aperto le porte sul lato SQL Server e aver configurato una regola del gruppo di sicurezza di rete sul lato SQL Managed Instance, testare la connettività usando SQL Server Management Studio (SSMS) o Transact-SQL.

Testare la rete creando un processo temporaneo di SQL Agent sia in SQL Server che in SQL Managed Instance per verificare la connessione tra le due istanze. Quando si usa Controllo di rete in SSMS, il processo viene creato automaticamente ed eliminato al termine del test. È necessario eliminare manualmente il processo di SQL Agent se si testa la rete usando T-SQL.

Per usare SQL Agent per testare la connettività di rete, sono necessari i requisiti seguenti:

• L'utente che esegue il test deve avere autorizzazioni per creare un job (come sysadmin o appartiene al msdb ruolo di SQLAgentOperator) sia per SQL Server che per SQL Managed Instance.
• Il servizio SQL Server Agent deve essere in esecuzione in SQL Server. Poiché l'agente è attivato per impostazione predefinita in SQL Managed Instance, non è necessaria alcuna azione aggiuntiva.

Tenere presente quanto segue:

• Per evitare falsi negativi, tutti i firewall lungo il percorso di rete devono consentire il traffico ICMP (Internet Control Message Protocol).
• Per evitare falsi positivi, tutti i firewall lungo il percorso di rete devono consentire il traffico sul protocollo proprietario SQL Server UCS. Il blocco del protocollo può portare a un test di connessione riuscito, ma non riesce a creare il collegamento.
• Le configurazioni avanzate del firewall con protezioni a livello di pacchetto devono essere configurate correttamente per consentire correttamente il traffico tra SQL Server e 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

Eseguire la migrazione di un certificato di un database protetto con TDE (facoltativo)

Se si collega un database SQL Server protetto da Transparent Data Encryption (TDE) a un'istanza gestita di SQL, è necessario eseguire la migrazione del certificato di crittografia corrispondente dall'istanza locale o Azure macchina virtuale SQL Server all'istanza gestita di SQL prima di usare il collegamento. Per i passaggi dettagliati, vedere Migrate un certificato di un database protetto da TDE per Azure SQL Managed Instance.

SQL Managed Instance database crittografati con chiavi TDE gestite dal servizio non possono essere collegati a SQL Server. È possibile collegare un database crittografato a SQL Server solo se è stato crittografato con una chiave gestita dal cliente e il server di destinazione ha accesso alla stessa chiave usata per crittografare il database. Per altre informazioni, vedere Impostare SQL Server TDE con Azure Key Vault.

Installare SSMS

SQL Server Management Studio (SSMS) è il modo più semplice per usare il collegamento Managed Instance. Installare la versione più recente di SQL Server Management Studio (SSMS) nel computer client.

Al termine dell'installazione, aprire SSMS e connettersi all'istanza di SQL Server supportata. Fare clic con il pulsante destro del mouse su un database utente e verificare che l'opzione collegamento di Azure SQL Managed Instance appaia nel menu.

Configurare SSMS per i cloud per enti pubblici

Se si vuole distribuire il SQL Managed Instance in un cloud per enti pubblici, è necessario modificare le impostazioni di SQL Server Management Studio (SSMS) per usare il cloud corretto. Se non si distribuisce il SQL Managed Instance in un cloud per enti pubblici, ignorare questo passaggio.

Per aggiornare le impostazioni SSMS, effettuare le seguenti operazioni:

1. Aprire SSMS.
2. Dal menu, scegliere Strumenti, quindi selezionare Opzioni.
3. Espandere Azure Services e selezionare Azure Cloud.
4. In Selezionare un Azure Cloud usare l'elenco a discesa per scegliere AzureUSGovernment o un altro cloud per enti pubblici, ad esempio AzureChinaCloud:

Per tornare al cloud pubblico, scegliere AzureCloud dall'elenco a discesa.

Contenuto correlato

Per usare il collegamento:

• Configurare il collegamento tra SQL Server e Istanza gestita di SQL con SSMS
• Configurare il collegamento tra SQL Server e Istanza gestita di SQL con script
• Eseguire il failover con il collegamento
• Eseguire la migrazione tramite il collegamento
• Procedure consigliate per la gestione del collegamento

Per altre informazioni sul collegamento:

• Panoramica del collegamento di Managed Instance
• Ripristino di emergenza con collegamento di Istanza gestita

Per altri scenari di replica e migrazione, prendere in considerazione:

• Replica transazionale con Istanza Gestita di SQL
• Servizio di riproduzione log (LRS)