Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Applica a:
Azure SQL Managed Instance
Questo articolo elenca i problemi attualmente noti relativi a Azure SQL Managed Instance e alla data di risoluzione o alla possibile soluzione alternativa. Per altre informazioni su Azure SQL Managed Instance, vedere Cos'è Azure SQL Managed Instance? e Novità in Azure SQL Managed Instance?
Nota
Microsoft Entra ID era precedentemente noto come Azure Active Directory (Azure AD).
Problemi noti
Ha una soluzione alternativa
Errori durante l'operazione di ripristino dopo la migrazione a Istanza SQL Gestita
Se si esegue la migrazione di un database a Istanza gestita di SQL di Azure da SQL Server 2019 e versioni successive con il ripristino accelerato del database abilitato, ma configurato con l'archivio versioni permanente impostato su un valore diverso dal PRIMARY gruppo di file, è possibile riscontrare errori di operazione di ripristino nell'istanza gestita di SQL di destinazione.
Per risolvere questo problema, assicurarsi di impostare l'archivio versioni permanenti (PVS) su PRIMARY nel database di SQL Server di origine prima di eseguirne la migrazione a Istanza gestita di SQL. Se è già stata eseguita la migrazione del database senza impostare pvS su PRIMARY, è possibile impostarlo nel database di SQL Server di origine e quindi eseguire di nuovo la migrazione del database a Istanza gestita di SQL.
Non è possibile usare il ripristino accelerato del database dopo la migrazione a Istanza gestita di SQL
A partire da SQL Server 2019, se si esegue la migrazione di un database a Istanza gestita di SQL di Azure e il database di origine ha disabilitato il ripristino accelerato del database , non è possibile usare il ripristino accelerato del database nell'istanza gestita di SQL di destinazione.
Per risolvere questo problema, assicurarsi di abilitare il ripristino accelerato del database nel database di SQL Server di origine prima di eseguirne la migrazione a Istanza gestita di SQL. Se è già stata eseguita la migrazione del database senza abilitare il ripristino accelerato del database, è possibile abilitarlo nel database SQL Server di origine e quindi eseguire di nuovo la migrazione del database all'istanza gestita di SQL.
SQL Server 2017 e versioni precedenti non supportano il ripristino accelerato del database, quindi questo problema non si applica ai database migrati da tali versioni di SQL Server.
Impossibile usare Service Broker dopo la migrazione a Istanza gestita di SQL
Se si esegue la migrazione di un database a Istanza gestita di SQL di Azure e Service Broker è disabilitato nel database di origine, non è possibile usare Service Broker nell'istanza gestita di SQL di destinazione.
Per risolvere questo problema, assicurarsi di abilitare Service Broker nel database di SQL Server di origine prima di eseguirne la migrazione a Istanza gestita di SQL. Se è già stata eseguita la migrazione del database senza abilitare Service Broker, è possibile abilitarlo nel database SQL Server di origine e quindi eseguire di nuovo la migrazione del database a Istanza gestita di SQL.
Modifica del periodo di conservazione dei backup per l'offerta gratuita
È possibile modificare solo i criteri di conservazione dei backup dei database nell'istanza gestita di SQL gratuita usando APIREST, PowerShell e Azure CLI. Non è possibile modificare i criteri di conservazione dei backup tramite il portale Azure.
Accesso al database secondario di lettura non riuscito a causa di un'attesa prolungata su "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING"
Questo errore potrebbe essere visualizzato come eccezione per il driver Microsoft OLE DB Driver 19 per SQL Server quando si tenta di connettersi a una replica secondaria di sola lettura di un gruppo failover o un database replicato tramite il collegamento Managed Instance.
Questo errore si verifica quando la replica secondaria non è disponibile per gli accessi perché mancano versioni di riga per le transazioni in corso di elaborazione quando una replica secondaria è stata riavviata o riciclata, sia per manutenzione che per failover. Quando un'istanza riavvia o esegue il failover, i dati di controllo delle versioni archiviati in tempdb vengono cancellati. Le query di lettura secondarie vengono interrotte se sono presenti transazioni attive con esecuzione prolungata avviate prima del failover o del riavvio.
Per risolvere questo problema, eseguire il rollback o il commit di transazioni attive nella replica primaria. Per evitare questo errore, ridurre al minimo le transazioni di scrittura con esecuzione prolungata nella replica primaria.
Errore 8992 durante l'esecuzione di DBCC CHECKDB in un database SQL Server originato da SQL Managed Instance
Quando si esegue il comando DBCC CHECKDB in un database SQL Server 2022, è possibile che venga visualizzato l'errore seguente dopo l'eliminazione di un indice o di una tabella con un indice e il database ha origine da Azure SQL Managed Instance, ad esempio dopo il ripristino di un file di backup o dalla funzionalità di collegamento SQL Managed Instance:
Msg 8992, Level 16, State 1, Line <Line_Number>
Check Catalog Msg 3853, State 1: Attribute (%ls) of row (%ls) in sys.sysrowsetrefs does not have a matching row (%ls) in sys.indexes.
Per risolvere il problema, eliminare prima di tutto l'indice o la tabella con l'indice, dal database di origine in Azure SQL Managed Instance, quindi ripristinare o collegare il database a SQL Server 2022 di nuovo. Se la ricreazione del database dal Azure SQL Managed Instance di origine non è possibile, contattare il supporto tecnico Microsoft per risolvere il problema.
Attenzione
Se si crea un indice partizionato in una tabella dopo l'eliminazione di un indice come descritto in questo scenario, la tabella diventa inaccessibile.
Elenco di backup a lungo termine nel portale di Azure mostra i file di backup per i database attivi ed eliminati con lo stesso nome
I backup a lungo termine possono essere elencati e gestiti nella pagina del portale di Azure per un Azure SQL Managed Instance nella scheda Backups. Nella pagina sono elencati i database attivi o eliminati, le informazioni di base sui backup a lungo termine e il collegamento per la gestione dei backup. Quando si seleziona il collegamento Gestisci, viene visualizzato un nuovo riquadro laterale con l'elenco dei backup. A causa di un problema con la logica di filtro, l'elenco mostra i backup per il database attivo e i database eliminati con lo stesso nome. Ciò richiede particolare attenzione quando si selezionano i backup per l'eliminazione, per evitare di eliminare i backup per un database errato.
Soluzione alternativa: usare le informazioni di Ora di backup (UTC) nell'elenco per distinguere i backup appartenenti ai database con lo stesso nome presenti nell'istanza in periodi diversi. In alternativa, utilizzare i comandi PowerShell Get-AzSqlInstanceDatabaseLongTermRetentionBackup e Remove-AzSqlInstanceDatabaseLongTermRetentionBackup, oppure i comandi CLI az sql midb ltr-backup list e az sql midb ltr-backup delete per gestire i backup a lungo termine, usando il parametro DatabaseState e il valore di ritorno DatabaseDeletionTime per filtrare i backup di un database.
La sp_send_dbmail di routine potrebbe non riuscire quando si usa @query parametro
La sp_send_dbmail stored procedure potrebbe non riuscire quando viene usato il @query parametro . Gli errori si verificano quando la stored procedure viene eseguita in un account sysadmin .
Questo problema è causato da un bug noto correlato al modo in cui sp_send_dbmail utilizza l'impersonificazione.
Soluzione alternativa: assicurarsi di chiamare sp_send_dbmail con un account personalizzato appropriato creato e non in un account sysadmin .
Ecco un esempio di come creare un account dedicato e modificare gli oggetti esistenti che inviano messaggi di posta elettronica tramite sp_send_dbmail.
USE [msdb];
GO
-- Step 1: Create a user mapped to a login to specify as a runtime user.
CREATE USER [user_name] FOR LOGIN [login_name];
GO
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = N'db_mail_sending_job',
@step_id = db_mail_sending_job_id,
@database_user_name = N'user_name';
GO
-- Step 2: Grant DB Mail permissions to the user who created it.
ALTER ROLE [DatabaseMailUserRole] ADD MEMBER [user_name];
GO
-- Step 3: If the database of the job step is not msdb, the permission error cannot be avoided even if it is a member of the role, so set it to msdb.
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = N'db_mail_sending_job',
@step_id = db_mail_sending_job_id,
@database_name = N'msdb';
GO
-- Step 4: Set a principal in the email profile
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@principal_name = N'user_name',
@profile_name = N'profile_name',
@is_default = 0;
GO
Le transazioni distribuite possono essere eseguite dopo la rimozione dell'istanza gestita di SQL dal gruppo di attendibilità del server
I gruppi di trust del server vengono usati per stabilire un trust tra istanze gestite che sono prerequisiti per l'esecuzione di transazioni distribuite. Dopo aver rimosso l'istanza gestita di SQL dal gruppo di attendibilità del server o eliminato il gruppo, potrebbe essere comunque possibile eseguire transazioni distribuite. Per assicurarsi che le transazioni distribuite siano disabilitate, eseguire un failover manuale avviato dall'utente nell'istanza gestita di SQL.
Impossibile creare SQL Managed Instance con lo stesso nome del server logico eliminato in precedenza
Quando si crea un server logical in Azure per Azure SQL Database o una SQL Managed Instance, il sistema crea un record DNS per <name>.database.windows.com. Questo record DNS deve essere univoco. Se si crea un server logico per il database SQL e quindi lo si elimina, il nome rimane riservato per sette giorni. Durante questo periodo non è possibile creare un SQL Managed Instance con lo stesso nome del server logico eliminato. Come soluzione alternativa, usare un nome diverso per il SQL Managed Instance o creare un ticket di supporto per rilasciare il nome del server logico.
Il Principal del servizio non può accedere a Microsoft Entra ID e Azure Key Vault.
In alcune circostanze, esiste un problema con il principale del servizio utilizzato per accedere a Microsoft Entra ID (precedentemente conosciuta come Azure Active Directory) e ai servizi di Azure Key Vault (AKV). Di conseguenza, questo problema influisce sull'utilizzo dell'autenticazione Microsoft Entra e di Transparent Data Encryption (TDE) con SQL Managed Instance. Questo problema può verificarsi come problema di connettività intermittente o non è in grado di eseguire istruzioni come CREATE LOGIN/USER FROM EXTERNAL PROVIDER o EXECUTE AS LOGIN/USER. La configurazione di TDE con chiave gestita dal cliente in un nuovo Azure SQL Managed Instance potrebbe non funzionare in alcune circostanze.
Workaround: per evitare che questo problema si verifichi nel SQL Managed Instance, prima di eseguire qualsiasi comando di aggiornamento o nel caso in cui si sia già verificato questo problema dopo i comandi di aggiornamento, passare alla pagina Panoramica del SQL managed instance nel portale di Azure. In Impostazioni selezionare Microsoft Entra ID per accedere alla pagina di amministrazione SQL Managed Instance Microsoft Entra ID admin. Individuare il messaggio di errore seguente:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Se viene visualizzato questo messaggio di errore, selezionarlo e seguire le istruzioni dettagliate fornite fino a quando questo errore non viene risolto.
Errore sbagliato restituito durante il tentativo di rimozione di un file non vuoto
SQL Server e SQL Managed Instance non consentono a un utente di eliminare un file non vuoto. Se si tenta di rimuovere un file di dati non vuoto usando un'istruzione ALTER DATABASE REMOVE FILE , l'errore:
Msg 5042 - The file '<file_name>' cannot be removed because it is not empty` isn't immediately returned. SQL Managed Instance keeps trying to drop the file, and the operation fails after 30 minutes with `Internal server error.
Le operazioni che consentono di modificare il livello di servizio e creare istanze sono bloccate dal ripristino di database in corso
Un'istruzione in corso RESTORE , un processo di migrazione del Servizio Migrazione dati e il ripristino temporizzato predefinito possono bloccare gli aggiornamenti a un livello di servizio o ridimensionare l'istanza esistente e creare nuove istanze fino al termine del processo di ripristino.
Il processo di ripristino bloccherà queste operazioni sulle istanze gestite e sui pool di istanze nella stessa subnet in cui è in esecuzione il processo di ripristino. Le istanze nei gruppi di istanze non sono interessate. La creazione o la modifica delle operazioni del livello di servizio non falliscono né vanno in timeout. Procedono una volta che il processo di ripristino è completato o annullato.
Soluzione alternativa: attendere il completamento del processo di ripristino o annullare il processo di ripristino se la creazione o l'aggiornamento del livello di servizio ha una priorità più elevata.
Resource Governor su una replica secondaria leggibile necessita di riconfigurazione dopo il failover
La funzionalità Resource Governor che consente di limitare le risorse assegnate al carico di lavoro utente potrebbe classificare erroneamente alcuni carichi di lavoro utente dopo il failover o una modifica avviata dall'utente del livello di servizio( ad esempio, la modifica delle dimensioni massime di archiviazione vCore o max instance).
Soluzione alternativa: eseguire ALTER RESOURCE GOVERNOR RECONFIGURE periodicamente o come parte di un processo di SQL Agent che esegue l'attività SQL quando viene avviata la replica secondaria leggibile se si usa Resource Governor.
Superamento dello spazio di archiviazione con file di database di piccole dimensioni
CREATE DATABASE, ALTER DATABASE ADD FILE e RESTORE DATABASE istruzioni potrebbero fallire perché l'istanza raggiunge il limite di Azure Storage per il livello di servizio di uso generico, ma non il livello di servizio upgrade di nuova generazione per uso generico o il livello di servizio Business Critical.
Ogni istanza per utilizzo generico di SQL Managed Instance ha fino a 35 TB di spazio di archiviazione riservato per Azure spazio su disco Premium. Ogni file di database si trova in un disco fisico separato. I dischi possono essere da 128 GB, 256 GB, 512 GB, 1 TB o 4 TB. Non viene addebitato alcun costo per lo spazio inutilizzato sul disco, ma la somma totale di Azure dimensioni del disco Premium non può superare i 35 TB. In alcuni casi, un'istanza gestita di SQL che non richiede 8 TB in totale potrebbe superare il limite di 35 TB Azure per le dimensioni di archiviazione a causa della frammentazione interna.
Ad esempio, un'istanza per utilizzo generico di SQL Managed Instance potrebbe avere un file di grandi dimensioni di 1,2 TB posizionato su un disco da 4 TB. Potrebbero inoltre essere presenti 248 file da 1 GB ognuno, divisi in dischi da 128 GB separati. In questo esempio:
- la dimensione totale della risorsa di archiviazione sul disco allocato è 1 x 4 TB + 248 x 128 GB = 35 TB.
- Lo spazio totale riservato per i database nell'istanza è 1 x 1,2 TB + 248 x 1 GB = 1,4 TB.
Questo esempio illustra che in determinate circostanze, a causa di una distribuzione specifica di file, un'istanza di SQL Managed Instance potrebbe raggiungere il limite di 35 TB riservato per un Azure Disco Premium collegato, quando potrebbe non essere previsto.
In questo esempio, i database esistenti continuano a funzionare e possono crescere senza alcun problema fino a quando non vengono aggiunti nuovi file. Non è possibile creare o ripristinare nuovi database perché non è disponibile spazio sufficiente per le nuove unità disco, anche se le dimensioni totali di tutti i database non raggiungono il limite di dimensioni dell'istanza. L'errore restituito non è chiaro.
È possibile identificare il numero di file rimanenti usando le viste di sistema. Se si raggiunge questo limite, provare a svuotare ed eliminare alcuni dei file più piccoli usando l'istruzione DBCC SHRINKFILE o passare al livello di servizio business critical, che non ha questo limite.
Valori GUID visualizzati al posto dei nomi di database
In numerose viste di sistema, contatori delle prestazioni, messaggi di errore, XEvent e voci del log degli errori sono visualizzati gli identificatori GUID dei database anziché i nomi effettivi. Non fare affidamento su questi identificatori GUID, in quanto potrebbero essere sostituiti dai nomi effettivi dei database in futuro.
Soluzione alternativa: usare la vista sys.databases per risolvere il nome del database effettivo dal nome del database fisico, indicato nel modulo degli identificatori del database GUID:
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
I moduli CLR e i server collegati a volte non riescono a fare riferimento all'indirizzo IP locale
I moduli CLR in SQL Managed Instance e server collegati o query distribuite che fanno riferimento a un'istanza corrente a volte non possono risolvere l'INDIRIZZO IP di un'istanza locale. Questo errore è un problema temporaneo.
Nessuna risoluzione
Messaggio di errore fuorviante durante la connessione a una replica in lettura con credenziali non valide
Quando si tenta di connettersi a una replica secondaria di lettura di un'istanza del livello Business Critical utilizzando ApplicationIntent=ReadOnly e credenziali non valide, l'istanza segnala un errore che indica che il database master è di sola lettura. L'istanza non segnala correttamente che le credenziali non sono valide.
I backup differenziali non vengono eseguiti quando un'istanza è collegata a SQL Server
Quando si configura un link tra SQL Server e Azure SQL Managed Instance, vengono eseguiti backup completi e del log delle transazioni automatizzati nell'istanza gestita di SQL, indipendentemente dal fatto che si tratti o meno del ruolo primario. Tuttavia, i backup differenziali non vengono attualmente eseguiti, quando possono portare a tempi di ripristino più lunghi del previsto.
Aumento del numero di accessi di sistema utilizzati per la replica transazionale
Il servizio Azure SQL Managed Instance crea un account di accesso di sistema per la replica transazionale. È possibile trovare questo account di accesso in SSMS (in Object Explorer>Security>Logins) o nella visualizzazione di sistema sys.syslogins. Il formato del nome di accesso è simile a DBxCy\WF-abcde01234QWERT e l'account di accesso ha il ruolo server pubblico. In determinate condizioni, questo account di accesso viene ricreato e a causa di un problema interno l'account di accesso precedente non viene eliminato. Questo problema può causare un aumento del numero di accessi. Questi account di accesso non rappresentano una minaccia per la sicurezza ed è possibile ignorarli in modo sicuro. Non eliminare questi account di accesso, perché almeno uno di essi viene usato per la replica transazionale.
Microsoft Entra account di accesso e utenti non sono supportati in SSDT
SQL Server Data Tools non supportano completamente gli account di accesso e gli utenti Microsoft Entra.
Il mascheramento dei tipi di accesso Microsoft Entra non è supportato
La rappresentazione con EXECUTE AS USER o EXECUTE AS LOGIN non è supportata per le entità di Microsoft Entra seguenti:
- Utenti aliasati di Microsoft Entra. In questo caso, l'operazione restituisce l'errore
15517. - Microsoft Entra account di accesso e utenti basati su Microsoft Entra applicazioni o entità servizio. In questo caso, l'operazione restituisce errori
15517e15406.
È necessario riconfigurare la replica transazionale dopo il failover geografico
Se si abilita la replica transazionale in un database in un gruppo di failover, l'amministratore SQL Managed Instance deve pulire tutte le pubblicazioni nel database primario precedente e riconfigurarle nel nuovo database primario dopo che si verifica un failover in un'altra area. Per altre informazioni, vedere Replica.
I log degli errori non sono permanenti
I log degli errori disponibili in SQL Managed Instance non sono persistenti e le relative dimensioni non sono incluse nel limite massimo di archiviazione. I log degli errori potrebbero essere cancellati automaticamente se si esegue il failover. Potrebbero esistere lacune nella cronologia dei log degli errori perché SQL Managed Instance è stato spostato più volte in più macchine virtuali.
Risolto
Indicazioni provvisorie sugli aggiornamenti del fuso orario 2024 per il Paraguay
(Risolto nel mese di febbraio 2026)
Il 14 ottobre 2024, il governo paraguaiano ha annunciato una modifica permanente alla politica del fuso orario. Il Paraguay rimane ora all'ora legale (DST) tutto l'anno, adottando in modo efficace UTC-3 come ora solare. Di conseguenza, gli orologi non avanzavano di 60 minuti alle 12:00 il 23 marzo 2025, come previsto in precedenza. Questa modifica influisce sul fuso orario standard del Paraguay. Microsoft ha rilasciato aggiornamenti correlati Windows a febbraio e marzo 2025. Le istanze gestite di SQL che usano il fuso orario interessato riflettono questa modifica e si allineano al nuovo offset UTC-3.
La modifica del tipo di connessione non influisce sulle connessioni tramite l'endpoint del gruppo di failover
(Risolto nel novembre 2025)
Se un'istanza partecipa a un gruppo di failover, la modifica del tipo di connessione dell'istanza non ha effetto per le connessioni stabilite tramite l'endpoint del listener del gruppo di failover.
Inaccessibilità temporanea dell'istanza tramite il listener del gruppo di failover durante l'operazione di ridimensionamento
(Risolto nell'aprile 2025)
Il ridimensionamento dell'istanza gestita di SQL a volte richiede lo spostamento dell'istanza in un cluster virtuale diverso, insieme ai record DNS gestiti dal servizio associati. Se l'istanza SQL gestita fa parte di un gruppo di failover, il record DNS corrispondente al listener del gruppo di failover associato (listener di lettura-scrittura, se l'istanza è il geo-primario corrente; listener di sola lettura, se l'istanza è il geo-secondario corrente) viene spostato nel nuovo cluster virtuale.
Nella progettazione dell'operazione di ridimensionamento corrente, i record DNS del listener vengono rimossi dal cluster virtuale di origine prima di eseguire completamente la migrazione dell'istanza gestita di SQL al nuovo cluster virtuale. In alcune situazioni, questa progettazione comporta tempi prolungati durante i quali l'indirizzo IP dell'istanza non può essere risolto usando il listener. Durante questo periodo, un client SQL che tenta di accedere all'istanza ridimensionata usando l'endpoint del listener può prevedere errori di accesso con il messaggio di errore seguente:
Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).
Il problema verrà risolto tramite la riprogettazione dell'operazione di ridimensionamento.
La tabella per i backup manuali nel msdb non mantiene il nome utente.
(Risolto nell'agosto 2023) Il supporto introdotto di recente per i backup automatici in msdb non contiene attualmente informazioni sul nome utente.
Quando si usa l'autenticazione di SQL Server, i nomi utente con '@' non sono supportati
I nomi utente che contengono il simbolo @ al centro (ad esempio, abc@xy) non possono accedere usando l'autenticazione SQL Server.
Il ripristino del backup manuale senza CHECKSUM potrebbe avere esito negativo
(Risolto nel giugno 2020) In determinate circostanze, il ripristino del backup manuale dei database eseguiti in un'istanza gestita di SQL senza CHECKSUM potrebbe non riuscire. In tali casi, riprova a ripristinare il backup finché non riesci.
Soluzione alternativa: eseguire backup manuali dei database in istanze gestite di SQL con CHECKSUM abilitato.
Autorizzazioni per il gruppo di risorse non applicate a SQL Managed Instance
Quando si applica il ruolo collaboratore SQL Managed Instance Azure a un gruppo di risorse (RG), non si applica a SQL Managed Instance e non ha alcun effetto.
Workaround: Impostare un ruolo di tipo "Contributor" per SQL Managed Instance per gli utenti a livello della sottoscrizione.
Un messaggio di errore fuorviante nel portale di Azure che suggerisce di ricreare il principale del servizio
La pagina Active Directory admin del portale di Azure per Azure SQL Managed Instance potrebbe mostrare il messaggio di errore seguente, anche se l'entità servizio esiste già:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
È possibile ignorare questo messaggio di errore se l'entità servizio per l'istanza gestita di SQL esiste già e/o l'autenticazione di Microsoft Entra sull'istanza gestita di SQL funziona.
Per verificare se l'entità servizio esiste, accedi alla pagina Applicazioni aziendali nel portale di Azure, seleziona "Identità gestite" dal menu a discesa "Tipo di applicazione", fai clic su Applica e digita il nome dell'istanza gestita di SQL nella casella di ricerca. Se il nome dell'istanza viene visualizzato nell'elenco dei risultati, il principale del servizio esiste già e non sono necessarie ulteriori azioni.
Se sono già state seguite le istruzioni del messaggio di errore e il collegamento è stato selezionato, l'entità servizio dell'istanza gestita di SQL viene ricreata. In tal caso, assegnare le autorizzazioni di lettura di Microsoft Entra ID al Principale del Servizio appena creato affinché l'autenticazione Microsoft Entra funzioni correttamente. È anche possibile eseguire questo passaggio con Azure PowerShell seguendo le instructions.
La destinazione event_file della sessione eventi di system_health non è accessibile
(Parzialmente risolto nel maggio 2025) Quando si tenta di leggere il contenuto della destinazione della event_file sessione dell'evento system_health , viene visualizzato l'errore 40538, "Un URL valido che inizia con https:// è obbligatorio come valore per qualsiasi percorso file specificato".
In origine, questo problema si è verificato in SQL Server Management Studio (SSMS) o durante la lettura dei dati della sessione usando la funzione sys.fn_xe_file_target_read_file.
Nel maggio 2025, questo problema è stato risolto per la lettura dei dati della sessione da SSMS. Il problema non viene risolto durante la lettura dei dati degli eventi tramite la sys.fn_xe_file_target_read_file funzione .
Questa modifica del comportamento è una conseguenza imprevista di una correzione di sicurezza richiesta. È possibile risolvere questo problema creando un proprio equivalente della sessione system_health con una destinazione /event_file in Azure Blob Storage. Per altre informazioni, incluso uno script T-SQL per creare la sessione system_health che può essere modificata per creare un equivalente personalizzato di system_health, vedere Usare la sessione di system_health.
Le finestre di dialogo di Service Broker tra database richiedono la reinizializzazione dopo l'aggiornamento del livello di servizio
(Risolto nel gennaio 2020) Le finestre di dialogo di Service Broker tra database non recapitano i messaggi ai servizi in altri database dopo l'operazione di modifica del livello di servizio. I messaggi non vengono persi e si trovano nella coda del mittente. Qualsiasi modifica dei vCore o delle dimensioni dell'archiviazione dell'istanza in SQL Managed Instance provoca un cambiamento del valore nella visualizzazione service_broke_guid per tutti i database. Qualsiasi DIALOG elemento creato usando un'istruzione BEGIN DIALOG che fa riferimento a Service Broker in altri database interrompe il recapito dei messaggi al servizio di destinazione.
Soluzione alternativa: arrestare tutte le attività che usano conversazioni di dialogo Service Broker tra database prima di aggiornare il livello di servizio e reinizializzarle dopo. Se i messaggi non recapitati rimangono dopo una modifica del livello di servizio, leggere i messaggi dalla coda di origine e inviarli nuovamente alla coda di destinazione.
Contribuire al contenuto
Per contribuire alla documentazione Azure SQL, vedere la guida per i collaboratori Docs.
Contenuto correlato
Per un elenco degli aggiornamenti e dei miglioramenti di SQL Managed Instance, vedere SQL Managed Instance aggiornamenti del servizio.
Per aggiornamenti e miglioramenti a tutti i servizi di Azure, vedere aggiornamenti Servizi.