Estendi un gruppo di disponibilità Always On su Istanza gestita di SQL di Azure (anteprima)

Si applica a:Istanza gestita di SQL di Azure

Questo articolo ti insegna come estendere un gruppo di disponibilità Always On con più database tra SQL Server e Istanza gestita di SQL di Azure tramite il link Istanza gestita utilizzando SQL Server Management Studio (SSMS), PowerShell o interfaccia della riga di comando di Azure.

Questo articolo tratta la modalità collegamento a più database, che replica tutti i database in un gruppo di disponibilità tramite un unico collegamento. La modalità di collegamento a database singolo replica un database per collegamento.

Overview

Quando estendi un gruppo di disponibilità Always On tra SQL Server e Istanza gestita di SQL di Azure, crei un collegamento che replica più database in un gruppo di disponibilità verso la replica target. Il collegamento utilizza un gruppo di disponibilità distribuito per replicare le variazioni in quasi tempo reale dalla replica primaria corrente alle copie database in sola lettura sulla replica secondaria. Questo garantisce che le copie di sola lettura nel secondario rimangano aggiornate con il primario.

Puoi usare un gruppo di disponibilità esistente o iniziare con database autonomi. Quando selezioni database autonomi in SSMS, il wizard crea un gruppo di disponibilità a singolo nodo sul primario iniziale e replica i database selezionati tramite un unico collegamento.

Sia SQL Server che Istanza gestita di SQL di Azure possono essere l'istanza primaria iniziale. La creazione del collegamento da Istanza gestita di SQL richiede SQL Server 2022 o SQL Server 2025 con l'aggiornamento cumulativo richiesto e una politica corrispondente di aggiornamento Istanza gestita di SQL. Gli esempi di creazione in questo articolo partono da SQL Server. Non illustrano la procedura di creazione a partire da Istanza gestita di SQL. Il failover con role reversal tra SQL Server e Istanza gestita di SQL di Azure è supportato per istanze configurate con policy di aggiornamento corrispondenti.

Supportability

I seguenti requisiti si applicano all'estensione di un gruppo di disponibilità tramite un collegamento multi-database durante l'anteprima. SQL Server sia su Windows che su Linux è supportato. Devi installare l'aggiornamento cumulativo (CU) richiesto. Le versioni precedenti non supportano questa funzione.

Tenere presente quanto segue:

• L'edizione standard non è supportata perché i gruppi di disponibilità base supportano solo un database.
• SQL Server 2019 e le versioni precedenti non sono supportate per la modalità collegamento multidatabase perché mancano della tecnologia richiesta introdotta in SQL Server 2022.
• Per creare il collegamento da Istanza gestita di SQL o invertire nuovamente i ruoli a SQL Server, Istanza gestita di SQL deve utilizzare il criterio di aggiornamento corrispondente alla versione di SQL Server. Per la replica unidirezionale e il passaggio da SQL Server, la policy di aggiornamento di destinazione deve corrispondere, o essere superiore, alla tua versione di SQL Server.
  • SQL Server 2022 supporta la replica su istanze configurate con le politiche SQL Server 2022, SQL Server 2025 e Always-up-to-date.
  • SQL Server 2025 supporta la replica su istanze configurate con le politiche SQL Server 2025 e Always-up-to-date, ma non SQL Server 2022. Non puoi replicare i dati o tornare a SQL Server dopo il passaggio se le policy non corrispondono.

Per le versioni e le edizioni di SQL Server che supportano i collegamenti a database singolo, vedere Supportabilità delle versioni di Istanza gestita link.

Prerequisiti

Per estendere il tuo gruppo di disponibilità tra SQL Server e Istanza gestita di SQL di Azure, ti servono i seguenti prerequisiti:

• Una sottoscrizione di Azure attiva. Se non ne hai uno, crea un account gratuito.
• Una versione e un'edizione supportate di SQL Server con l'aggiornamento di servizio richiesto installato. Puoi utilizzare un gruppo di disponibilità Always On esistente o database standalone che SSMS inserisce in un nuovo gruppo di disponibilità a singolo nodo. I gruppi di disponibilità contenuti non sono supportati.
• Istanza gestita di SQL di Azure con una policy di aggiornamento adatta al tuo scenario. È richiesta una politica di matching quando Istanza gestita di SQL è la primaria iniziale o per il role reversal. Inizia se non hai un'istanza gestita in SQL.
• SQL Server Management Studio (SSMS) 22.10.2 o versione successiva.
• Per la configurazione scriptata, Azure PowerShell con modulo Az versione 16.3.0 o successiva e Az.SQL versione 7.1.0 o successiva, oppure interfaccia della riga di comando di Azure versione 2.90.0 o successiva. È anche possibile usare Azure Cloud Shell. Verifica che i moduli installati o la CLI soddisfino questi requisiti di versione.
• Ambiente preparato correttamente.
• Per un gruppo di disponibilità con più nodi, un listener di gruppo di disponibilità configurato. Usa l'indirizzo IP dell'ascoltatore quando configuri il collegamento, non l'indirizzo IP di una singola replica di SQL Server. Usare l'ascoltatore permette al collegamento di continuare a funzionare dopo un failover del gruppo di disponibilità locale.
• Nessun collegamento esistente su nessuna replica di SQL Server quando si abilita la modalità collegamento multidatabase. Prima di iniziare, rimuovi tutti i link che utilizzano la vecchia modalità di collegamento a singolo database.
• Sufficiente capacità di database e spazio di archiviazione disponibili sull'istanza gestita target per tutti i database nel tuo gruppo di disponibilità. Rivedi i limiti di risorse.

Permissions

Per SQL Server sono necessarie autorizzazioni sysadmin.

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

Abilita modalità collegamento multi-database

Il supporto per la modalità collegamento multi-database è disabilitato di default durante l'anteprima. Usa la stored procedure integrata sys.sp_multidb_milink per abilitarla su ogni replica di SQL Server nel gruppo di disponibilità, o sull'istanza di SQL Server dove prevedi di creare un gruppo a nodo singolo.

Esegui il seguente comando su ogni replica di SQL Server per abilitare la modalità collegamento multidatabase:

EXEC sys.sp_multidb_milink 1;

L'impostazione persiste durante i riavvii di SQL Server, quindi devi abilitarla solo una volta per ogni replica.

Per verificare l'impostazione, esegui la procedura memorizzata senza un parametro su ogni replica. Ritorna 1 quando abilitato e 0 quando disabilitato:

EXEC sys.sp_multidb_milink;

Se la stored procedure non è disponibile, verifica che la replica abbia una versione supportata di SQL Server e un aggiornamento cumulativo installati.

Per disabilitare la modalità collegamento multidatabase, prima rimuovere tutti i collegamenti, poi eseguire il seguente comando su ogni replica di SQL Server:

EXEC sys.sp_multidb_milink 0;

Prepara i database dei gruppi di disponibilità

Imposta ogni database SQL Server che vuoi replicare al modello completo di recupero, e poi crea un backup completo. Sia i database esistenti dei gruppi di disponibilità che quelli autonomi richiedono questa preparazione. Usa la procedura di backup SSMS nella guida alla configurazione del collegamento.

Per i database SQL Server, migra il certificato TDE su Istanza gestita di SQL. Per database Istanza gestita di SQL criptati collegati a SQL Server, utilizza una chiave gestita dal cliente accessibile al SQL Server di destinazione. Verificare la preparazione TDE del collegamento per i requisiti in ciascuna direzione.

Il link replica tutti i database nel gruppo di disponibilità selezionato. Non puoi scegliere un sottoinsieme, quindi controlla la capacità disponibile dell'istanza gestita SQL target prima di creare il link. La destinazione non deve contenere database con gli stessi nomi dei database che si vuole replicare. Sono consentiti database esistenti con nomi diversi, soggetti ai limiti di capacità dell'istanza.

