Configurare il collegamento con gli script - Istanza gestita di SQL di Azure

Applica a:Istanza gestita di SQL di Azure

Questo articolo illustra come configurare un link tra SQL Server e Istanza gestita di SQL di Azure con script di Transact-SQL e PowerShell o interfaccia della riga di comando di Azure. Attraverso il collegamento, i database del tuo server primario iniziale vengono replicati nella replica secondaria quasi in tempo reale.

Dopo aver creato il collegamento, è possibile effettuare il failover nella replica secondaria allo scopo della migrazione o del ripristino di emergenza.

Panoramica

Usare il collegamento per replicare i database dal database primario iniziale alla replica secondaria. Per SQL Server 2022, il database primario iniziale può essere SQL Server o Istanza gestita di SQL di Azure. Per SQL Server 2019 e versioni precedenti, il database primario iniziale deve essere SQL Server. Dopo aver configurato il collegamento, il database primario iniziale viene replicato nella replica secondaria.

È possibile scegliere di lasciare il collegamento sul posto per la replica continua dei dati in un ambiente ibrido tra la replica primaria e secondaria oppure eseguire il failover del database nella replica secondaria, per eseguire la migrazione a Azure o per il ripristino di emergenza. Per SQL Server 2019 e versioni precedenti, il failover a Istanza gestita di SQL di Azure interrompe il collegamento e il failback non è supportato. Con SQL Server 2022, è possibile mantenere il collegamento e il failback tra le due repliche.

Se si prevede di usare l’istanza gestita secondaria solo per il ripristino di emergenza, è possibile risparmiare sui costi di licenza attivando il vantaggio di failover ibrido.

Usare le istruzioni riportate in questo articolo per configurare manualmente il collegamento tra SQL Server e Istanza gestita di SQL di Azure. Dopo aver creato il collegamento, il database di origine ottiene una copia di sola lettura nella replica secondaria di destinazione.

Prerequisiti

Per replicare i database, 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 installato.
• Istanza gestita di SQL di Azure. Inizia subito se non ce l'hai.
• Modulo PowerShell Az.SQL 6.0.0 o versione successiva o interfaccia della riga di comando di Azure 2.67.0 o versione successiva. In alternativa, usare Azure Cloud Shell online dal Web browser per eseguire i comandi, perché viene sempre aggiornato con le versioni più recenti del modulo.
• Ambiente preparato correttamente.

Considerare quanto segue:

• La funzionalità di collegamento supporta un database per collegamento. Per replicare più database in un'istanza, creare un collegamento per ogni singolo database. Ad esempio, per replicare 10 database in Istanza gestita di SQL, creare 10 singoli collegamenti.
• Le regole di confronto tra SQL Server e Istanza gestita di SQL devono essere uguali. Una differenza nelle regole di confronto potrebbe causare una discrepanza nel maiuscolo/minuscolo dei nomi del server e impedire il successo di una connessione da SQL Server a Istanza gestita di SQL.
• L'errore 1475 nella SQL Server primaria iniziale indica che è necessario avviare una nuova catena di backup creando un backup completo senza l'opzione COPY ONLY.
• Per stabilire un collegamento o eseguire il failover, da Istanza gestita di SQL a SQL Server 2025, l'istanza SQL gestita deve essere configurata con il criterio di aggiornamento SQL Server 2025. La replica dei dati e il failover da Istanza gestita di SQL a SQL Server 2025 non sono supportati per le istanze configurate con criteri di aggiornamento incompatibili.
• Per stabilire un collegamento o eseguire il passaggio a SQL Server 2022 da un'istanza gestita di SQL, l'istanza gestita di SQL deve essere configurata seguendo la politica degli aggiornamenti SQL Server 2022. La replica dei dati e il failover da Istanza gestita di SQL a SQL Server 2022 non sono supportati per le istanze configurate con un criterio di aggiornamento non corrispondente.
• Sebbene sia possibile stabilire un collegamento da una versione supportata di SQL Server a un'istanza gestita SQL configurata con i criteri di aggiornamento Always-up-to-date, dopo il failover a Istanza gestita di SQL, non sarà più possibile replicare i dati o eseguire il failback alla tua istanza di SQL Server.

