Domande frequenti su Istanza gestita di SQL di Azure

Per un elenco delle funzionalità supportate in Istanza gestita di SQL, vedere Funzionalità di Istanza gestita di SQL di Azure.

Per le differenze di sintassi e comportamento tra Istanza gestita di SQL di Azure e SQL Server, vedere Differenze T-SQL rispetto a SQL Server.

Per informazioni sulle caratteristiche hardware disponibili, vedere Differenze tecniche nelle configurazioni hardware. Per i livelli di servizio disponibili e le relative caratteristiche, vedere Differenze tecniche tra i livelli di servizio.

Tutti i clienti sono idonei per qualsiasi livello di servizio. Sia le edizioni Standard che Enterprise coperte da Software Assurance possono essere scambiate usando il Vantaggio Azure Hybrid per il livello di servizio Utilizzo generico (che include l’upgrade al livello di servizio Utilizzo generico di nuova generazione, attualmente in anteprima) o Business Critical usando i rapporti di cambio seguenti: 1 Standard Edition = 1 Utilizzo generico, 1 Edizione Enterprise = 1 Business Critical, 1 Edizione Enterprise = 4 Utilizzo generico e 4 Utilizzo generico = 1 Edizione Enterprise. Per ulteriori informazioni, vedere Diritti specifici di Vantaggio Azure Hybrid.

Per l'elenco dei tipi di sottoscrizioni supportati, vedere Tipi di sottoscrizioni supportati.

Le istanze gestite possono essere create nella maggior parte delle aree di Azure. Vedere Aree supportate per Istanza gestita di SQL. Se è necessario creare un'istanza gestita in un'area attualmente non supportata, inviare una richiesta di supporto tramite il portale di Azure.

Istanza gestita di SQL prevede due limiti predefiniti: uno relativo al numero di subnet che è possibile usare e uno relativo al numero di vCore di cui è possibile effettuare il provisioning. I limiti variano in base ai tipi di sottoscrizioni e alle aree. Per l'elenco dei limiti delle risorse a livello di area in base al tipo di sottoscrizione, vedere la tabella in Limiti delle risorse a livello di area. Si tratta di limiti flessibili che è possibile aumentare su richiesta. Se è necessario effettuare il provisioning di più istanze gestite nelle aree correnti, inviare una richiesta di supporto, tramite il portale di Azure, per aumentare la quota. Per altre informazioni, vedere Richiedere aumenti di quota per il database SQL di Azure.

Il limite di 100 database per Istanza gestita di SQL è un limite rigido che non può essere modificato nei livelli di servizio Utilizzo generico e Business Critical. È possibile avere fino a 500 database nel livello di servizio per utilizzo generico di nuova generazione.

Può essere opportuno eseguire la migrazione ad altre versioni di Azure che supportano il carico di lavoro in uso: Hyperscale per il database SQL di Azure o SQL Server in Macchine virtuali di Azure.

Può essere opportuno eseguire la migrazione a SQL Server in Macchine virtuali di Azure o database SQL di Azure con memoria/cpu ottimizzata.

Per i problemi noti e i difetti del prodotto, vedere Problemi noti.

Per le funzionalità nuove e di anteprima, vedere Novità.

È possibile effettuare il provisioning di un'istanza gestita dal portale di Azure, da PowerShell, dall'interfaccia della riga di comando di Azure e dai modelli di ARM.

Sì, è possibile effettuare il provisioning di un'istanza gestita in una sottoscrizione esistente se tale sottoscrizione appartiene ai tipi di sottoscrizioni supportati.

Si tratta di un limite attuale nel componente sottostante che verifica il nome della subnet rispetto all'espressione regolare ^[a-zA-Z_][^\/:*?"<>|`'^]*(?<![.\s])$. Tutti i nomi che passano l'espressione regolare e sono nomi di subnet validi sono attualmente supportati.

È possibile ridimensionare l'istanza dal portale di Azure, da PowerShell, dall'interfaccia della riga di comando di Azure e dai modelli di ARM.

Si, puoi. Per istruzioni, vedere Spostare le risorse tra aree.

È possibile eliminare le istanze gestite tramite il portale di Azure, PowerShell, l'interfaccia della riga di comando di Azure o le API REST di Resource Manager.

I tempi previsti per la creazione di una nuova istanza gestita o la modifica del livello di servizio (vCore, archiviazione) dipendono da diversi fattori. Vedere Operazioni di gestione.