Il collegamento supporta solo la replica dei database utente. La replica del database di sistema non è supportata. Per replicare gli oggetti a livello di istanza archiviati in master o msdb, crearne lo script ed eseguire script T-SQL nell'istanza di destinazione.

Configura l'ascoltatore e i certificati

Per un gruppo di disponibilità a più nodi, usa l'indirizzo IP dell'ascoltatore durante la configurazione del collegamento, sia in SSMS che in script. L'ascoltatore indirizza le connessioni alla replica primaria attuale. Non usare l'indirizzo IP di una singola replica di SQL Server come endpoint partner del link. Senza l'ascoltatore, il collegamento non continua a funzionare dopo un failover del gruppo di disponibilità locale. Per un gruppo di disponibilità a nodo singolo, incluso uno creato dalla procedura guidata di SSMS per database autonomi, utilizzare l'endpoint IP dell'istanza di SQL Server.

Il wizard SSMS scambia i certificati tra Istanza gestita di SQL di Azure e solo la replica primaria attuale di SQL Server. Non configura la fiducia dei certificati sulle altre repliche di SQL Server. Devi copiare e configurare manualmente i certificati richiesti su ogni altra replica di SQL Server, così che il collegamento possa continuare a funzionare dopo un failover del gruppo di disponibilità locale. Questo passaggio manuale si applica sia a SSMS che a configurazioni scriptate. Consulta Stabilire un rapporto di trust tra le istanze per la procedura di scambio dei certificati.

Prepararsi per la creazione di link scriptati

Usa SSMS per l'esperienza di configurazione consigliata. Il wizard automatizza molti passaggi di configurazione. Se non hai bisogno di automazione scriptata, salta questa sezione e continua alla scheda SSMS in Estendi il gruppo di disponibilità.

La configurazione scriptata è un'opzione avanzata che richiede esperienza nella configurazione di gruppi di disponibilità, endpoint e fiducia dei certificati. Completa questi passaggi solo se usi PowerShell o interfaccia della riga di comando di Azure con SQL Server come primario iniziale.

La checklist copre sia i gruppi di disponibilità esistenti sia i database autonomi. Dopo aver preparato database, trust e endpoint, riutilizza il tuo gruppo di disponibilità esistente o creane uno nel passo 4. Poi crea il gruppo di disponibilità distribuita. I comandi PowerShell e interfaccia della riga di comando di Azure per creare link non creano il gruppo di disponibilità per te.

Per ottenere uno script personalizzato per il proprio ambiente, usa la procedura guidata dei collegamenti di SSMS e seleziona Script nella pagina Riepilogo. Rivedi lo script generato ed eseguilo separatamente.

1. Abilita la modalità collegamento multi-database su ogni replica di SQL Server, o sull'istanza standalone di SQL Server, e prepara i database.
2. Instaurare una relazione di fiducia tra istanze. Segui i passaggi di creazione del certificato, scambio di chiavi pubbliche, importazione del certificato root e validazione della catena di certificati. Per un gruppo a più nodi, applicare i requisiti del certificato a ogni replica di SQL Server, non solo al principale attuale.
3. Metti in sicurezza l'endpoint di mirroring del database. Se il tuo gruppo di disponibilità ha già un endpoint, usa Altera un endpoint esistente invece di crearne un altro. Mantenere la porta endpoint configurata per il comando di creazione del collegamento.
4. Preparate il gruppo di disponibilità. Se hai già un gruppo di disponibilità che contiene tutti i database che vuoi replicare, riutilizzalo e salta la creazione di un nuovo gruppo. Se inizi con database autonomi, crea prima un gruppo di disponibilità su SQL Server. Nella scheda primaria iniziale di SQL Server, usa l'esempio a singolo nodo CREATE AVAILABILITY GROUP con CLUSTER_TYPE = NONE, ma sostituisci FOR DATABASE [<DatabaseName>] con la lista completa del database, come FOR DATABASE [DB01], [DB03], [DB05], [DB07]. Imposta <AGNameOnSQLServer> il nome che vuoi dare al nuovo gruppo. Esegui questo script prima di continuare con la creazione del gruppo di disponibilità distribuita. Non eseguirlo su un gruppo esistente né modificare la configurazione del cluster di un gruppo esistente.
5. Crea il gruppo di disponibilità distribuita su SQL Server. Usa la scheda primaria iniziale di SQL Server e inizia dalle istruzioni di creazione del gruppo di disponibilità distribuita. Imposta <AGNameOnSQLServer> sul gruppo di disponibilità che hai riutilizzato o creato nel passaggio precedente. Per un gruppo a più nodi, si usa l'indirizzo IP dell'ascoltatore per <SQLServerIP>. Per un gruppo a singolo nodo, usa l'endpoint dell'istanza di SQL Server. Mantieni <DAGName> come nome del collegamento e <AGNameOnSQLMI> come nome del gruppo di disponibilità dell'istanza gestita per il comando di creazione riportato di seguito.
6. Verifica i gruppi di disponibilità su SQL Server. Conferma che sia il gruppo di disponibilità Always On sia quello distribuito siano presenti. Poi torna a Estendi il gruppo di disponibilità, seleziona PowerShell o interfaccia della riga di comando di Azure, ed esegui il comando creazione multi-database in questo articolo invece del comando single-database dell'altra guida.