Autorizzazioni

Per SQL Server è necessario disporre delle autorizzazioni sysadmin.

Per Istanza gestita di SQL di Azure, è necessario essere membri del Istanza gestita di SQL Collaboratore o disporre delle autorizzazioni del ruolo personalizzate seguenti:

Terminologia e convenzioni di denominazione

Quando si eseguono script da questa guida utente, è importante non scambiare i nomi di SQL Server e Istanza gestita di SQL con i loro nomi di dominio completi (FQDN). La tabella seguente spiega cosa rappresentano esattamente i vari nomi e come ottenere i relativi valori:

La configurazione di Istanza gestita di SQL di Azure come istanza primaria iniziale è supportata a partire da SQL Server 2022 CU10.

Configurare il backup e il ripristino del database

Se SQL Server è il tuo server primario iniziale, i database che verranno replicati tramite il collegamento devono trovarsi nel modello di recupero completo e avere almeno un backup. Poiché Istanza gestita di SQL di Azure esegue automaticamente i backup, ignorare questo passaggio se Istanza gestita di SQL è il database primario iniziale.

Quando si crea un collegamento, il seeding iniziale tra le repliche primarie e secondarie avviene 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).

Eseguire il codice seguente in SQL Server per tutti i database da replicare. Sostituire <DatabaseName> con il nome effettivo del database.

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

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

Per altre informazioni, vedere Creazione di un backup completo del database.

Stabilire un trust tra istanze

Prima di tutto, è necessario stabilire un trust tra le due istanze e proteggere gli endpoint usati per comunicare e crittografare i dati in rete. I gruppi di disponibilità distribuiti usano l'endpoint del mirroring del database del gruppo di disponibilità esistente, anziché avere il proprio endpoint dedicato. Di conseguenza, la sicurezza e l'attendibilità reciproca devono essere configurate tra le due istanze tramite l'endpoint del gruppo di disponibilità per il mirroring del database.

L'attendibilità basata su certificati è l'unico modo supportato per proteggere gli endpoint del mirroring del database per SQL Server e Istanza gestita di SQL. Se si dispone di gruppi di disponibilità esistenti che usano autenticazione di Windows, è necessario aggiungere un trust basato su certificato all'endpoint di mirroring esistente come opzione di autenticazione secondaria. A tale scopo, è possibile usare l'istruzione ALTER ENDPOINT, come illustrato più avanti in questo articolo.

Di seguito è riportata una panoramica del processo per proteggere gli endpoint del mirroring del database sia per SQL Server che per Istanza gestita di SQL:

1. Generare un certificato in SQL Server e ottenere la chiave pubblica.
2. Ottenere una chiave pubblica del certificato Istanza gestita di SQL.
3. Exchange le chiavi pubbliche tra SQL Server e Istanza gestita di SQL.
4. Importare le chiavi di un'autorità di certificazione radice attendibile di Azure in SQL Server

Le sezioni seguenti descrivono questi passaggi in dettaglio.

Creare un certificato in SQL Server e importarne la chiave pubblica in Istanza gestita di SQL

Creare prima di tutto la chiave master del database master, se non è già presente. 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 encryption password
-- Keep the password confidential and in a secure place
USE MASTER
IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
BEGIN
    PRINT 'Creating master key.' + CHAR(13) + 'Keep the password confidential and in a secure place.'
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>'
END
ELSE
    PRINT 'Master key already exists.'
GO

Generare quindi un certificato di autenticazione in SQL Server. Nello script seguente, sostituire:

• @cert_expiry_date con la data di scadenza del certificato desiderata (data futura).

Registrare questa data e impostare un promemoria per ruotare (aggiornare) il certificato di SQL Server prima della data di scadenza per garantire il funzionamento continuo del collegamento.

-- Create the SQL Server certificate for the instance link
USE MASTER

-- Customize SQL Server certificate expiration date by adjusting the date below
DECLARE @cert_expiry_date AS varchar(max)='03/30/2025'

