Panoramica del collegamento Istanza gestita

Applica a:Istanza gestita di SQL di Azure

Questo articolo offre una panoramica del collegamento Istanza gestita, che consente la replica dei dati quasi in tempo reale tra SQL Server e Istanza gestita di SQL di Azure. Il collegamento offre flessibilità ibrida e mobilità dei database perché sblocca diversi scenari, ad esempio il ridimensionamento di carichi di lavoro di sola lettura, l'offload di analisi e la creazione di report in Azure e la migrazione a Azure. Inoltre, con SQL Server 2022 e versioni successive, il collegamento consente il ripristino di emergenza online con failback a SQL Server, nonché la configurazione del collegamento da Istanza gestita di SQL a SQL Server.

Per iniziare, vedere Preparare l'ambiente per il collegamento.

Panoramica

Il collegamento Istanza gestita usa gruppi di disponibilità distribuiti per estendere il patrimonio di dati in modo sicuro e protetto. Replica i dati in tempo quasi reale da SQL Server ospitati ovunque verso Istanza gestita di SQL di Azure, o da Istanza gestita di SQL di Azure verso SQL Server 2022 o versioni successive ospitati ovunque.

Il collegamento supporta istanze a nodo singolo e a più nodi SQL Server con o senza gruppi di disponibilità esistenti. Attraverso il link, puoi utilizzare i benefici di Azure senza dover migrare l'intero patrimonio dati di SQL Server sul cloud.

Il collegamento offre attualmente le funzionalità seguenti:

• Replica bidirezionale da SQL Server versioni 2016, 2017 e 2019: usare la funzionalità di collegamento per replicare i dati in modo unidirezionale dall'istanza di SQL alla Istanza gestita di SQL di Azure. Anche se è possibile effettuare manualmente il failover nell’istanza gestita in caso di emergenza, in questo modo si interrompe il collegamento e il failback non è supportato.
• ripristino di emergenza (SQL Server 2022 e SQL Server 2025): utilizzare la funzionalità di collegamento per replicare i dati tra SQL Server 2022 o SQL Server 2025 e un'istanza gestita di SQL, eseguire manualmente il failover su un'istanza secondaria durante un disastro e ripristinare sull'istanza primaria dopo aver mitigato il disastro. SQL Server o Istanza gestita di SQL possono essere il database primario iniziale.

È possibile continuare a eseguire il collegamento per tutto il tempo necessario, mesi e persino anni alla volta. E per il percorso di modernizzazione, se o quando si è pronti per la migrazione a Azure, il collegamento consente un'esperienza di migrazione notevolmente migliorata. La migrazione tramite il collegamento offre tempi di inattività minimi rispetto a tutte le altre opzioni di migrazione disponibili, fornendo una vera migrazione online al Istanza gestita di SQL.

È possibile usare i database replicati tramite il collegamento tra SQL Server e Istanza gestita di SQL di Azure per diversi scenari, ad esempio:

• Ripristino di emergenza
• Uso dei servizi Azure senza eseguire la migrazione al cloud
• Spostamento dei carichi di lavoro di sola lettura su Azure
• Migrazione a Azure
• Copia dei dati in locale

Modalità di collegamento

Il collegamento Istanza gestita supporta due modalità. La modalità determina se un link replica un database o tutti i database di un gruppo di disponibilità Always On di SQL Server esistente.

La modalità multi-database richiede aggiornamenti cumulativi specifici di SQL Server, edizioni supportate e l'opt-in su ogni replica di SQL Server. Una policy corrispondente di aggiornamento Istanza gestita di SQL è richiesta quando Istanza gestita di SQL è la primaria iniziale o quando si invertiscono i ruoli di ritorno a SQL Server. La replicazione non può colpire una versione inferiore, indipendentemente da quale istanza sia la destinazione. Per la replica unidirezionale e il passaggio da SQL Server a Istanza gestita di SQL, la policy di aggiornamento destinazione deve corrispondere o essere superiore alla versione sorgente di SQL Server. SQL Server 2022 supporta le politiche SQL Server 2022, SQL Server 2025 e Alwaysup-to-date. SQL Server 2025 supporta 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 questi requisiti, vedi Supportabilità del collegamento multiplo database.

I collegamenti in modalità collegamento a singolo database e in modalità collegamento a database multiplo non possono coesistere sulla stessa istanza di SQL Server. Non puoi cambiare direttamente la modalità di un link. Per cambiare modalità, rimuovi tutti i link esistenti, cambia la modalità su ogni replica di SQL Server e poi ricrea i link.