Estendi il gruppo di disponibilità

Per conservare i record di log necessari per il seeding, l'approccio raccomandato è abilitare il trace flag 12381 sulle build supportate di SQL Server prima di creare collegamenti, specialmente per database grandi o molti database in modalità collegamento multidatabase. Tuttavia, il flag non è richiesto e ci sono mitigazioni alternative, elencate nell'errore di risoluzione dei problemi 1412. Con il flag attivato, i backup dei log possono continuare, ma i record di log conservati non sono resi riutilizzabili. Monitora la crescita dei log di SQL Server e lo spazio libero su disco, e disabilita il flag non appena termina la seeding per tutti i link in fase di creazione.

Usa SSMS per automatizzare la creazione dei link, oppure scegli PowerShell o interfaccia della riga di comando di Azure per una configurazione avanzata scriptata. I seguenti esempi utilizzano SQL Server come primario iniziale. Puoi anche partire da Istanza gestita di SQL con una policy di aggiornamento corrispondente, ma qui non è trattato quel flusso di lavoro di creazione.

Per la configurazione scriptata, completa i passaggi di configurazione scriptata per riutilizzare o creare un gruppo di disponibilità contenente tutti i database che vuoi replicare, e poi crea il gruppo di disponibilità distribuita prima di eseguire il comando di creazione PowerShell o interfaccia della riga di comando di Azure. In alternativa, se si parte da database autonomi, la procedura SSMS in questa sezione crea automaticamente il gruppo di disponibilità a singolo nodo come parte dell'impostazione del collegamento.

Per la modalità collegamento a più database, specificare MultiDatabase esplicitamente negli script e fornire tutti i nomi del database nel gruppo di disponibilità. PowerShell imposta SingleDatabase di default se -LinkMode è omesso. Usa -LinkMode MultiDatabase in PowerShell o --link-mode MultiDatabase in interfaccia della riga di comando di Azure.

Update-Module -Name Az
Update-Module -Name Az.Sql

Get-InstalledModule -Name Az | Select-Object Name, Version
Get-InstalledModule -Name Az.Sql | Select-Object Name, Version

# Run in Azure Cloud Shell and select PowerShell.
$ManagedInstanceName = "<ManagedInstanceName>"

# Use the distributed availability group name from SQL Server as the link name.
# Use lowercase letters and hyphens, with no leading or trailing hyphen.
# The name must not already identify another link on this managed instance.
$DAGName = "<DAGName>"

# Enter the availability group names from the setup steps.
$AGNameOnSQLServer = "<AGNameOnSQLServer>"
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# Include every database in the availability group.
$DatabaseNames = @("DB01", "DB03", "DB05", "DB07")