Il ripristino di ogni database è garantito durante l'intero periodo di conservazione definito, anche per i database creati e quindi eliminati dopo pochi secondi. Quando un database viene creato, eliminato o ripristinato, i backup vengono eseguiti a intervalli diversi per mantenere i dati in modo che sia possibile ripristinarli durante il periodo di conservazione specificato. Se un database viene eliminato prima del completamento di un'operazione di backup, l'operazione di eliminazione potrebbe essere bloccata con l'errore seguente:

Message database 'backup_restore_db_lkg_native_restore' already exists. Choose a different database name.

Per evitare questo errore, controllare lo stato dell'operazione di eliminazione prima di ricreare un database con lo stesso nome. Per altre informazioni, vedere sys.dm_operation_status. Quando lo stato dell'operazione diventa Completato, è possibile ripristinare o creare un database con lo stesso nome.

È probabile che si verifichi questo errore nei seguenti casi d'uso comuni:

• Se più database vengono eliminati e creati di nuovo con lo stesso nome in breve successione. Quando un database viene rimosso, viene eseguito il backup della parte finale rimanente del log delle transazioni in modo sincrono prima del completamento dell'operazione, come illustrato nell'immagine seguente:

  

  Non è possibile creare un database con lo stesso nome finché non viene eseguito il backup della parte finale del log e l'operazione di rilascio viene completata. La natura sequenziale dell'operazione di eliminazione inserisce i database eliminati in breve successione in una coda, che può prolungare il processo di eliminazione dei database e ritarda la possibilità di crearne di nuovi usando lo stesso nome.

• Se un database viene ripristinato ed eliminato prima della creazione di un backup completo. Quando un database viene ripristinato, il primo passaggio del processo di ripristino consiste nell'eseguire un nuovo backup completo del database. Se si tenta di ripristinare un database e quindi eliminarlo immediatamente prima del completamento del backup completo, non sarà possibile eliminare il database e creare un altro database con lo stesso nome finché non viene eseguito il backup completo e l'operazione di eliminazione del database non viene completata. A seconda delle dimensioni del database, il backup completo potrebbe richiedere ore.

È possibile che la sottoscrizione non sia idonea per l’Istanza gestita di SQL gratuita. In caso contrario, esiste un limite di un'istanza gratuita per ogni sottoscrizione. È necessario rimuovere un'istanza gratuita esistente per crearne un'altra. Se l'istanza gratuita è stata eliminata di recente, il banner dell'offerta gratuita può richiedere fino a un'ora.

È probabile che il credito per il mese sia esaurito. Passare all'istanza gestita di SQL nel portale di Azure e controllare lo stato per verificare se l'istanza è in stato arrestato a causa di crediti insufficienti.

Questa funzione attualmente non è disponibile.

Sì, è possibile ripristinare un backup automatico da Archiviazione di Azure oppure Ripristinare un backup del database usando SQL Server Management Studio (SSMS).

Nonostante le limitazioni delle risorse, la versione gratuita gestita di SQL è progettata per consentire di testare i carichi di lavoro senza alcun impatto. Le prestazioni che si verificano durante l'uso dell’Istanza gestita di SQL gratuito sono identiche alle prestazioni di una versione di produzione dell'istanza.

L’Istanza gestita di SQL gratuita offre 4 e 8 opzioni vCore. Se l'azienda richiede un'istanza con più risorse, creare un’Istanza gestita di SQL a pagamento completo.

Non è possibile modificare le opzioni di backup per l’Istanza gestita di SQL gratuito.

Attualmente, la sottoscrizione Student non è idonea. Per le sottoscrizioni idonee, esaminare i prerequisiti dell'offerta gratuita Istanza gestita di SQL.

La modifica del nome di un'istanza gestita non è supportata.

Sì, è possibile modificare la zona DNS predefinita dell'istanza gestita di SQL .database.windows.net con la propria. Tuttavia, la parte del nome host dell'istanza gestita del nome di dominio completo deve rimanere invariata.

Per usare un'altra zona DNS anziché quella predefinita, ad esempio .contoso.com:

• Usare Utilità di rete client di SQL Server (CliConfg) per definire un alias. È possibile usare solo il nome host dell'istanza gestita o il nome host dell'istanza gestita seguito da un nome di dominio personalizzato. Lo strumento CliConfg aggiunge solo alias nel Registro di sistema in "HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo" o "HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo" a seconda che si utilizzi la versione a 64 bit (C:\Windows\System32\cliconfg.exe) o la versione a 32 bit (C:\Windows\SysWOW64\cliconfg.exe), quindi può essere eseguita anche usando criteri di gruppo o uno script. Usare entrambi per garantire che i programmi a 32 bit e a 64 bit possano risolvere l'alias.
• Usare il record CNAME in DNS con il nome host dell'istanza gestita che punta al nome di dominio completo dell'istanza gestita. In questo caso, TrustServerCertificate=TRUE è necessario quando si usa l'autenticazione con Microsoft Entra ID (in precedenza Azure Active Directory).
• Usare record A in DNS con il nome host dell'istanza gestita che punta all'indirizzo IP dell'istanza gestita. L'uso dell'indirizzo IP non è consigliato, perché può cambiare senza preavviso. In questo caso, TrustServerCertificate=TRUE è necessario quando si usa l'autenticazione Microsoft Entra.