Supporto delle versioni

Sia i livelli di servizio Per utilizzo generico che business critical di Istanza gestita di SQL di Azure supportano il collegamento Istanza gestita. La funzionalità di collegamento funziona con le edizioni Enterprise, Developer e Standard di SQL Server.

La replica unidirezionale da SQL Server a Istanza gestita di SQL di Azure è disponibile a livello generale per ogni versione di SQL Server supportata. Il ripristino di emergenza con replica bidirezionale e failback è supportato a partire da SQL Server 2022 ed è basato sui criteri update con cui è configurata l'istanza gestita di SQL.

Nella tabella seguente sono elencate le funzionalità della funzionalità di collegamento e le versioni minime supportate SQL Server:

¹ Creare un collegamento con SQL Server 2022 come primario iniziale è supportato a partire dalla versione RTM di SQL Server 2022, mentre creare un collegamento con Istanza gestita di SQL di Azure come primario iniziale è supportato solo a partire da SQL Server 2022 CU10. Se si crea il collegamento da un'istanza gestita di SQL inizialmente primaria, il downgrade di SQL Server al di sotto di CU10 non è supportato mentre il collegamento è attivo, poiché ciò può causare problemi dopo il failover in qualsiasi direzione.

SQL Server versioni precedenti a SQL Server 2016 (SQL Server 2008 - 2014) non sono supportate perché la funzionalità di collegamento si basa sulla tecnologia del gruppo di disponibilità distribuito, introdotta in SQL Server 2016.

Oltre alla versione di SQL Server supportata, è necessario:

• Connettività di rete tra l'istanza di SQL Server e l'istanza gestita. Se SQL Server è in esecuzione in locale, usare un collegamento VPN o un Azure ExpressRoute. Se SQL Server è in esecuzione in una macchina virtuale (VM) Azure, distribuire la macchina virtuale nella stessa rete virtuale dell'istanza gestita o usare il peering di rete virtuale per connettere le due subnet separate.
• Distribuzione Istanza gestita di SQL di Azure di cui è stato effettuato il provisioning in qualsiasi livello di servizio.

Sono necessari anche gli strumenti seguenti:

Funzionamento del collegamento

La funzionalità di collegamento per Istanza gestita di SQL funziona creando un gruppo di disponibilità distribuito tra SQL Server e Istanza gestita di SQL di Azure. La soluzione supporta sistemi a nodo singolo con o senza gruppi di disponibilità esistenti oppure sistemi a più nodi con gruppi di disponibilità esistenti.

Una connessione privata, ad esempio una VPN o Azure ExpressRoute, connette una rete locale e Azure. Se si ospita SQL Server in una macchina virtuale Azure, il backbone Azure interno può connettere la macchina virtuale e l'istanza gestita di SQL, ad esempio con il peering di rete virtuale. I due sistemi stabiliscono una relazione di fiducia utilizzando l'autenticazione basata su certificati, in cui SQL Server e Istanza gestita di SQL scambiano le chiavi pubbliche dei rispettivi certificati.

Istanza gestita di SQL di Azure supporta più collegamenti provenienti dalla stessa o da fonti SQL Server diverse. La capacità del database è condivisa tra tutti i collegamenti e qualsiasi altro database presente nell'istanza gestita. General Purpose e Business Critical consentono di gestire fino a 100 database per istanza e Next-gen General Purpose ne supporta fino a 500. I database esistenti riducono la capacità disponibile per i database collegati. Per informazioni dettagliate, vedere Limiti delle risorse.

In modalità a database singolo, ogni collegamento replica un database. In modalità multidatabase, un collegamento può replicare più database e ogni database replicato conta per lo stesso limite di database a livello di istanza. Creare più link non aumenta quel limite. Ad esempio, un'istanza gestita con un limite di 100 database e 10 database esistenti ha capacità per 90 database aggiuntivi, sia che si replichino tramite un unico collegamento a più database sia tramite link separati a singolo database da istanze SQL Server configurate appropriatamente.

Un'unica istanza di SQL Server può creare più collegamenti paralleli con diverse istanze gestite SQL, anche in diverse regioni Azure. Tutti i collegamenti su quell'istanza di SQL Server devono usare la stessa modalità collegamento.

Usare il collegamento

Per facilitare la configurazione dell'ambiente iniziale, vedere la guida per preparare l'ambiente SQL Server per l'uso della funzionalità di collegamento con Istanza gestita di SQL:

• Preparare l'ambiente per il collegamento per SQL Server 2019 e versioni successive o per SQL Server 2016
• Automatizzare la preparazione dell'ambiente per il collegamento Istanza gestita usando uno script scaricabile. Per altre informazioni, vedere il blog sulla configurazione automatica dei collegamenti.

Dopo aver soddisfatto i requisiti di ambiente iniziali, creare il collegamento usando la procedura guidata automatizzata in SQL Server Management Studio (SSMS) o configurare il collegamento manualmente usando gli script:

• Configurare il collegamento con SSMS
• Configurare il collegamento con gli script

Dopo aver creato il collegamento, seguire le procedure consigliate per mantenere il collegamento:

• Procedure consigliate per gestire il collegamento

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

Usa la modalità multi-database link per estendere un gruppo di disponibilità SQL Server Always On esistente su Istanza gestita di SQL di Azure. Per i requisiti di anteprima e la configurazione, vedi Estendi un gruppo di disponibilità Always On su Istanza gestita di SQL di Azure.

Ripristino di emergenza

Il collegamento di Instantanea Gestita abilita il ripristino di emergenza, per cui, in caso di disastro, è possibile eseguire manualmente lo switch over del carico di lavoro dal server primario al secondario. Per iniziare, esaminare il ripristino di Disaster con Istanza gestita collegamento.

Con SQL Server 2016 a SQL Server 2019, il server primario è sempre SQL Server e il failover verso l'istanza gestita di SQL Server secondaria è unidirezionale. Il failback verso SQL Server non è supportato. È tuttavia possibile ripristinare i dati in SQL Server usando opzioni di spostamento dei dati, ad esempio replica transazionale o l'esportazione di un file bacpac.

Con SQL Server 2022 e SQL Server 2025, sia SQL Server che Istanza gestita di SQL (con un criterio di aggiornamento corrispondente) possono essere il database primario iniziale ed è possibile stabilire il collegamento fra SQL Server e Istanza gestita di SQL. È possibile eseguire il failback dei carichi di lavoro tra il database primario e quello secondario, ottenendo così un vero ripristino di emergenza bidirezionale.

Quando si esegue il failback a SQL Server, è possibile scegliere di eseguire il failback:

• online usando direttamente il collegamento Istanza gestita.
• offline eseguendo un backup del database da Istanza gestita di SQL e ripristinarlo nella tua istanza di SQL Server.

Usare i servizi di Azure

Utilizzare la funzionalità di collegamento per sfruttare i servizi di Azure utilizzando i dati di SQL Server senza eseguirne la migrazione al cloud. Gli esempi includono creazione di report, analisi, backup, Machine Learning e altri processi che inviano dati a Azure.

Scaricare i carichi di lavoro su Azure

È anche possibile usare la funzionalità di collegamento per eseguire l'offload dei carichi di lavoro per Azure. Ad esempio, un'applicazione può usare SQL Server per i carichi di lavoro di lettura/scrittura, mentre scarica i carichi di lavoro di sola lettura sulle distribuzioni di Istanza gestita di SQL in qualsiasi area Azure mondiale. Dopo aver stabilito il collegamento, il database primario in SQL Server è accessibile in lettura/scrittura, mentre i dati replicati nell'istanza gestita di SQL in Azure sono accessibili in sola lettura. Questa configurazione consente diversi scenari in cui i database replicati nell'istanza gestita di SQL possono essere usati per la scalabilità della lettura e il trasferimento dei carichi di lavoro di sola lettura su Azure. L'istanza gestita di SQL, in parallelo, può anche ospitare database di lettura/scrittura indipendenti, che consente anche di copiare il database replicato in un altro database di lettura/scrittura nella stessa istanza gestita di SQL per un'ulteriore elaborazione dei dati.

Per scaricare il carico di lavoro nell'istanza gestita SQL, connetti l'applicazione al database replicato e indirizza a esso le query di sola lettura. È possibile connettersi usando uno degli endpoint seguenti:

• L'endpoint locale alla rete virtuale, accessibile dall'interno della rete virtuale che ospita l'istanza gestita di SQL o da reti con peering. Questo è l'approccio consigliato quando l'applicazione viene eseguita in Azure o si connette tramite una VPN o ExpressRoute.
• Endpoint pubblico, accessibile tramite Internet. Usare questo approccio quando l'applicazione deve connettersi dall'esterno della rete virtuale e i peering o gli endpoint privati non sono disponibili. L'endpoint pubblico trasporta solo il traffico client e non può essere usato per la replica dei dati del collegamento, che usa sempre l'endpoint locale della rete virtuale.