# Use the listener IP for multiple-node AGs or the instance IP for single-node AGs.
$SQLEndpointIP = "<SQLEndpointIP>"
# Use the database mirroring endpoint port, normally 5022 unless customized.
$EndpointPort = "<EndpointPort>"

$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName
$SQLPartnerEndpoint = "TCP://" + $SQLEndpointIP + ":" + $EndpointPort

# Create the multi-database link with SQL Managed Instance as the secondary.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI -Database $DatabaseNames -PartnerEndpoint $SQLPartnerEndpoint -InstanceLinkRole "Secondary" -FailoverMode "Manual" -SeedingMode "Automatic" -LinkMode "MultiDatabase"

# Run in Azure Cloud Shell and select Bash.
ResourceGroupName="<ResourceGroupName>"
ManagedInstanceName="<ManagedInstanceName>"

# Use the distributed availability group name from SQL Server as the link name.
# Use lowercase letters and hyphens, with no leading or trailing hyphen.
# The name must not already identify another link on this managed instance.
DAGName="<DAGName>"

# Enter the availability group names from the setup steps.
AGNameOnSQLServer="<AGNameOnSQLServer>"
AGNameOnSQLMI="<AGNameOnSQLMI>"

# Include every database in the availability group.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB05},{database-name:DB07}]"

# Use the listener IP for multiple-node AGs or the instance IP for single-node AGs.
SQLEndpointIP="<SQLEndpointIP>"
# Use the database mirroring endpoint port, normally 5022 unless customized.
EndpointPort="<EndpointPort>"

SQLPartnerEndpoint="TCP://${SQLEndpointIP}:${EndpointPort}"

# Create the multi-database link with SQL Managed Instance as the secondary.
az sql mi link create --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --partner-availability-group-name "$AGNameOnSQLServer" --instance-availability-group-name "$AGNameOnSQLMI" --databases "$DatabaseNames" --partner-endpoint "$SQLPartnerEndpoint" --instance-link-role Secondary --failover-mode Manual --seeding-mode Automatic --link-mode MultiDatabase

Verifica replicazione

Dopo aver creato il collegamento o aggiunto database, i dati si replicano dalla replica primaria corrente alla replica secondaria attuale. SQL Server o Istanza gestita di SQL di Azure possono fungere da istanza primaria iniziale. Dopo l'inversione dei ruoli, i dati si replicano nella direzione opposta. A seconda della dimensione del database e della velocità della rete, ogni database potrebbe inizialmente trovarsi in uno stato di Ripristino sulla replica secondaria. Al termine dell’inserimento iniziale, il database viene ripristinato nella replica secondaria ed è pronto per i carichi di lavoro di sola lettura.

Su entrambe le repliche, usa Esplora oggetti in SSMS per visualizzare lo stato sincronizzato di ogni database replicato. Espandi Always On High Availability e Availability Groups per visualizzare il gruppo di disponibilità distribuita creato per il collegamento.

Quando SQL Server è primario, puoi continuare i backup dei log delle transazioni durante il seeding se il trace flag 12381 è abilitato su una build supportata. Se metti in pausa i backup dei log per evitare il troncamento prematuro, riprendili dopo il completamento dell'inizializzazione iniziale. Per ogni database senza un programma di backup del log, effettua il primo backup del log delle transazioni solo dopo la fine della seeding iniziale, non durante la seeding. Dopo che il seeding si è completato per tutti i link creati, disabilita il flag se l'hai abilitato e fai regolarmente i backup del log delle transazioni di SQL Server mentre SQL Server rimane primario. Quando Istanza gestita di SQL di Azure è principale, accetta automaticamente i backup dei log delle transazioni. Non è necessario fare backup manuali di log di SQL Server per questi database, mentre SQL Server è secondario.

La troncatura prematura del log durante il seeding può causare gli errori 1408 e 1412 nel log di errore di Istanza gestita di SQL. Nelle build che lo supportano, il trace flag 12381 impedisce questa troncazione. Disabilitalo una volta completata la seeding per tutti i link creati, e monitora l'uso del log delle transazioni, il tasso di crescita e lo spazio libero su disco mentre è attivato. I backup dei log possono continuare mentre i registri necessari rimangono conservati. Questa ritenzione non sostituisce i normali backup dei log dopo la seeding. Vedi Prevenire la troncatura prematura dei log.