L'istanza gestita di SQL di Azure offre gli stessi livelli di prestazioni per calcolo e dimensioni di archiviazione delle altre opzioni di distribuzione del database SQL di Azure. Se si intende consolidare i dati in una singola istanza oppure è sufficiente una funzionalità supportata esclusivamente nell'istanza gestita di SQL, è possibile eseguire la migrazione dei dati tramite la funzionalità di esportazione/importazione (BACPAC). Di seguito sono disponibili altri modi da tenere presenti per eseguire la migrazione del database SQL a Istanza gestita di SQL:

• Uso di un'origine dati esterna
• Uso di SQLPackage
• Uso di BCP

Un'opzione consiste nell'esportare il database in BACPAC e quindi importare il file BACPAC. Si tratta dell'approccio consigliato se il database è inferiore a 100 GB.

È possibile usare la replica transazionale se tutte le tabelle nel database dispongono di chiavi primarie e nel database non sono presenti oggetti OLTP in memoria.

Per eseguire la migrazione dell'istanza di SQL Server, vedere Guida alla migrazione da SQL Server a Istanza gestita di SQL di Azure.

Per informazioni sulla migrazione da altre piattaforme, vedere Azure Database Migration Guide (Guida alla migrazione di database di Azure).

Per un confronto delle prestazioni tra l'istanza gestita e SQL Server, un punto di partenza valido è l'articolo Best practices for performance comparison between Azure SQL managed instance and SQL Server (Procedure consigliate per il confronto delle prestazioni tra l'istanza gestita di SQL di Azure e SQL Server).

Vedere Cause principali delle differenze di prestazioni tra Istanza gestita di SQL e SQL Server. Le dimensioni del file di registro delle transazioni possono influire sulle prestazioni dell’Istanza gestita di SQL per Utilizzo generico. Per altre informazioni, vedere Impatto delle dimensioni del file di log nelle prestazioni dell'istanza gestita per utilizzo generico.

È possibile ottimizzare le prestazioni dell'istanza gestita tramite:

• Ottimizzazione automatica, che garantisce massime prestazioni e carichi di lavoro stabili grazie al miglioramento continuo delle prestazioni basato sull'intelligenza artificiale e sull'apprendimento automatico.
• OLTP in memoria, che migliora la velocità effettiva e la latenza nei carichi di lavoro di elaborazione delle transazioni e offre informazioni aziendali più rapide.
• Applicazione di alcune delle procedure consigliate per l'ottimizzazione di applicazioni e database.
• Modifica del tipo di connessione dalla modalità proxy alla modalità di reindirizzamento per una minore latenza e una maggiore velocità effettiva, nel caso in cui il carico di lavoro sia costituito da numerose transazioni di piccole dimensioni.

Per ottimizzare le prestazioni in un'istanza per utilizzo generico, è consigliabile aumentare le dimensioni del file di dati. Per ottimizzare le prestazioni di archiviazione in un'istanza per utilizzo generico, vedere Storage performance best practices and considerations for Azure SQL DB Managed Instance (General Purpose) (Considerazioni e procedure consigliate sulle prestazioni di archiviazione di Istanza gestita di database SQL di Azure (per utilizzo generico)).

Vedere Analyzing wait statistics on SQL Managed Instance (Analisi delle statistiche di attesa in Istanza gestita di SQL). Le statistiche di attesa sono informazioni che possono aiutare a comprendere il motivo per cui la durata della query è eccessiva e a identificare le query in attesa di azioni nel motore di database.

Per tutte le opzioni possibili relative al monitoraggio e all'invio di avvisi su consumi e prestazioni di Istanza gestita di SQL, vedere il post di blog Azure SQL Managed Instance monitoring options (Opzioni di monitoraggio di Istanza gestita di SQL di Azure). Per il monitoraggio delle prestazioni in tempo reale per Istanza gestita di SQL, vedere Monitoraggio delle prestazioni in tempo reale per Istanza gestita di SQL di Azure.

Vedere Monitoraggio e ottimizzazione delle prestazioni.

Vedere Monitoraggio delle prestazioni in tempo reale per Istanza gestita di database SQL di Azure.

Sì, SQL Profiler è supportato in Istanza gestita di SQL. Per altre informazioni, vedere Profiler SQL. È tuttavia consigliabile prendere in considerazione gli eventi estesi per l'attività di "traccia" con minore impatto sull'istanza monitorata. Per altre informazioni, vedere Eventi estesi.

No, non sono supportati. Per il monitoraggio dei database, è possibile usare DMV e Query Store in combinazione con SQL Profiler e XEvent.

Vedere Monitor CPU usage on your SQL Server and Azure SQL (Monitorare l'utilizzo della CPU in SQL Server e Azure SQL).

Sì. Per istruzioni, vedere Creare avvisi per Istanza gestita di SQL. Per altri suggerimenti, vedere il blog.

Non è possibile, le metriche di avviso sono disponibili solo per l'istanza gestita. Le metriche di avviso per i singoli database in un’istanza gestita non sono disponibili.

Le dimensioni di archiviazione per Istanza gestita di SQL dipendono dal livello di servizio selezionato (per utilizzo generico, per utilizzo generico di nuova generazione o business critical). Per le limitazioni di archiviazione di questi livelli di servizio, vedere Limiti delle risorse.

La quantità minima di spazio di archiviazione disponibile in un'istanza è di 32 GB. Lo spazio di archiviazione può essere aggiunto in incrementi di 32 GB fino alle dimensioni massime di archiviazione. I primi 32 GB sono gratuiti.

Sì, entro certi limiti, è possibile acquistare l'archiviazione dei componenti aggiuntivi, indipendentemente dal calcolo. Vedere nella tabella lo spazio di archiviazione massimo riservato dell'istanza.

Per ottimizzare le prestazioni di archiviazione, vedere Storage performance best practices and considerations for Azure SQL DB Managed Instance (General Purpose) (Considerazioni e procedure consigliate sulle prestazioni di archiviazione di Istanza gestita di database SQL di Azure (per utilizzo generico)).

No, l'archivio di backup non viene dedotto dallo spazio di archiviazione dell'istanza gestita. L'archivio di backup è indipendente dallo spazio di archiviazione dell'istanza e non ha dimensioni limitate. L'archivio di backup è limitato al periodo di tempo per cui conservare il backup dei database dell'istanza, configurabile fino a 35 giorni. Per i dettagli, vedere Backup automatizzati.

Per tenere traccia del momento in cui sono stati eseguiti backup automatizzati in un'istanza gestita di SQL, vedere Monitorare l'attività di backup.

Sì, è possibile creare un backup di sola copia completo in Archiviazione BLOB di Azure, ma sarà ripristinabile solo in un’Istanza gestita. Per altre informazioni dettagliate, vedere Backup di sola copia. Il backup di sola copia non è tuttavia possibile se il database è crittografato usando la funzionalità TDE gestita dal servizio perché il certificato usato per la crittografia non è accessibile. In tal caso, usare la funzionalità di ripristino temporizzato per spostare il database in un'altra istanza di Istanza gestita o passare alla chiave gestita dal cliente.

Sì, è supportato e disponibile per SQL Server 2005 e versioni successive. Per usare il ripristino nativo, caricare il file con estensione bak in Archiviazione BLOB di Azure ed eseguire i comandi T-SQL. Per altre ulteriori informazioni, vedere Ripristino nativo dall'URL.

Sì, ma solo per SQL Server 2022, durante il periodo di supporto mainstream di SQL Server 2022. È possibile che, in futuro, alcune funzionalità di Istanza gestita di SQL di Azure potrebbero essere introdotte che richiedono modifiche al formato del database, rendendo i backup incompatibili con l’ultima versione di SQL Server. L'accesso a tali funzionalità richiede il consenso esplicito.

I database di sistema non vengono replicati nell'istanza secondaria in un gruppo di failover. Pertanto, gli scenari che dipendono dagli oggetti dei database di sistema sono impossibili nell'istanza secondaria, a meno che gli oggetti non vengano creati manualmente nel database secondario. Per una soluzione alternativa, vedere Abilitare nell'oggetto scenari dipendenti dai database di sistema.

Quali sono i vincoli correnti del gruppo di sicurezza di rete in ingresso e in uscita nella subnet di Istanza gestita?

Le regole necessarie per il gruppo di sicurezza di rete e la route definita dall'utente sono descritte in configurazione subnet assistita dal servizio e sono automaticamente impostate dal servizio. Tenere presente che queste regole sono solo quelle necessarie per la gestione del servizio. Per connettersi a un'istanza gestita e usare funzionalità diverse, è necessario impostare regole aggiuntive specifiche della funzionalità che si vuole gestire.

Come è possibile impostare regole del gruppo di sicurezza di rete in ingresso sulle porte di gestione?

Istanza gestita di SQL è responsabile dell'impostazione delle regole sulle porte di gestione. Questa operazione viene ottenuta tramite la funzionalità denominata configurazione della subnet con il supporto del servizio. Ciò consente di garantire un flusso ininterrotto del traffico di gestione per soddisfare un contratto di servizio.

Sì. È possibile analizzare il traffico proveniente dal gruppo di sicurezza di rete configurando i log dei flussi di Network Watcher.

Sì. Dopo aver effettuato il provisioning di un'istanza gestita, è possibile impostare un gruppo di sicurezza di rete che controlla l'accesso in ingresso alla porta 1433. È consigliabile restringere il più possibile l'intervallo IP.

No. Questa operazione non è supportata per diversi motivi:

• Il traffico di routing che rappresenta la risposta alla richiesta di gestione in ingresso sarebbe asimmetrico e non potrebbe funzionare.
• Il routing del traffico che passa all'archiviazione di Azure sarebbe influenzato dai vincoli di velocità effettiva e dalla latenza, quindi in questo modo non sarebbe possibile fornire la qualità e la disponibilità del servizio previste.
• Queste configurazioni sono soggette a errori e non sono supportate.

Sì. Il modo più semplice per ottenere questo risultato è aggiungere una regola 0/0 a una route definita dall'utente associata alla subnet dell'istanza gestita per instradare il traffico tramite l'appliance virtuale di rete.

La subnet deve avere un numero sufficiente di indirizzi IP disponibili. Per determinare le dimensioni della subnet della rete virtuale per Istanza gestita di SQL, vedere Determinare l'intervallo e le dimensioni della subnet necessari per Istanza gestita di SQL di Azure.

Se nella subnet in cui viene effettuato il provisioning dell'istanza gestita non è disponibile un numero sufficiente di indirizzi IP, sarà necessario creare una nuova subnet dove spostare l'istanza gestita SQL. Si consiglia anche di creare la nuova subnet con più indirizzi IP allocati, in modo da evitare situazioni simili nelle operazioni di aggiornamento future. Informazioni su come Spostare Istanza gestita di SQL di Azure tra subnet.

No. È possibile usare una subnet vuota o una subnet che contiene già istanze gestite.

No, se sono presenti istanze gestite all'interno. Si tratta di un limite dell'infrastruttura di rete di Azure. È possibile solo aggiungere altro spazio indirizzi a una subnet vuota.

Sì. Un'istanza gestita di SQL può essere spostata in un'altra subnet all'interno della stessa rete virtuale o in una rete virtuale diversa in modo online. Informazioni su come Spostare Istanza gestita di SQL di Azure tra subnet.

Non è obbligatorio. È possibile creare una rete virtuale per Istanza gestita di SQL di Azure oppure configurare una rete virtuale esistente per Istanza gestita di SQL di Azure.

No. Attualmente l'inserimento di un'istanza gestita in una subnet che contiene già altri tipi di risorse non è supportato.

No, questa operazione non è supportata. Il nome host dell'istanza gestita viene associato al bilanciamento del carico davanti al cluster virtuale dell’istanza gestita. Poiché un cluster virtuale può ospitare più istanze gestite, non è possibile instradare una connessione all'istanza gestita corretta senza specificarne il nome. Per altre informazioni sull'architettura del cluster virtuale di Istanza gestita di SQL, vedere Architettura della connettività del cluster virtuale.

Attualmente, solo gli endpoint privati alle istanze gestite garantiscono indirizzi IP statici.

In situazioni rare ma necessarie, è possibile eseguire una migrazione online di un'istanza gestita a un nuovo cluster virtuale o a un gruppo di macchine virtuali diverso all'interno del cluster virtuale, a causa di modifiche dello stack di tecnologie che mirano a migliorare la sicurezza e l'affidabilità del servizio. La migrazione a un nuovo gruppo di macchine virtuali o cluster virtuale comporta la modifica dell'indirizzo IP associato al nome host dell'istanza gestita. Il servizio di istanza gestita non fornisce de il supporto di indirizzi IP statici e si riserva il diritto di modificare l’indirizzo IP senza preavviso nell'ambito dei normali cicli di manutenzione.

Per il motivo precedente, gli endpoint pubblici e locali della rete virtuale devono essere accessibili solo tramite i nomi di dominio associati. Non è consigliabile affidarsi all'immutabilità del proprio indirizzo IP perché ciò potrebbe causare una prolungata indisponibilità mentre il servizio è integro.

Se è necessario un indirizzo IP statico raggiungibile dall'esterno della rete virtuale, è possibile distribuire Firewall di Azure con un indirizzo IP pubblico front-end e configurare una regola NAT per convertire il traffico in ingresso nell'endpoint privato di un'istanza gestita. Configurare quindi la risoluzione DNS o configurare gli alias client in modo che i client SQL si connettano all'indirizzo IP pubblico del firewall tramite il nome di dominio completo dell'istanza gestita.

Sì, è possibile abilitare un endpoint pubblico per abilitare il traffico in ingresso da Internet per raggiungere Istanza gestita di SQL. Per altre informazioni, vedere Utilizzare Istanza gestita di SQL con endpoint pubblici e Configurare un endpoint pubblico in Istanza gestita di SQL.

No, l'uso di una porta personalizzata non è disponibile. Per l'endpoint della rete virtuale locale, Istanza gestita di SQL usa il numero di porta predefinito 1433 e per l'endpoint dati pubblico, Istanza gestita di SQL usa il numero di porta predefinito 3342.

Sia il peering di reti virtuali globale che la rete WAN virtuale di Azure sono metodi consigliati per connettere due istanze gestite in aree diverse. In alternativa, è possibile utilizzare il peering del circuito ExpressRoute. Se nessuna delle due opzioni è possibile nell'ambiente, l'unico metodo di connettività è una connessione VPN da sito a sito. Configurare una VPN da sito a sito usando il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure

Il supporto per il peering di reti virtuali globale per i cluster virtuali appena creati è stato aggiunto a Istanza gestita di SQL di Azure il 22 settembre 2020. Pertanto, il peering di reti virtuali globale è supportato per le istanze gestite ospitate create in subnet vuote dopo 22 settembre 2020. Per tutte le altre istanze distribuite prima di questa data, il supporto del peering è limitato alle reti nella stessa area a causa dei vincoli del peering di reti virtuali globale. Per ulteriori informazioni, vedere la sezione pertinente dell'articolo Domande frequenti sulle reti virtuali di Azure.

Per usare il peering di reti virtuali globale per le istanze create prima di settembre 2020, valutare la possibilità di configurare una finestra di manutenzione o di spostare l’istanza in una nuova subnet, in quanto entrambe le opzioni sposteranno l'istanza in un nuovo cluster virtuale che supporta il peering di reti virtuali globale.

Se necessario, vedere Come verificare se il peering di reti virtuali globale è supportato nel cluster virtuale per l'istanza gestita di SQL.

Per mitigare eventuali rischi di esfiltrazione di dati, è consigliabile applicare un set di impostazioni e controlli di sicurezza:

• Abilitare Transparent Data Encryption (TDE) in tutti i database.
• Disabilitare Common Language Runtime (CLR). Questa operazione è consigliata anche in locale.
• Utilizzare solamente l’Autenticazione Microsoft Entra.
• Accedere all'istanza con un account amministratore di database con privilegi limitati.
• Configurare l'accesso JIT JumpBox per l'account sysadmin.
• Abilitare il servizio di controllo SQL e integrarlo con meccanismi di avviso.
• Abilitare il Rilevamento delle minacce dalla suite Microsoft Defender per SQL.
• Applicare un criterio dell'endpoint di servizio alla subnet per controllare il traffico in uscita a Archiviazione di Azure.
• CREATE EXTERNAL TABLE AS SELECT (CETAS) è disabilitato per impostazione predefinita. Per abilitare CETAS tramite l'opzione di configurazione del server allowPolyBaseExport, vedere CREATE EXTERNAL TABLE AS SELECT (CETAS).

Sì. Vedere Risoluzione dei nomi DNS privati in Istanza gestita di SQL di Azure.

Sì. Vedere Risoluzione dei nomi DNS privati in Istanza gestita di SQL di Azure.

La configurazione del fuso orario può essere impostata quando viene effettuato il provisioning di un'istanza gestita per la prima volta. La modifica del fuso orario di un'istanza gestita esistente non è supportata. Per informazioni dettagliate, vedere Limitazioni del fuso orario.

Alcune soluzioni alternative includono la creazione di una nuova istanza gestita con il fuso orario appropriato e quindi l'esecuzione di un backup e un ripristino manuali o un ripristino temporizzato tra istanze (opzione consigliata).

Sì, i clienti possono creare account di accesso membri del ruolo sysadmin. Anche i clienti che presuppongono il privilegio sysadmin si assumono la responsabilità di eseguire l'istanza, con un impatto negativo sull'impegno del contratto di servizio. Per aggiungere un account di accesso al ruolo del server amministratore di sistema, vedere Autenticazione di Microsoft Entra.

Sì, Transparent Data Encryption è supportata per Istanza gestita di SQL di Azure. Per informazioni dettagliate, vedere Transparent Data Encryption per Istanza gestita di SQL.

Sì, Azure Key Vault per lo scenario BYOK è disponibile per Istanza gestita di SQL di Azure. Per informazioni dettagliate, vedere Transparent Data Encryption con chiave gestita dal cliente.

Si, puoi. Per eseguire la migrazione di un database SQL Server crittografato, è necessario esportare e importare i certificati esistenti in Istanza gestita di SQL, quindi eseguire un backup completo del database e ripristinarlo in Istanza gestita.

È anche possibile usare Servizio Migrazione del database di Azure per eseguire la migrazione dei database con crittografia TDE.

È possibile ruotare la protezioni TDE per Istanza gestita di SQL usando Azure Cloud Shell. Per istruzioni, vedere Transparent Data Encryption in Istanza gestita di SQL usando una chiave personale da Azure Key Vault.

Sì, non è necessario decrittografare il database per poterlo ripristinare in Istanza gestita di SQL. Per poter leggere i dati dal file di backup crittografato, è necessario fornire un certificato o una chiave usata come protezione con chiave di crittografia nel sistema di origine a Istanza gestita di SQL. È possibile procedere in due modi:

• Caricare la protezione del certificato in Istanza gestita di SQL. Questa operazione può essere eseguita solo con PowerShell. Lo script di esempio descrive l'intero processo.
• Caricare la protezione con chiave asimmetrica per Azure Key Vault e puntarvi Istanza gestita di SQL. Questo approccio è simile al caso d'uso BYOK (Bring Your Own Key) TDE (Transparent Data Encryption) che usa l'integrazione Key Vault per archiviare la chiave di crittografia. Se non si vuole usare la chiave come protezione con chiave di crittografia e si intende solo rendere disponibile la chiave per Istanza gestita di SQL per ripristinare i database crittografati, seguire le istruzioni per la configurazione Bring Your Own Key Transparent Data Encryption e non selezionare la casella di controllo Imposta la chiave predefinita come protezione TDE predefinita.

Dopo aver reso disponibile la protezione della crittografia per Istanza gestita di SQL, è possibile eseguire la procedura di ripristino del database standard.

Istanza gestita di SQL offre il modello di acquisto basato su vCore.

È possibile risparmiare sui costi con i vantaggi Azure SQL nei modi seguenti:

• Ottimizzare gli investimenti esistenti nelle licenze locali e risparmiare fino al 55% con il Vantaggio Azure Hybrid.
• Eseguire il commit in una prenotazione per le risorse di calcolo e risparmiare fino al 33% con il vantaggio dell'istanza riservata. Combinarlo con il Vantaggio Azure Hybrid per risparmiare fino all'82%.
• Risparmiare fino al 55% rispetto ai prezzi di listino con il vantaggio dei prezzi di sviluppo/test di Azure che offre tariffe scontate per i carichi di lavoro di sviluppo e test in corso.

Per essere idoneo per il vantaggio dell'istanza riservata, il tipo di sottoscrizione deve essere un contratto Enterprise (numeri di offerta: MS-AZR-0017P o MS-AZR-0148P) o un contratto singolo con prezzi con pagamento in base al consumo (numeri di offerta: MS-AZR-0003P o MS-AZR-0023P). Per altre informazioni sulle prenotazioni, vedere Vantaggio dell'istanza riservata.

È possibile annullare o scambiare le prenotazioni oppure chiederne il rimborso con determinate limitazioni. Per altre informazioni, vedere Scambi e rimborsi self-service per le prenotazioni di Azure.

Per esplorare le opzioni per i prezzi di Istanza gestita di SQL, vedere la pagina dei prezzi.

È possibile usare la soluzione Gestione dei costi di Microsoft. Passare a Sottoscrizioni nel portale di Azure e selezionare Analisi dei costi.

Usare l'opzione osti accumulati, quindi filtrare in base al tipo di risorsa microsoft.sql/managedinstances.

È possibile usare strumenti client Microsoft o di terze parti compatibili per accedere a Istanza gestita di SQL senza che vengano addebitati costi aggiuntivi nella fattura di Azure. Tuttavia, se alcuni degli strumenti richiedono una licenza, è necessario disporre di un software con licenza legale. Questo è disciplinato da contratti separati che hai con ogni singolo produttore di strumenti.

La quantità di spazio dell'archivio di backup gratuito è identica a quella della risorsa di archiviazione dati riservata acquistata, indipendentemente dal periodo di conservazione del backup impostato. Se l'utilizzo dell'archivio di backup rientra nello spazio dell'archivio di backup gratuito allocato, i backup automatizzati nell'istanza gestita di SQL non avranno alcun costo aggiuntivo, pertanto saranno gratuiti. Il superamento dell'uso dell'archivio di backup sopra lo spazio disponibile comporta costi aggiuntivi. Per informazioni dettagliate, vedere la sezione Archivio di backup della pagina dei prezzi. Altre informazioni tecniche su Istanza gestita di SQL backup automatizzati sono disponibili in Informazioni dettagliate sull'utilizzo dell'archivio di backup.

È possibile monitorare i costi relativi all'archivio di backup tramite il portale di Azure. Per istruzioni, vedere Monitorare i costi dei backup automatizzati.

Per ottimizzare i costi dell'archivio di backup, vedere Fine tuning backup storage costs on SQL Managed Instance (Ottimizzare i costi dell'archivio di backup in Istanza gestita di SQL).

Case study su Istanza gestita di SQL:

• Komatsu
• KMD
• PowerDETAILS
• Allscripts

Per comprendere meglio i vantaggi, i costi e i rischi associati alla distribuzione di Istanza gestita di SQL di Azure, è disponibile anche uno studio di Forrester: Il Total Economic Impact dei database dell'istanza gestita di SQL di Microsoft Azure.

I criteri password di Istanza gestita di SQL per gli account di accesso di SQL ereditano i criteri della piattaforma Azure applicati alle macchine virtuali che formano un cluster virtuale che contiene l'istanza gestita. Al momento non è possibile modificare queste impostazioni perché sono definite da Azure ed ereditate dall'istanza gestita.

Ogni account di accesso deve impostare la password al momento dell'accesso e modificarla dopo aver raggiunto la validità massima.

Sì, è possibile controllare i campi CHECK_POLICY e CHECK_EXPIRATION a livello di accesso. È possibile controllare le impostazioni correnti eseguendo il comando T-SQL seguente:

SELECT *
FROM sys.sql_logins

Successivamente, è possibile modificare le impostazioni di accesso specificate eseguendo:

ALTER LOGIN <login_name> WITH CHECK_POLICY = OFF;
ALTER LOGIN <login_name> WITH CHECK_EXPIRATION = OFF;

(sostituire "test" con il nome di accesso desiderato e modificare i criteri e i valori di scadenza.)

Vedere Rotazione dei certificati per il database SQL di Azure e Istanza gestita di SQL.

Vedere Pianificare eventi di manutenzione di Azure in Istanza gestita di SQL.

È possibile votare per una nuova funzionalità di Istanza gestita di SQL o inserire una nuova idea di miglioramento nel forum dei commenti di Istanza gestita di SQL. In questo modo, è possibile contribuire allo sviluppo del prodotto e aiutare a classificare in ordine di priorità i potenziali miglioramenti.

Per informazioni su come creare una richiesta di supporto tecnico di Azure, vedere Creare una richiesta di supporto di Azure.

Le modifiche e le funzionalità introdotte nel ciclo di funzionalità di novembre 2022 sono state integrate nella maggior parte delle istanze e sono ora disponibili per impostazione predefinita. Poiché l'esecuzione di un'azione separata per registrare un'istanza non è più necessaria, le opzioni che indicano l'onda delle funzionalità di novembre 2022 sono state rimosse dal portale di Azure.

Il ciclo delle funzionalità è disponibile per le istanze nelle subnet idonee. Se non vengono visualizzate nuove funzionalità, è probabile che la subnet che contiene l'istanza gestita di SQL non sia idonea perché è ancora nel processo di registrazione. Le istanze nelle subnet non registrate nell'onda continuano a visualizzare la pagina Ciclo di funzionalità nel portale di Azure.

Per le istanze all'interno di un gruppo di failover, la modifica del livello di servizio verso o dal livello Utilizzo generico di nuova generazione non è supportata. È necessario eliminare il gruppo di failover prima di modificare una delle repliche e poi ricreare il gruppo di failover dopo l'applicazione della modifica.

La ridondanza della zona al momento non è supportata per il livello di servizio Utilizzo generico di nuova generazione.

No, l'aggiornamento del livello di servizio per utilizzo generico di nuova generazione non è attualmente supportato per i pool di istanze o le istanze all'interno di un pool.