Il link consente la consolidazione e la deconsolidazione dei carichi di lavoro in Azure. Ad esempio, puoi replicare database da più istanze SQL Server in una singola distribuzione Istanza gestita di SQL in Azure (consolidazione), oppure puoi replicare database da una singola istanza SQL Server a più istanze gestite SQL in qualsiasi regione Azure nel mondo (deconsolidazione). Quest’ultima opzione offre un modo efficiente per avvicinare rapidamente i carichi di lavoro ai clienti in qualsiasi area del mondo, che possono essere utilizzate come repliche di sola lettura.

Eseguire la migrazione a Azure

La funzionalità di collegamento facilita anche la migrazione da SQL Server a Istanza gestita di SQL, che consente di:

• Migrazione con tempi di inattività più efficienti e minimi rispetto a tutte le altre soluzioni attualmente disponibili.
• Migrazione online verso Istanza gestita di SQL in qualsiasi livello di servizio.

Poiché la funzionalità di collegamento consente una migrazione con tempi di inattività minimi, è possibile eseguire la migrazione all'istanza gestita man mano che si gestisce il carico di lavoro primario online. Sebbene sia attualmente possibile ottenere migrazioni online al livello di servizio Per utilizzo generico con altre soluzioni, la funzionalità di collegamento è l'unica soluzione che consente migrazioni online reali al livello di servizio Business Critical . Per un confronto approfondito della migrazione tra la migrazione con il collegamento e il Servizio di Riproduzione Log, vedere Confronto del collegamento di Istanza gestita con il Servizio di Riproduzione Log.

Copiare dati in locale

Con SQL Server 2022 e versioni successive, è possibile stabilire il collegamento da Istanza gestita di SQL a SQL Server, sbloccare scenari aggiuntivi, ad esempio creare una replica di database quasi in tempo reale al di fuori di Azure, testare i piani di continuità aziendale e soddisfare i requisiti di conformità.

Backup automatizzati

Dopo aver configurato un collegamento con Istanza gestita di SQL di Azure, viene eseguito automaticamente il backup dei database nel SQL managed instance nell'archiviazione Azure indipendentemente dal fatto che Istanza gestita di SQL sia primario. I backup automatizzati con il collegamento eseguono backup completi e del log delle transazioni, ma non backup differenziali, che possono causare tempi di ripristino più lunghi.

È possibile ridurre i costi operativi e di gestione locali sfruttando al tempo stesso l'affidabilità dei backup di Azure per i database replicati. È quindi possibile eseguire un ripristino puntuale nel tempo del database replicato in qualsiasi distribuzione Istanza gestita di SQL nella stessa area, come con qualsiasi altro backup automatico.

Replica passiva di Disaster Recovery senza obbligo di licenza

È possibile risparmiare sui costi di licenza vCore se si attiva il vantaggio di failover ibrido per il ripristino di emergenza passivo secondario solo per le istanze gestite di SQL che non hanno carichi di lavoro.

Per iniziare, vedere Replica passiva senza licenza.

Vantaggi economici

Se si designa un'istanza gestita replicata solo per il ripristino di emergenza, Microsoft non addebita i costi di licenza SQL Server per i vCore usati dall'istanza secondaria. L'istanza viene fatturata su base oraria e si potrebbero comunque pagare costi di licenza per un'ora intera se si aggiorna il beneficio di licenza durante l'ora.

Il vantaggio funziona in modo diverso per il modello di fatturazione con pagamento in base al consumo e il Vantaggio Azure Hybrid. Per un modello di fatturazione con pagamento in base al consumo, i vCore vengono scontati nella fattura. Se si usa l'Vantaggio Azure Hybrid per la replica passiva, il numero di vCore utilizzati dalla replica secondaria viene reinserito nel pool di licenze.

Ad esempio, come cliente pay-as-you-go, se hai 16 vCore assegnati all'istanza secondaria, sulla tua fattura apparirà uno sconto per 16 vCore se designi l'istanza secondaria per il failover ibrido.

In un altro esempio, se si dispone di 16 licenze Vantaggio Azure Hybrid e l'istanza gestita di SQL secondaria usa 8 vCore, dopo aver designato l'istanza secondaria per il failover ibrido, vengono restituiti 8 vCore al pool di licenze da usare con altre distribuzioni Azure SQL.