Aggiungere database

Usa la procedura guidata di SSMS per aggiungere database dall'istanza primaria corrente, sia che si tratti di SQL Server o di Istanza gestita di SQL. Il mago automatizza i cambiamenti necessari. Per automazione avanzata, usa PowerShell o interfaccia della riga di comando di Azure. Aggiungere un database è un'operazione singola sul lato primario.

Prima di aggiungere database, verifica che il collegamento esistente utilizzi la modalità collegamento multi-database e che la destinazione abbia sufficiente capacità e spazio di archiviazione disponibili, senza nomi di database esistenti in conflitto con i nuovi database. Quando SQL Server è primario, imposta ogni nuovo database che non è già nel gruppo di disponibilità al modello completo di recupero e crea un backup completo usando la procedura di backup SSMS.

Aggiungi database con SSMS

Usa la procedura guidata Add Database to Istanza gestita di SQL di Azure Link per aggiungere database a un collegamento esistente a più database:

1. Connettiti alla replica primaria corrente in SSMS. In Esplora oggetti, espandere Always On - Alta disponibilità e Gruppi di disponibilità.

2. Clicca con il tasto destro sul gruppo di disponibilità distribuita per il tuo link, passa il mouse sul link Istanza gestita di SQL di Azure e seleziona Aggiungi database....

   

3. Prosegui attraverso Introduzione e Azure Login, poi seleziona il link a più database nella pagina Seleziona Link.

4. Nella pagina Seleziona database , seleziona i database che vuoi aggiungere. Puoi aggiungere database solo con uno stato Ready . I database già presenti nel link sono mostrati come Già parte del link selezionato. Risolvi eventuali problemi di idoneità prima di continuare.

   

5. Completa Convalida e rivedi Riepilogo. Seleziona Termina per eseguire la modifica, oppure seleziona Script per generare uno script senza eseguire la modifica, così puoi rivedere, personalizzare ed eseguire separatamente. Se esegui la modifica nel wizard, controlla i Risultati prima di chiuderlo.

Aggiungi database con script

Esegui l'operazione di aggiunta sul nodo primario corrente. Segui le istruzioni per quell'istante.

Quando SQL Server è principale

Usa T-SQL per aggiungere ogni database al gruppo di disponibilità. Il collegamento propaga l'aggiunta a Istanza gestita di SQL. Non è necessaria alcuna ulteriore azione su Istanza gestita di SQL. Non eseguire un aggiornamento PowerShell o interfaccia della riga di comando di Azure per questa aggiunta.

Quando Istanza gestita di SQL è la principale

Usa PowerShell o interfaccia della riga di comando di Azure per aggiornare il collegamento su Istanza gestita di SQL. Il collegamento propaga automaticamente i database aggiunti al gruppo di disponibilità. Non è necessario un passaggio separato su SQL Server. Fornisci l'iscrizione completa prevista, inclusi tutti i database esistenti che vuoi mantenere e i nuovi database. La lista fornita sostituisce l'attuale iscrizione. Omettere un database lo rimuove dall'appartenenza al link.

Ad esempio, per aggiungere DB09 quando il collegamento contiene già DB01, DB03, DB05 e DB07, mantenere questi quattro nomi nell’elenco e aggiungere anche DB09 all’elenco. Sostituisci i nomi delle risorse e del database con i tuoi valori.

# Include every existing database to retain and each new database to add.
$DatabaseNames = @("DB01", "DB03", "DB05", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include every existing database to retain and each new database to add.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB05},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Ripeti i passaggi di verifica della replica per ogni nuovo database aggiunto. Segui i passaggi manuali del backup dei log solo quando SQL Server è principale.

Rimuovere i database