-- Build the query to generate the certificate
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @sqlserver_certificate_subject NVARCHAR(MAX) = N'Certificate for ' + @sqlserver_certificate_name
DECLARE @create_sqlserver_certificate_command NVARCHAR(MAX) = N'CREATE CERTIFICATE [' + @sqlserver_certificate_name + '] ' + char (13) +
'    WITH SUBJECT = ''' + @sqlserver_certificate_subject + ''',' + char (13) +
'    EXPIRY_DATE = '''+ @cert_expiry_date + ''''+ char (13)
IF NOT EXISTS (SELECT name from sys.certificates WHERE name = @sqlserver_certificate_name)
BEGIN
    PRINT (@create_sqlserver_certificate_command)
    -- Execute the query to create SQL Server certificate for the instance link
    EXEC sp_executesql @stmt = @create_sqlserver_certificate_command
END
ELSE
    PRINT 'Certificate ' + @sqlserver_certificate_name + ' already exists.'
GO

Usare quindi la query T-SQL seguente in SQL Server per verificare che il certificato sia stato creato:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

Nei risultati della query si noterà che il certificato è stato crittografato con la chiave master.

A questo punto, è possibile ottenere la chiave pubblica del certificato generato in SQL Server:

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @PUBLICKEYENC VARBINARY(MAX) = CERTENCODED(CERT_ID(@sqlserver_certificate_name));
SELECT @sqlserver_certificate_name as 'SQLServerCertName'
SELECT @PUBLICKEYENC AS SQLServerPublicKey;

Salvare i valori di SQLServerCertName e SQLServerPublicKey dall'output, perché sarà necessario per il passaggio successivo quando si importa il certificato.

Assicurarsi prima di tutto di aver eseguito l'accesso a Azure e di aver selezionato la sottoscrizione in cui è ospitata l'istanza gestita. La selezione della sottoscrizione appropriata è particolarmente importante se sono presenti più sottoscrizioni Azure nell'account.

Sostituire <SubscriptionID> con l'ID sottoscrizione Azure.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

Usare quindi il comando New-AzSqlInstanceServerTrustCertificate PowerShell o az sql mi partner-cert create interfaccia della riga di comando di Azure per caricare la chiave pubblica del certificato di autenticazione da SQL Server a Azure, ad esempio l'esempio di PowerShell seguente.

Compilare le informazioni utente necessarie, copiarlo, incollarlo e quindi eseguire lo script. Sostituire:

• <SQLServerPublicKey> con la parte pubblica del certificato SQL Server in formato binario, registrato nel passaggio precedente. Si tratta di un valore di stringa lungo che inizia con 0x.
• <SQLServerCertName> con il nome del certificato SQL Server registrato nel passaggio precedente.
• <ManagedInstanceName> con il nome breve dell'istanza gestita.

# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO IMPORT SQL SERVER PUBLIC CERTIFICATE TO SQL MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter the name for the server SQLServerCertName certificate – for example, "Cert_sqlserver1_endpoint"
$CertificateName = "<SQLServerCertName>"

# Insert the certificate public key blob that you got from SQL Server – for example, "0x1234567..."
$PublicKeyEncoded = "<SQLServerPublicKey>"

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the below cmdlets====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Upload the public key of the authentication certificate from SQL Server to Azure.
New-AzSqlInstanceServerTrustCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $CertificateName -PublicKey $PublicKeyEncoded 

Il risultato di questa operazione è un riepilogo del certificato SQL Server caricato in Azure.

Se è necessario visualizzare tutti i certificati SQL Server caricati in un'istanza gestita, usare il comando Get-AzSqlInstanceServerTrustCertificate PowerShell o az sql mi partner-cert list interfaccia della riga di comando di Azure in Azure Cloud Shell. Per rimuovere il certificato di SQL Server caricato su un'istanza gestita di SQL, utilizzare il comando Remove-AzSqlInstanceServerTrustCertificate PowerShell o az sql mi partner-cert delete interfaccia della riga di comando di Azure in Azure Cloud Shell.

Ottenere la chiave pubblica del certificato da Istanza gestita di SQL e importarla in SQL Server

Il certificato per proteggere l'endpoint di collegamento viene generato automaticamente in Istanza gestita di SQL di Azure. Ottenere la chiave pubblica del certificato da Istanza gestita di SQL e importarla in SQL Server usando il comando Get-AzSqlInstanceEndpointCertificate PowerShell o az sql mi endpoint-cert show interfaccia della riga di comando di Azure, ad esempio l'esempio di PowerShell seguente.

Eseguire lo script seguente. Sostituire:

• <SubscriptionID> con l'ID della sottoscrizione Azure.
• <ManagedInstanceName> con il nome breve dell'istanza gestita.

# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO EXPORT MANAGED INSTANCE PUBLIC CERTIFICATE
# ===== Enter user variables here ====

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Fetch the public key of the authentication certificate from Managed Instance. Outputs a binary key in the property PublicKey.
Get-AzSqlInstanceEndpointCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -EndpointType "DATABASE_MIRRORING" | out-string   

Copiare l'intero output PublicKey (inizia con 0x) perché sarà necessario nel passaggio successivo.

In alternativa, se si verificano problemi durante la procedura di copia-incolla di PublicKey, è anche possibile eseguire il comando EXEC sp_get_endpoint_certificate 4 T-SQL nell'istanza gestita per ottenere la relativa chiave pubblica per l'endpoint di collegamento.

Importare quindi la chiave pubblica ottenuta del certificato di sicurezza dell'istanza gestita in SQL Server. Eseguire la seguente query sul server SQL per creare il certificato dell'endpoint di istanza gestita. Sostituire:

• <ManagedInstanceFQDN> con il nome di dominio completamente qualificato dell'istanza gestita.
• <PublicKey> con il valore PublicKey ottenuto nel passaggio precedente (da Azure Cloud Shell, a partire da 0x). Non è necessario usare le virgolette.

-- Run on SQL Server
USE MASTER
CREATE CERTIFICATE [<ManagedInstanceFQDN>]
FROM BINARY = <PublicKey> 

Importare le chiavi di un'autorità di certificazione radice attendibile di Azure in SQL Server

L'importazione delle chiavi delle autorità di certificazione radice (CA) attendibili di Azure nel server SQL è necessaria affinché il server SQL consideri attendibili i certificati di chiave pubblica di Istanza gestita di SQL rilasciati da Azure.

È possibile scaricare le chiavi della CA radice necessarie dai dettagli dell'autorità di certificazione di Azure. Scaricare almeno i certificati DigiCert Global Root G2 e Certificato Radice Microsoft RSA 2017 e importarli nell'istanza di SQL Server. Tuttavia, se si prevede di eseguire il collegamento per più di qualche mese, scaricare e importare tutti e 7 i certificati elencati nella sezione Root Certificate Authorities per evitare potenziali interruzioni nel caso in cui Azure aggiorna l'elenco ca attendibile.

Salvare i certificati locali nell'istanza di SQL Server, ad esempio nel percorso di esempio C:\Path\To\<name of certificate>.crt, quindi importare i certificati da tale percorso usando lo script di Transact-SQL seguente. Sostituire <name of certificate> con il nome effettivo del certificato, ad esempio DigiCert Global Root G2 o Microsoft RSA Root Certificate Authority 2017.

-- Run on SQL Server
-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'<name of certificate>')
BEGIN
    PRINT 'Creating <name of certificate> certificate.'
    CREATE CERTIFICATE [<name of certificate>] FROM FILE = 'C:\Path\To\<name of certificate>.crt'

    --Trust certificates issued by <name of certificate> root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('<name of certificate>')
    --For government cloud, use the corresponding SQL Database DNS suffix, e.g. '*.database.usgovcloudapi.net', '*.database.chinacloudapi.cn' etc.
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate <name of certificate> already exists.'
GO

Infine, verificare tutti i certificati creati usando la vista a gestione dinamica seguente:Finally, verify all the created certificates by using the following dynamic management view (DMV):

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

Convalidare la catena di certificati

Le modifiche pianificate o non intenzionali ai certificati possono compromettere il collegamento. Per evitare interruzioni, è importante convalidare la catena dei certificati su SQL Server.

Ignorare questo passaggio se si sta configurando un nuovo collegamento o se sono stati importati di recente i certificati come descritto nelle sezioni precedenti.

Proteggi l'endpoint del mirroring del database

Se non si dispone di un gruppo di disponibilità esistente o di un endpoint del mirroring del database in SQL Server, il passaggio successivo consiste nel creare un endpoint del mirroring del database in SQL Server e proteggerlo con il certificato SQL Server generato in precedenza. Se si dispone di un gruppo di disponibilità o di un endpoint di mirroring esistente, vai alla sezione Modificare un endpoint esistente.

Creare e proteggere l'endpoint del mirroring del database su SQL Server

Per verificare che non sia stato creato un endpoint di mirroring del database esistente, usare lo script seguente:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT * FROM sys.database_mirroring_endpoints WHERE type_desc = 'DATABASE_MIRRORING'

Se la query precedente non mostra un endpoint del mirroring del database esistente, eseguire lo script seguente in SQL Server per ottenere il nome del certificato SQL Server generato in precedenza.

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
SELECT @sqlserver_certificate_name as 'SQLServerCertName'

Salvare SQLServerCertName dall'output perché sarà necessario nel passaggio successivo.

Usare lo script seguente per creare un nuovo endpoint del mirroring del database sulla porta <EndpointPort> e proteggere l'endpoint con il certificato SQL Server. Sostituire:

• <SQL_SERVER_CERTIFICATE> con il nome di SQLServerCertName ottenuto nel passaggio precedente.

-- Run on SQL Server
-- Create a connection endpoint listener on SQL Server
USE MASTER
CREATE ENDPOINT database_mirroring_endpoint
    STATE=STARTED   
    AS TCP (LISTENER_PORT=<EndpointPort>, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE [<SQL_SERVER_CERTIFICATE>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )  
GO

Verificare che l'endpoint del mirroring sia stato creato eseguendo lo script seguente in SQL Server:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc,
    connection_auth_desc, is_encryption_enabled, encryption_algorithm_desc
FROM 
    sys.database_mirroring_endpoints

La colonna "state_desc" dell'endpoint creata correttamente dovrebbe indicare STARTED.

È stato creato un nuovo endpoint di mirroring con l'autenticazione del certificato e la crittografia AES abilitata.

Alterare un endpoint esistente

Se si usano gruppi di disponibilità esistenti per il collegamento o se è presente un endpoint di mirroring del database esistente, verificare prima di tutto che soddisfi le condizioni obbligatorie seguenti per il collegamento:

• Il tipo deve essere DATABASE_MIRRORING.
• L’autenticazione della connessione deve essere CERTIFICATE.
• La crittografia deve essere abilitata.
• L'algoritmo di crittografia deve essere AES.

Eseguire la query seguente su SQL Server per visualizzare i dettagli per un endpoint di mirroring del database esistente:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

Se l'output indica che l'endpoint esistente DATABASE_MIRRORINGconnection_auth_desc non è CERTIFICATE, o encryption_algorithm_desc non è AES, l'endpoint deve essere modificato per soddisfare i requisiti.

In SQL Server, lo stesso endpoint del mirroring del database viene usato sia per i gruppi di disponibilità che per i gruppi di disponibilità distribuiti. Se l'endpoint connection_auth_desc è NTLM (autenticazione di Windows) o KERBEROS ed è necessario autenticazione di Windows per un gruppo di disponibilità esistente, è possibile modificare l'endpoint per usare più metodi di autenticazione passando all'opzione di autenticazione NEGOTIATE CERTIFICATE. Questa modifica consente al gruppo di disponibilità esistente di usare autenticazione di Windows, usando l'autenticazione del certificato per Istanza gestita di SQL.

Analogamente, se la crittografia non include AES ed è necessaria la crittografia RC4, è possibile modificare l'endpoint per usare entrambi gli algoritmi. Per informazioni dettagliate sulle opzioni possibili per la modifica degli endpoint, vedere la pagina della documentazione per sys.database_mirroring_endpoints.

Lo script seguente è un esempio di come modificare l'endpoint del mirroring del database esistente in SQL Server. Sostituire:

• <YourExistingEndpointName> con il nome dell'endpoint esistente.
• <SQLServerCertName> con il nome del certificato SQL Server generato (ottenuto in uno dei passaggi precedenti).

A seconda della configurazione specifica, potrebbe essere necessario personalizzare ulteriormente lo script. È anche possibile usare SELECT * FROM sys.certificates per ottenere il nome del certificato creato in SQL Server.

-- Run on SQL Server
-- Alter the existing database mirroring endpoint to use CERTIFICATE for authentication and AES for encryption
USE MASTER
ALTER ENDPOINT [<YourExistingEndpointName>]   
    STATE=STARTED   
    AS TCP (LISTENER_PORT=<EndpointPort>, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = WINDOWS NEGOTIATE CERTIFICATE [<SQLServerCertName>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )
GO

Dopo aver eseguito la query dell'endpoint ALTER e impostare la modalità di autenticazione doppia su Windows e certificato, usare di nuovo questa query in SQL Server per visualizzare i dettagli per l'endpoint del mirroring del database:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

L'endpoint del mirroring del database è stato modificato con successo per un collegamento a Istanza gestita di SQL.

Creare un gruppo di disponibilità in SQL Server

Se non si dispone di un gruppo di disponibilità esistente, il passaggio successivo consiste nel crearne uno in SQL Server, indipendentemente dal gruppo primario iniziale.

I comandi per creare il gruppo di disponibilità sono diversi se il Istanza gestita di SQL è il database primario iniziale, supportato solo a partire da SQL Server 2022 CU10.

Sebbene sia possibile stabilire più collegamenti per lo stesso database, il collegamento supporta solo la replica di un database per ogni collegamento. Se si desidera creare più collegamenti per lo stesso database, usare lo stesso gruppo di disponibilità per tutti i collegamenti, ma creare un nuovo gruppo di disponibilità distribuito per ogni collegamento di database tra SQL Server e Istanza gestita di SQL.

-- Run on the initial primary
SELECT @@SERVERNAME AS SQLServerName 

-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGNameOnSQLServer>]
WITH (CLUSTER_TYPE = NONE) -- <- Delete this line for SQL Server 2016 only. Leave as-is for all higher versions.
    FOR database [<DatabaseName>]  
    REPLICA ON   
        N'<SQLServerName>' WITH   
            (  
            ENDPOINT_URL = 'TCP://<SQLServerIP>:<EndpointPort>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

-- Run on SQL Server
-- Create a distributed availability group for the availability group and database
-- ManagedInstanceName example: 'sqlmi1'
-- ManagedInstanceFQDN example: 'sqlmi1.73d19f36a420a.database.windows.net'
USE MASTER
CREATE AVAILABILITY GROUP [<DAGName>]
WITH (DISTRIBUTED) 
    AVAILABILITY GROUP ON  
    N'<AGNameOnSQLServer>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:<EndpointPort>',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<AGNameOnSQLMI>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC
    );
GO

-- Run on the initial primary
SELECT @@SERVERNAME AS SQLServerName 

-- Run on SQL Server 
-- Create the availability group on SQL Server 

CREATE AVAILABILITY GROUP [<AGNameOnSQLServer>] 
WITH (CLUSTER_TYPE = NONE) 
FOR  
REPLICA ON N'<SQLServerName>' 
WITH ( 
    ENDPOINT_URL = N'TCP://<SQLServerIP>:<EndpointPort>', 
    FAILOVER_MODE = MANUAL, 
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
    SEEDING_MODE = AUTOMATIC); 

GO 

-- Run on SQL Server 
-- Grant permission to the availability group to create databases 

ALTER AVAILABILITY GROUP [<AGNameOnSQLServer>] GRANT CREATE ANY DATABASE; 

-- Run on SQL Server 
-- Create a distributed availability group for the availability group and database 
-- ManagedInstanceName example: 'sqlmi1' 
-- ManagedInstanceFQDN example: 'sqlmi1.73d19f36a420a.database.windows.net' 

USE MASTER 
CREATE AVAILABILITY GROUP [<DAGName>] 
WITH (DISTRIBUTED)  
    AVAILABILITY GROUP ON   
    N'<AGNameOnSQLServer>' WITH  
    ( 
      LISTENER_URL = 'TCP://<SQLServerIP>:<EndpointPort>', 
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, 
      FAILOVER_MODE = MANUAL, 
      SEEDING_MODE = AUTOMATIC, 
      SESSION_TIMEOUT = 20 
    ), 
    N'<AGNameOnSQLMI>' WITH 
    ( 
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>];Database=[<DatabaseName>]', 
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, 
      FAILOVER_MODE = MANUAL, 
      SEEDING_MODE = AUTOMATIC 
    ); 
GO 

Verificare i gruppi di disponibilità

Usare lo script seguente per elencare tutti i gruppi di disponibilità e i gruppi di disponibilità distribuiti nell'istanza di SQL Server. A questo punto, lo stato del gruppo di disponibilità deve essere connected, e lo stato dei gruppi di disponibilità distribuiti deve essere disconnected. Lo stato del gruppo di disponibilità distribuito passa a connected solo una volta aggiunto con Istanza gestita di SQL.

-- Run on SQL Server
-- This will show that the availability group and distributed availability group have been created on SQL Server.
SELECT * FROM sys.availability_groups

In alternativa, è possibile usare Esplora oggetti SSMS per trovare gruppi di disponibilità e gruppi di disponibilità distribuiti. Espandere la cartella Disponibilità elevata Always On e quindi la cartella Gruppi di disponibilità.

Crea un collegamento

Infine, è possibile creare il collegamento. I comandi differiscono in base all'istanza primaria iniziale. Usare il comando New-AzSqlInstanceLink PowerShell o az sql mi link create interfaccia della riga di comando di Azure per creare il collegamento, ad esempio l'esempio di PowerShell in questa sezione. La creazione del collegamento da un Istanza gestita di SQL primario non è attualmente supportata con il interfaccia della riga di comando di Azure.

Se è necessario visualizzare tutti i collegamenti in un'istanza gestita, usare il comando Get-AzSqlInstanceLink PowerShell o az sql mi link show interfaccia della riga di comando di Azure in Azure Cloud Shell.

#  Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO CREATE MANAGED INSTANCE LINK
# Instructs Managed Instance to join distributed availability group on SQL Server
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"

# Enter the availability group name that was created on SQL Server
$AGNameOnSQLServer = "<AGNameOnSQLServer>"

# Enter the availability group name that was created on SQL Managed Instance
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# Enter the distributed availability group name that was created on SQL Server
$DAGName = "<DAGName>"

# Enter the database name that was placed in the availability group for replication
$DatabaseName = "<DatabaseName>"

# Enter the SQL Server IP
$SQLServerIP = "<SQLServerIP>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Build properly formatted connection endpoint
$SourceIP = "TCP://" + $SQLServerIP + ":<EndpointPort>"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI |
-Database @($DatabaseName) -PartnerEndpoint $SourceIP -InstanceLinkRole Secondary

#  Run in Azure Cloud Shell (select PowerShell console) 
# ============================================================================= 
# POWERSHELL SCRIPT TO CREATE MANAGED INSTANCE LINK 
# Instructs Managed Instance to join distributed availability group on SQL Server 
# ===== Enter user variables here ====  

# Enter your managed instance name – for example, "sqlmi1" 
$ManagedInstanceName = "<ManagedInstanceName>" 

# Enter the availability group name that was created on SQL Server
$AGNameOnSQLServer = "<AGNameOnSQLServer>"

# Enter the availability group name that was created on SQL Managed Instance
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# Enter the distributed availability group name that was created on SQL Server 
$DAGName = "<DAGName>"  

# Enter the database name that was placed in the availability group for replication 
$DatabaseName = "<DatabaseName>"  

# Enter the SQL Server IP 
$SQLServerIP = "<SQLServerIP>" 

# Enter the Azure subscription ID 
$SubscriptionID = "<SubscriptionID>" 
 
# ==== Do not customize the following cmdlet ==== 

# Find out the resource group name 
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName 

# Build properly formatted connection endpoint 
$DestinationIP = "TCP://" + $SQLServerIP + ":<EndpointPort>"  

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI |
-Database @($DatabaseName) -PartnerEndpoint $DestinationIP -InstanceLinkRole Primary

Il risultato di questa operazione è un indicatore orario dell'esecuzione corretta della richiesta di creazione di un collegamento.

Verificare il collegamento

Per verificare la connessione tra Istanza gestita di SQL e SQL Server, eseguire la query seguente in SQL Server. La connessione non sarà istantanea. Può volerci fino a un minuto prima che la DMV mostri una connessione riuscita. Continuare ad aggiornare la DMV fino a quando la connessione non viene visualizzata come CONNECTED per la replica Istanza gestita di SQL.

-- Run on SQL Server
SELECT
    r.replica_server_name AS [Replica],
    r.endpoint_url AS [Endpoint],
    rs.connected_state_desc AS [Connected state],
    rs.last_connect_error_description AS [Last connection error],
    rs.last_connect_error_number AS [Last connection error No],
    rs.last_connect_error_timestamp AS [Last error timestamp]
FROM
    sys.dm_hadr_availability_replica_states rs
    JOIN sys.availability_replicas r
    ON rs.replica_id = r.replica_id

Dopo aver stabilito la connessione, Esplora oggetti in SSMS potrebbe visualizzare inizialmente il database replicato nella replica secondaria in uno stato di Ripristino mentre la fase iniziale di seeding si occupa di trasferire e ripristinare il backup completo del database. Dopo il ripristino del database, la replica deve recuperare lo stato sincronizzato dei due database. Il database non sarà più in Ripristino una volta completato il seeding iniziale. Il seeding di database di piccole dimensioni potrebbe essere sufficientemente veloce da non visualizzare lo stato di Ripristino iniziale in SSMS.

Eseguire il primo backup del log delle transazioni

Se SQL Server è il database primario iniziale, è importante eseguire il primo backup del log delle transazioni su SQL Server dopo il completamento del seeding iniziale, quando il database non è più nello stato di Ripristino... su Istanza gestita di SQL di Azure. Eseguire quindi regolarmente backup del log delle transazioni di SQL Server per minimizzare la crescita eccessiva del log mentre SQL Server è nel ruolo primario.

Se Istanza gestita di SQL è il database primario, non è necessario eseguire alcuna azione perché Istanza gestita di SQL di Azure esegue automaticamente i backup del log.

Eliminare un collegamento

Se si vuole eliminare il collegamento perché non è più necessario o perché è in uno stato irreparabile e deve essere ricreato, è possibile farlo con PowerShell e T-SQL.

Per prima cosa, usare il comando Remove-AzSqlInstanceLink di PowerShell per eliminare il collegamento come nell'esempio seguente:

Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $managedInstanceName -Name $DAGName -Force 

Eseguire quindi lo script T-SQL seguente in SQL Server per eliminare il gruppo di disponibilità distribuito. Sostituire <DAGName> con il nome del gruppo di disponibilità distribuito usato per creare il collegamento:

USE MASTER 
GO 

DROP AVAILABILITY GROUP <DAGName>  
GO 

Infine, facoltativamente, è possibile rimuovere il gruppo di disponibilità se non è più disponibile. A tale scopo, sostituire <AGName> con il nome del gruppo di disponibilità e quindi eseguirlo nella rispettiva istanza:

DROP AVAILABILITY GROUP <AGName>  
GO 

Risoluzione dei problemi

Se viene visualizzato un messaggio di errore quando si crea il collegamento, esaminare il messaggio di errore nella finestra di output della query per altre informazioni. Per ulteriori informazioni, consultare per risolvere i problemi relativi al collegamento.

Contenuto correlato

Per usare il collegamento:

• Preparare l'ambiente per il collegamento dell'istanza gestita
• Configurare il collegamento tra SQL Server e Istanza gestita di SQL con SSMS
• Eseguire il failover sul collegamento
• Eseguire la migrazione con il collegamento
• Procedure consigliate per la gestione del collegamento
• Risolvere i problemi relativi al collegamento

Per altre informazioni sul collegamento:

• Panoramica del collegamento di Istanza gestita
• 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 replica log (LRS)