Per condizioni e termini precisi del vantaggio dei diritti di failover ibridi, vedere le condizioni di licenza SQL Server online nella sezione SQL Server - Diritti di failover.

Limiti

Quando si usa il collegamento, prendere in considerazione le seguenti limitazioni.

Le limitazioni di supporto delle versioni includono:

• Non è possibile usare Windows 10 e 11 client per ospitare l'istanza di SQL Server, perché non è possibile abilitare la funzionalità del gruppo di disponibilità AlwaysOn necessaria per il collegamento. È necessario ospitare istanze di SQL Server in Windows Server 2012 o versioni successive.
• La funzionalità di collegamento non supporta SQL Server versioni da 2008 a 2014, perché il motore SQL di queste versioni non dispone del supporto predefinito per i gruppi di disponibilità distribuiti necessari per il collegamento. Eseguire l'aggiornamento a una versione più recente di SQL Server per usare il collegamento.
• La replica dei dati e il failover from Istanza gestita di SQL a SQL Server 2022 o SQL Server 2025 non sono supportati dalle istanze configurate con il criterio di aggiornamento Always-up-to-date. L'istanza deve essere configurata con il criterio di aggiornamento di SQL Server 2022 o SQL Server 2025 update policy per eseguire le operazioni seguenti:
  • Stabilire un collegamento da Istanza gestita di SQL a SQL Server.
  • Eseguire il failover da Istanza gestita di SQL a SQL Server.
• Anche se è possibile stabilire un collegamento da SQL Server 2022 o SQL Server 2025 a un SQL managed instance configurato con il Always-up-to-date update policy, dopo il failover in Istanza gestita di SQL, non è possibile replicare i dati o eseguire il failback in SQL Server.

Ecco alcune limitazioni della replica dei dati:

• È possibile replicare solo i database utente. La replica del database di sistema non è supportata.
• La soluzione non replica gli oggetti a livello di server, i processi dell'agente o gli account di accesso utente da SQL Server a Istanza gestita di SQL.
• Per le versioni di SQL Server 2016, 2017 e 2019, la replica dei database utente dalle istanze di SQL Server alle distribuzioni di Istanza gestita di SQL avviene in un unico senso. Non è possibile replicare i database utente dalle distribuzioni Istanza gestita di SQL alle istanze di SQL Server tramite il collegamento. La replica bidirezionale con failback a un'istanza di SQL Server è disponibile solo per SQL Server 2022 o SQL Server 2025 quando Istanza gestita di SQL è configurato con il criterio di aggiornamento corrispondente.
• La configurazione di un collegamento da Istanza gestita di SQL a SQL Server non è supportata per i database Istanza gestita di SQL già collegati.

Le limitazioni di configurazione possibili sono:

• Se in un server sono presenti più istanze di SQL Server, è possibile configurare un collegamento per ogni istanza, ma è necessario configurare ogni istanza per usare un endpoint di mirroring del database separato, con una porta dedicata per ogni istanza. Solo l’istanza predefinita deve usare la porta 5022 per l’endpoint del mirroring del database.
• In modalità collegamento a database singolo, ogni collegamento replica un database. Puoi replicare più database stabilendo collegamenti separati a un singolo database. Per replicare tutti i database in un gruppo di disponibilità esistente tramite un unico collegamento, si utilizza la modalità multi-database link (preview). Gli aggiornamenti cumulativi richiesti e l'opt-in sono obbligatori su ogni replica di SQL Server; vedi supportabilità delle estensioni AG.
• La modalità collegamento a database singolo richiede un gruppo di disponibilità contenente un solo database. Questa restrizione non si applica alla modalità collegamento multidatabase, che replica tutti i database del gruppo esistente. Non rimuovere database dal tuo gruppo di disponibilità per usare la modalità multidatabase; segui Estendi un gruppo di disponibilità Always On su Istanza gestita di SQL di Azure.
• Un singolo Istanza gestita di SQL per utilizzo generico o business critical supporta fino a 100 collegamenti e un singolo Istanza gestita di SQL per utilizzo generico di nuova generazione supporta fino a 500 collegamenti, dallo stesso o da più origini SQL Server.
• Un collegamento Istanza gestita può replicare un database di qualsiasi dimensione se rientra nelle dimensioni di archiviazione scelte della distribuzione del Istanza gestita di SQL di destinazione.
• Istanza gestita'autenticazione dei collegamenti tra SQL Server e Istanza gestita di SQL è basata su certificati e disponibile solo tramite uno scambio di certificati. Non è possibile usare autenticazione di Windows per stabilire il collegamento tra l'istanza di SQL Server e l'istanza gestita di SQL.
• È possibile stabilire un collegamento con solo un endpoint VNet-local per Istanza gestita di SQL.
• Non è possibile usare endpoint pubblici o endpoint privati per stabilire il collegamento con l’istanza gestita.
• Non è possibile replicare i database con più file di log, perché Istanza gestita di SQL non supporta più file di log.