Usa la procedura guidata di SSMS sull'istanza primaria corrente per automatizzare la rimozione da entrambi i lati. Rimuovere un database richiede di rimuoverlo dal collegamento su Istanza gestita di SQL e dal gruppo di disponibilità. Rimuoverlo solo da un lato non completa l'operazione.

Rimuovi i database con SSMS

I seguenti passaggi si applicano sia se SQL Server è l'istanza primaria sia se Istanza gestita di SQL è l'istanza primaria:

1. Connettiti alla replica primaria corrente in SSMS. In Esplora oggetti, espandere Always On - Alta disponibilità e Gruppi di disponibilità.

2. Clicca con il tasto destro sul gruppo di disponibilità distribuita per il link, passa il mouse sul link Istanza gestita di SQL di Azure e seleziona Remove Database....

   

3. Nella procedura guidata Remove Database from Istanza gestita di SQL di Azure Link, passa attraverso Introduction e Azure Login e seleziona il collegamento in Select Link.

4. Su Select Databases, seleziona i database da rimuovere. Ad esempio, seleziona DB05 per rimuoverlo dal link, poi seleziona Avanti.

   

5. Completa la Validazione, rivedi il Riassunto e seleziona Termina per eseguire la rimozione oppure Script per rivedere prima i comandi generati. Controlla i risultati per il completamento con successo prima di chiudere il wizard.

Rimuovere database tramite script

Rimuovi i database di entrambe le istanze. L'attuale primario determina quale istanza aggiornare per prima.

Gli esempi di PowerShell e interfaccia della riga di comando di Azure utilizzano le seguenti variabili:

Quando SQL Server è principale

1. Usa T-SQL per rimuovere i database dal gruppo di disponibilità.
2. Usa PowerShell o interfaccia della riga di comando di Azure per rimuovere i database dal link su Istanza gestita di SQL, come mostrato in questa sezione.

Per il passaggio Istanza gestita di SQL, fornisci l'elenco completo dei database da conservare, escludendo solo quelli che vuoi rimuovere. Ad esempio, se il link contiene DB09, DB05, DB07, DB05 e DB03, il comando seguente rimuove DB01 e mantiene gli altri quattro. Sostituisci i nomi delle risorse e del database con i tuoi valori.