Le limitazioni delle caratteristiche includono:

• Non è possibile usare gruppi di failover con istanze che usano la funzionalità di collegamento. Non è possibile stabilire un collegamento in un'istanza gestita di SQL che fa parte di un gruppo di failover e viceversa non è possibile configurare un gruppo di failover in un'istanza con un collegamento stabilito.
• Se si utilizza Change Data Capture (CDC), log shipping o un service-broker con database replicati nell'istanza di SQL Server, quando il database viene migrato a una distribuzione di Istanza gestita di SQL, durante un failover su Azure, i client devono connettersi utilizzando il nome dell'istanza della replica primaria globale corrente. È necessario riconfigurare manualmente queste impostazioni.
• Se si usa la replica transazionale in un database con un collegamento stabilito, tenere presente quanto segue:
  • Il database collegato nella replica secondaria non può essere un Publisher in una topologia di replica transazionale.
  • Se si esegue la migrazione di un database configurato come Publisher in una topologia di replica transazionale tramite il collegamento, è necessario riconfigurare il database come Publisher nell'istanza di destinazione al termine della migrazione.
• Se si utilizzano transazioni distribuite con un database replicato dall'istanza di SQL Server e, in uno scenario di migrazione, nel passaggio al cloud, le funzionalità del Coordinatore di Transazioni Distribuite non verranno trasferite. Non è possibile che il database migrato venga coinvolto nelle transazioni distribuite con l'istanza di SQL Server, perché la distribuzione Istanza gestita di SQL non supporta transazioni distribuite con SQL Server in questo momento. Per riferimento, Istanza gestita di SQL attualmente supporta transazioni distribuite solo tra altre istanze gestite. Per altre informazioni, vedere Transazioni distribuite tra database cloud.
• Se si usa Transparent Data Encryption (TDE) per crittografare i database SQL Server, è necessario esportare la chiave di crittografia del database da SQL Server e caricarla in Azure Key Vault ed è necessario configurare anche l'opzione TDE BYOK in Istanza gestita di SQL prima di creare il collegamento.
• Se ripristino accelerato del database è disabilitato sul SQL Server di origine 2019 e versioni successive, non è più possibile abilitarlo dopo la migrazione ad Istanza gestita di SQL di Azure. Inoltre, 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.
• Se Service Broker è disabilitato nell'istanza di SQL Server di origine, non è possibile usare Service Broker nell'istanza gestita di SQL di destinazione dopo la migrazione.
• Non è possibile collegare Istanza gestita di SQL database crittografati con chiavi TDE gestite dal servizio 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.
• Non è possibile stabilire un collegamento tra SQL Server e Istanza gestita di SQL se la funzionalità usata nell'istanza di SQL Server non è supportata nel SQL managed instance. Ad esempio:
  • Non è possibile replicare i database con tabelle file e flussi di file, perché Istanza gestita di SQL non supporta tabelle file o flussi di file.
  • È possibile replicare i database che usano In-Memory OLTP solo per Istanza gestita di SQL nel livello di servizio Business Critical, perché il livello di servizio General Purpose non supporta In-Memory OLTP. Istanza gestita di SQL non supporta i database con più file OLTP In-Memory e non è possibile replicarli.

Tentativo di aggiungere una funzionalità non supportata a un database replicato in:

• SQL Server 2017, 2019 e 2022 hanno un errore.
• SQL Server 2016 causa l'interruzione del collegamento, che è quindi necessario eliminare e ricreare.

Per l'elenco completo delle differenze tra SQL Server e Istanza gestita di SQL, vedere differenze T-SQL tra SQL Server e Istanza gestita di SQL di Azure.

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
• Configurare il collegamento tra SQL Server e Istanza gestita di SQL con script
• Eseguire il failover del 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:

• 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 dei log (LRS)
• Riferimento di configurazione modificabile per Istanza gestita di SQL di Azure