# Include only the databases to retain, excluding DB05.
$DatabaseNames = @("DB01", "DB03", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include only the databases to retain, excluding DB05.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Quando Istanza gestita di SQL è la principale

1. Usa PowerShell o interfaccia della riga di comando di Azure per rimuovere i database dal link su Istanza gestita di SQL, come mostrato in questa sezione.
2. Usa T-SQL su SQL Server per rimuovere i database dal suo gruppo di disponibilità. La rimozione non è completa finché non completi questo passaggio.

Per il passaggio Istanza gestita di SQL, fornisci l'elenco completo dei database da conservare, escludendo solo quelli che vuoi rimuovere. Ad esempio, se il collegamento contiene DB09, DB05, DB07, DB05 e DB03, il seguente comando rimuove DB01 e mantiene gli altri quattro. Sostituisci i nomi delle risorse e del database con i tuoi valori.

# Include only the databases to retain, excluding DB05.
$DatabaseNames = @("DB01", "DB03", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include only the databases to retain, excluding DB05.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Conferma che i database rimossi non appartengano più al link o al gruppo di disponibilità. Rimuovere un database dalla replica non è la stessa cosa che cancellare la sua copia conservata. Esamina i database di entrambe le istanze prima di decidere se eliminare una copia che non ti serve più.

Fallover o passaggio su Azure

Utilizzare le procedure di failover esistenti in SSMS o script per invertire i ruoli tra SQL Server e Istanza gestita di SQL di Azure. L'inversione dei ruoli richiede che l'istanza gestita SQL utilizzi la policy di aggiornamento che corrisponde alla versione di SQL Server. Per la replica unidirezionale e il passaggio a Istanza gestita di SQL di Azure, la sua policy di aggiornamento deve corrispondere o essere superiore alla versione di SQL Server. Non puoi replicare i dati o tornare a SQL Server dopo se le policy non corrispondono. Rivedi le combinazioni supportate. Per indicazioni sulla migrazione e sul cutover, consulta Esegui la migrazione tramite il collegamento.

Monitorare e risolvere i problemi di replica

Utilizza le seguenti viste di gestione dinamica (DMV) e la vista catalogo su SQL Server per controllare il gruppo principale di disponibilità, la connettività delle repliche e lo stato di replica di ogni database:

SELECT * FROM sys.availability_groups;
SELECT * FROM sys.dm_hadr_availability_replica_states;
SELECT * FROM sys.dm_hadr_database_replica_states;
SELECT * FROM sys.dm_hadr_internal_availability_groups;
SELECT * FROM sys.dm_hadr_internal_availability_replicas;

Se le DMV interne di replica non sono disponibili, oppure se l'esecuzione della procedura archiviata sys.sp_multidb_milink indica che non è disponibile, verifica la versione di SQL Server e l'aggiornamento cumulativo installati in quella replica. Per la connettività generale e la risoluzione dei problemi di replicazione, vedi Troubleshoot the Istanza gestita link.

Limitations

Considera le seguenti limitazioni quando estendi un gruppo di disponibilità tramite un collegamento multidatabase:

• I nomi dei link devono usare lettere minuscole. I trattini sono permessi, ma un nome non può iniziare né finire con un trattino.
• Non degradare nessuna replica di SQL Server al di sotto di SQL Server 2022 CU27 o SQL Server 2025 CU9, a seconda dei criteri, mentre un collegamento in modalità multidatabase è attivo. Un downgrade al di sotto della CU richiesta può causare problemi imprevedibili anche senza un failover.
• I gruppi di disponibilità contenuti non sono supportati.
• I collegamenti a database singolo e a più database non possono coesistere sulla stessa istanza di SQL Server.
• Non puoi cambiare direttamente la modalità di un link. Per passare tra modalità di collegamento a database singolo e a modalità di collegamento a database multiplo, rimuovere tutti i collegamenti esistenti, cambiare la modalità su ogni replica di SQL Server e poi ricreare i collegamenti nella nuova modalità.
• Quando crei un collegamento per un gruppo di disponibilità esistente, tutti i database di quel gruppo devono essere replicati. Non puoi selezionare solo un sottoinsieme dei database in quel gruppo.
• La capacità residua del database sull'istanza SQL gestita di destinazione limita il numero di database che puoi replicare. General Purpose e Business Critical supportano fino a 100 database per istanza, e Next Gen General Purpose supporta fino a 500. I database esistenti sono conteggiati ai fini di questi limiti. Ad esempio, un'istanza con un limite di 100 database e 10 database esistenti ha capacità per 90 database in più. Per maggiori informazioni, vedi limiti di risorse.
• Aggiungere database al gruppo di disponibilità oltre la capacità disponibile di database della SQL managed instance di destinazione può avere successo su SQL Server, ma la replica su Istanza gestita di SQL fallisce. Questa condizione può lasciare il collegamento in uno stato incoerente che richiede la rimozione manuale dei database non replicati dal gruppo di disponibilità.
• L'aggiunta di database si propaga attraverso il link, ma rimuovere un database da un lato non lo rimuove automaticamente dall'altro. Se rimuovi un database dal gruppo di disponibilità, la sua copia rimane su Istanza gestita di SQL. Se rimuovi un database dal link su Istanza gestita di SQL, il database rimane nel gruppo di disponibilità senza replica tramite il link e richiede una pulizia manuale.
• Quando si aggiungono database a un collegamento esistente tramite SSMS, si possono aggiungere database solo con uno stato Ready . Non puoi aggiungere database che appartengono a un altro gruppo di disponibilità o che hanno un nome già presente nella destinazione.

Contenuti correlati

• Panoramica del collegamento di Istanza gestita
• Preparare l'ambiente per il collegamento
• Configurare il collegamento con SSMS
• Procedure consigliate per la gestione del collegamento
• Risolvere i problemi relativi al collegamento