Problemi noti con Istanza gestita di SQL di Azure

Si applica a:Istanza gestita di SQL di Azure

Questo articolo elenca i problemi attualmente noti relativi a Istanza gestita di SQL di Azure e la data di risoluzione o la possibile soluzione alternativa. Per altre informazioni sulle Istanza gestita di SQL di Azure, vedere la panoramica e le novità.

Nota

Microsoft Entra ID è il nuovo nome per Azure Active Directory (Azure AD).Microsoft Entra ID is the new name for Azure Active Directory (Azure AD). La documentazione viene aggiornata in questo momento.

Problemi noti

Problema Data individuata Status Data risolta
Inaccessibilità dell'istanza temporanea tramite il listener del gruppo di failover durante l'operazione di ridimensionamento Genn. 2024 Nessuna risoluzione
La destinazione event_file della sessione eventi di system_health non è accessibile Dic. 2023 Ha una soluzione alternativa
Procedure sp_send_dbmail may fail when @query parameter is used on Nov22FW enabled managed instances Dic. 2023 Ha una soluzione alternativa
Aumento del numero di account di accesso di sistema usati per la replica transazionale Dicembre 2022 Nessuna risoluzione
La tabella msdb per i backup manuali non mantiene il nome utente Novembre 2022 Nessuna risoluzione
Indicazioni provvisorie sugli aggiornamenti del fuso orario 2022 per il Cile Agosto 2022 Ha una soluzione alternativa
L'esecuzione di query sulla tabella esterna ha esito negativo e viene visualizzato il messaggio di errore 'non supportato' Gennaio 2022 Risolto Settembre 2022
Quando si usa l'autenticazione di SQL Server, i nomi utente con '@' non sono supportati Ottobre 2021 Risolto Febbraio 2022
Messaggio di errore fuorviante in portale di Azure suggerisce la ricreazione dell'entità servizio Settembre 2021 Ottobre 2021
La modifica del tipo di connessione non influisce sulle connessioni tramite l'endpoint del gruppo di failover Gen 2021 Ha una soluzione alternativa
Procedure sp_send_dbmail may transiently fail when @query parameter is used Gen 2021 Risolto Marzo 2022
Le transazioni distribuite possono essere eseguite dopo la rimozione di un'istanza gestita dal gruppo di attendibilità del server Ott 2020 Ha una soluzione alternativa
Le transazioni distribuite non possono essere eseguite dopo l'operazione di ridimensionamento dell'istanza gestita Ott 2020 Risolto 2021° maggio
Impossibile creare Istanza gestita di SQL con lo stesso nome del server logico eliminato in precedenza Ago 2020 Ha una soluzione alternativa
L'entità servizio non può accedere all'ID Microsoft Entra [in precedenza Azure Active Directory]e AKV
Ago 2020 Ha una soluzione alternativa
Il ripristino del backup manuale senza CHECKSUM potrebbe avere esito negativo Maggio 2020 Risolto Giugno 2020
L'agente non risponde durante la modifica, la disabilitazione o l'abilitazione di processi esistenti Maggio 2020 Risolto Giugno 2020
Autorizzazioni per il gruppo di risorse non applicate a Istanza gestita di SQL Febbraio 2020 Risolto Nov 2020
Limitazione del failover manuale tramite il portale per i gruppi di failover Gennaio 2020 Ha una soluzione alternativa
I ruoli di SQL Agent richiedono autorizzazioni EXECUTE esplicite per gli account di accesso nonsysadmin Dicembre 2019 Risolto Settembre 2022
I processi di SQL Agent possono essere interrotti dal riavvio del processo dell'agente Dicembre 2019 Risolto Marzo 2020
Gli account di accesso e gli utenti di Microsoft Entra non sono supportati in SSDT Novembre 2019 Nessuna soluzione alternativa
I limiti di memoria OLTP in memoria non vengono applicati Ottobre 2019 Ha una soluzione alternativa
Errore errato restituito durante il tentativo di rimuovere un file non vuoto Ottobre 2019 Risolto Agosto 2020
Le operazioni che consentono di modificare il livello di servizio e creare istanze sono bloccate dal ripristino di database in corso Settembre 2019 Ha una soluzione alternativa
Potrebbe essere necessario riconfigurare Resource Governor sul livello di servizio business critical dopo il failover Settembre 2019 Ha una soluzione alternativa
Le finestre di dialogo di Service Broker tra database devono essere reinizializzate dopo l'aggiornamento del livello di servizio Agosto 2019 Ha una soluzione alternativa
La rappresentazione dei tipi di accesso di Microsoft Entra non è supportata Luglio 2019 Nessuna soluzione alternativa
parametro @query non supportato in sp_send_db_mail April 2019 Risolto Gen 2021
La replica transazionale deve essere riconfigurata dopo il failover geografico Marzo 2019 Nessuna soluzione alternativa
La struttura e il contenuto di tempdb sono stati ricreati Nessuna soluzione alternativa
Superamento dello spazio di archiviazione con file di database di piccole dimensioni Ha una soluzione alternativa
Valori GUID visualizzati al posto dei nomi di database Ha una soluzione alternativa
I log degli errori non sono permanenti Nessuna soluzione alternativa
L'ambito della transazione in due database nella stessa istanza non è supportato Ha una soluzione alternativa Marzo 2020
I moduli CLR e i server collegati a volte non riescono a fare riferimento all'indirizzo IP locale Ha una soluzione alternativa
Coerenza del database non verificata usando DBCC CHECKDB dopo il ripristino del database dall'Archiviazione BLOB di Azure. Risolto Novembre 2019
Il ripristino temporizzato di database dal livello business critical al livello utilizzo generico non avrà esito positivo se il database di origine contiene oggetti OLTP in memoria. Risolto Ottobre 2019
Funzionalità Posta elettronica database con server di posta elettronica esterni (non Azure) che usano una connessione sicura Risolto Ottobre 2019
Database indipendenti non supportati in Istanza gestita di SQL Risolto Agosto 2019

Soluzione alternativa

La destinazione event_file della sessione eventi di system_health non è accessibile

Quando si tenta di leggere il contenuto della destinazione della event_file sessione eventi system_health , viene visualizzato l'errore 40538, "È necessario un URL valido a partire da 'https://' come valore per qualsiasi percorso file specificato". Ciò si verifica in SQL Server Management Studio o quando si leggono i dati della sessione usando la funzione sys.fn_xe_file_target_read_file .

Questa modifica del comportamento è una conseguenza imprevista di una correzione di sicurezza richiesta recente. Stiamo esaminando la fattibilità di una modifica aggiuntiva che consente ai clienti di continuare a usare la system_health sessione in Istanza gestita in modo sicuro. Nel frattempo, i clienti possono risolvere questo problema creando un proprio equivalente della sessione con una event_file destinazione nell'archiviazione system_health BLOB di Azure. Per altre informazioni, incluso uno script T-SQL per creare la system_health sessione che può essere modificata per creare un equivalente personalizzato di system_health, vedere Usare la sessione di system_health.

La procedura sp_send_dbmail potrebbe non riuscire quando @query il parametro viene usato nelle istanze gestite abilitate per Nov22FW

La procedura sp_send_dbmail potrebbe non riuscire quando @query viene usato il parametro e ciò influisce sulle istanze con ondata di funzionalità di novembre 2022 abilitata. Gli errori si verificano quando la stored procedure viene eseguita nell'account sysadmin.

Questo problema è causato da un bug noto correlato all'uso sp_send_dbmail della rappresentazione.

Soluzione alternativa: assicurarsi di chiamare sp_send_dbmail con l'account personalizzato appropriato creato e non nell'account sysadmin.

Di seguito è riportato 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
EXEC 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.
EXEC 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
EXEC msdb.dbo.sysmail_add_principalprofile_sp @principal_name=N'user_name', @profile_name=N'profile_name', @is_default=0
GO

Indicazioni provvisorie sugli aggiornamenti del fuso orario 2022 per il Cile

L'8 agosto 2022, il governo cileno ha fatto un annuncio ufficiale su una modifica del fuso orario dell'ora legale (DST). A partire dalle 12:00 sabato 10 settembre 2022, fino alle 12:00 di sabato 1 aprile 2023, l'ora ufficiale avanza 60 minuti. La modifica influisce sui tre fusi orari seguenti: Ora solare pacifico SA, Ora solare dell'isola di Pasqua e Ora solare di Magallanes. Istanza gestita di SQL di Azure che usano fusi orari interessati non riflettono le modifiche fino a quando Microsoft non rilascia un aggiornamento del sistema operativo per supportarlo e Istanza gestita di SQL di Azure servizio assorbe l'aggiornamento a livello di sistema operativo.

Soluzione alternativa: se è necessario modificare i fusi orari interessati per le istanze gestite, tenere presenti le limitazioni e seguire le indicazioni della documentazione.

La modifica del tipo di connessione non influisce sulle connessioni tramite l'endpoint del gruppo di failover

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.

Soluzione alternativa: eliminare e ricreare un gruppo di failover dopo la modifica del tipo di connessione.

La procedura sp_send_dbmail può avere esito negativo temporaneo quando @query viene usato il parametro

La procedura sp_send_dbmail può avere esito negativo temporaneamente quando @query viene usato il parametro . Quando si verifica questo problema, ogni seconda esecuzione della routine sp_send_dbmail ha esito negativo con errore Msg 22050, Level 16, State 1 e messaggio Failed to initialize sqlcmd library with error number -2147467259. Per poter visualizzare correttamente questo errore, la procedura deve essere chiamata con il valore predefinito 0 per il parametro @exclude_query_output, in caso contrario l'errore non viene propagato.

Questo problema è causato da un bug noto correlato all'uso sp_send_dbmail della rappresentazione e del pool di connessioni.

Per risolvere questo problema, eseguire il wrapping del codice per l'invio di messaggi di posta elettronica in una logica di ripetizione dei tentativi che si basa sul parametro @mailitem_iddi output . Se l'esecuzione ha esito negativo, il valore del parametro è NULL, a indicare che sp_send_dbmail deve essere chiamato un'altra volta per inviare correttamente un messaggio di posta elettronica. Ecco un esempio di questa logica di ripetizione dei tentativi.

CREATE PROCEDURE send_dbmail_with_retry AS
BEGIN
    DECLARE @miid INT
    EXEC msdb.dbo.sp_send_dbmail
        @recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
        @profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
        @mailitem_id = @miid OUTPUT

    -- If sp_send_dbmail returned NULL @mailidem_id then retry sending email.
    --
    IF (@miid is NULL)
    EXEC msdb.dbo.sp_send_dbmail
        @recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
        @profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
END

Le transazioni distribuite possono essere eseguite dopo la rimozione di un'istanza gestita dal gruppo di attendibilità del server

I gruppi di attendibilità 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 da Server Trust Group o eliminato il gruppo, potrebbe comunque essere possibile eseguire transazioni distribuite. Esiste una soluzione alternativa che è possibile applicare per assicurarsi che le transazioni distribuite siano disabilitate e che sia il failover manuale avviato dall'utente nell'istanza gestita.

Le transazioni distribuite non possono essere eseguite dopo l'operazione di ridimensionamento dell'istanza gestita

Istanza gestita di SQL operazioni di ridimensionamento che includono la modifica del livello di servizio o il numero di vCore reimposta le impostazioni del gruppo di attendibilità del server nel back-end e disabilita l'esecuzione di transazioni distribuite. Come soluzione alternativa, eliminare e creare un nuovo gruppo di attendibilità del server in portale di Azure.

Impossibile creare Istanza gestita di SQL con lo stesso nome del server logico eliminato in precedenza

Un record DNS di <name>.database.windows.com viene creato quando si crea un server logico in Azure per database SQL di Azure e quando si crea un Istanza gestita di SQL. Il record DNS deve essere univoco. Di conseguenza, se si crea un server logico per database SQL e quindi lo si elimina, è previsto un periodo di soglia di sette giorni prima del rilascio del nome dai record. In quel periodo non è possibile creare un Istanza gestita di SQL con lo stesso nome del server logico eliminato. Come soluzione alternativa, usare un nome diverso per il Istanza gestita di SQL o creare un ticket di supporto per rilasciare il nome del server logico.

L'entità servizio non può accedere a Microsoft Entra ID e AKV

In alcuni casi, potrebbe verificarsi un problema con l'entità servizio usata per accedere ai servizi Microsoft Entra ID (in precedenza Azure Active Directory) e Azure Key Vault (AKV). Di conseguenza, questo problema influisce sull'utilizzo dell'autenticazione di Microsoft Entra e di Transparent Data Encryption (TDE) con Istanza gestita di SQL. Ciò potrebbe verificarsi come un problema di connettività intermittente o non essere 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 Istanza gestita di SQL di Azure potrebbe non funzionare in alcune circostanze.

Soluzione alternativa: per evitare che questo problema si verifichi nel Istanza gestita di SQL prima di eseguire qualsiasi comando di aggiornamento o nel caso in cui si sia già verificato questo problema dopo i comandi di aggiornamento, passare a portale di Azure, accedere Istanza gestita di SQL pagina di amministrazione di Active Directory. Verificare se è possibile visualizzare il messaggio di errore "Istanza gestita richiede un'entità servizio per accedere all'ID Microsoft Entra. Fare clic qui per creare un'entità servizio". Nel caso in cui sia stato rilevato questo messaggio di errore, selezionarlo e seguire le istruzioni dettagliate fornite fino a quando questo errore non è stato risolto.

Limitazione del failover manuale tramite il portale per i gruppi di failover

Se un gruppo di failover si estende su istanze in sottoscrizioni o gruppi di risorse di Azure diversi, il failover manuale non può essere avviato dall'istanza primaria nel gruppo di failover.

Soluzione alternativa: avviare il failover tramite il portale dall'istanza geografica secondaria.

Per i ruoli SQL Agent sono necessarie autorizzazioni EXECUTE esplicite per gli accessi diversi da sysadmin

Se gli account di accesso non sysadmin vengono aggiunti a ruoli predefiniti del database di SQL Agent, esiste un problema in cui è necessario concedere autorizzazioni EXECUTE esplicite a tre stored procedure nel master database per il corretto funzionamento di questi account di accesso. Se si verifica questo problema, viene visualizzato il messaggio The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) di errore.

Soluzione alternativa: dopo aver aggiunto gli account di accesso a un ruolo predefinito del database di SQL Agent (SQLAgentUserRole, SQLAgentReaderRole o SQLAgentOperatorRole), per ognuno degli account di accesso aggiunti a questi ruoli, eseguire lo script T-SQL seguente per concedere in modo esplicito le autorizzazioni EXECUTE alle stored procedure elencate.

USE [master];
GO

CREATE USER [login_name] FOR LOGIN [login_name];
GO

GRANT EXECUTE ON master.dbo.xp_sqlagent_enum_jobs TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_is_starting TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_notify TO [login_name];

I limiti di memoria OLTP in memoria non vengono applicati

Il livello di servizio Business Critical non applica correttamente limiti di memoria massimi per gli oggetti ottimizzati per la memoria in alcuni casi. Istanza gestita di SQL può consentire al carico di lavoro di usare più memoria per le operazioni OLTP in memoria, che possono influire sulla disponibilità e sulla stabilità dell'istanza. Le query di OLTP in memoria che raggiungono i limiti potrebbero non avere subito esito negativo. Le query che usano più memoria OLTP in memoria hanno esito negativo prima se raggiungono i limiti.

Soluzione alternativa: monitorare l'utilizzo dell'archiviazione OLTP in memoria usando SQL Server Management Studio per assicurarsi che il carico di lavoro non usi più della memoria disponibile. Aumentare i limiti di memoria che dipendono dal numero di vCore oppure ottimizzare il carico di lavoro per usare meno memoria.

Errore errato restituito durante il tentativo di rimuovere un file non vuoto

SQL Server e Istanza gestita di SQL 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 non viene restituito immediatamente. Istanza gestita di SQL continuerà a provare a eliminare il file e l'operazione avrà esito negativo dopo 30 minuti con 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 blocca l'aggiornamento di un livello di servizio o il ridimensionamento dell'istanza esistente e la creazione di nuove istanze fino al termine del processo di ripristino.

Il processo di ripristino blocca queste operazioni sulle istanze gestite e sui pool di istanze nella stessa subnet in cui è in esecuzione il processo di ripristino. Le istanze nei pool di istanze non sono interessate. Le operazioni di creazione o modifica del livello di servizio non hanno esito negativo o si verifica il timeout. Si procede dopo il completamento o l'annullamento del processo di ripristino.

Soluzione alternativa: attendere il completamento del processo di ripristino o annullare il processo di ripristino se l'operazione di creazione o di livello di servizio di aggiornamento ha una priorità più alta.

Potrebbe essere necessario riconfigurare Resource Governor sul livello di servizio business critical dopo il failover

La funzionalità di 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 all'avvio dell'istanza se si usa Resource Governor.

Le finestre di dialogo di Service Broker tra database devono essere reinizializzate dopo l'aggiornamento del livello di servizio

Le finestre di dialogo Service Broker tra database interromperanno l'invio di messaggi ai servizi di altri database dopo l'operazione di modifica del livello di servizio. I messaggi non vengono persi e sono disponibili nella coda del mittente. Qualsiasi modifica delle dimensioni di archiviazione di istanze o vCore in Istanza gestita di SQL determina la modifica di un service_broke_guid valore nella vista sys.databases per tutti i database. Qualsiasi DIALOG elemento creato usando un'istruzione BEGIN DIALOG che fa riferimento a Service Broker in altri database smette di recapitare messaggi al servizio di destinazione.

Soluzione alternativa: arrestare tutte le attività che usano conversazioni tra database di Service Broker prima di aggiornare un livello di servizio e reinizializzare le conversazioni in un secondo momento. Se dopo la modifica di un livello di servizio sono presenti messaggi rimanenti, leggere i messaggi dalla coda di origine e inviarli nuovamente alla coda di destinazione.

Superamento dello spazio di archiviazione con file di database di piccole dimensioni

Le istruzioni CREATE DATABASE, ALTER DATABASE ADD FILEe RESTORE DATABASE potrebbero avere esito negativo perché l'istanza può raggiungere il limite di Archiviazione di Azure.

Ogni istanza per utilizzo generico di Istanza gestita di SQL ha fino a 35 TB di spazio di archiviazione riservato per lo spazio su disco Premium di Azure. 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. Lo spazio inutilizzato sul disco non viene conteggiato, ma la somma delle dimensioni dei dischi Premium di Azure non può superare 35 TB. In alcuni casi, un'istanza gestita che non necessita di 8 TB in totale può superare il limite di Azure di 35 TB per le dimensioni delle risorse di archiviazione a causa della frammentazione interna.

Ad esempio, un'istanza per utilizzo generico di Istanza gestita di SQL potrebbe avere un file di grandi dimensioni di 1,2 TB posizionato su un disco da 4 TB. Potrebbe anche avere 248 file di 1 GB ciascuno e che vengono posizionati su dischi separati da 128 GB. 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 Istanza gestita di SQL potrebbe raggiungere il limite di 35 TB riservato per un disco Premium di Azure 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 a causa dello spazio insufficiente 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 in questo caso potrebbe non essere 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 perché potrebbero essere sostituiti con nomi di database effettivi in futuro.

Soluzione alternativa: usare sys.databases la vista per risolvere il nome effettivo del database dal nome del database fisico, specificato sotto forma di identificatori di 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 Istanza gestita di SQL 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.

L'ambito della transazione in due database nella stessa istanza non è supportato

(Risolto a marzo 2020) La classe TransactionScope in .NET non funziona se vengono inviate due query ai due database nella stessa istanza all'interno del medesimo ambito della transazione:

using (var scope = new TransactionScope())
{
    using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=mypassword;Encrypt=true"))
    {
        conn1.Open();
        SqlCommand cmd1 = conn1.CreateCommand();
        cmd1.CommandText = string.Format("insert into T1 values(1)");
        cmd1.ExecuteNonQuery();
    }

    using (var conn2 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=mypassword;Encrypt=true"))
    {
        conn2.Open();
        var cmd2 = conn2.CreateCommand();
        cmd2.CommandText = string.Format("insert into b.dbo.T2 values(2)");        cmd2.ExecuteNonQuery();
    }

    scope.Complete();
}

Soluzione alternativa (non necessaria a partire da marzo 2020): usare Sql Connessione ion. ChangeDatabase(String) per usare un altro database in un contesto di connessione anziché usare due connessioni.

Nessuna risoluzione

Aumento del numero di account di accesso di sistema usati per la replica transazionale

Istanza gestita di SQL di Azure servizio sta creando l'account di accesso di sistema ai fini della replica transazionale. Questo account di accesso è disponibile in SSMS (in Esplora oggetti nella sezione Sicurezza, Account di accesso) o nella visualizzazione sys.sysloginsdi sistema . Il formato del nome di accesso è simile 'DBxCy\WF-abcde01234QWERT'a e l'account di accesso ha il ruolo del server pubblico. In determinate condizioni, questo account di accesso viene ricreato e a causa di un errore nell'account di accesso precedente del sistema non viene eliminato. Ciò può comportare un aumento del numero di account di accesso. Questi account di accesso non rappresentano una minaccia per la sicurezza. Possono essere ignorati in modo sicuro. Questi account di accesso non devono essere eliminati perché almeno uno di essi viene usato per la replica transazionale.

msdb la tabella per i backup manuali non mantiene il nome utente

Di recente è stato introdotto il supporto per i backup automatici in msdb, ma la tabella non contiene attualmente informazioni sul nome utente.

Gli account di accesso e gli utenti di Microsoft Entra non sono supportati in SSDT

SQL Server Data Tools non supporta completamente gli account di accesso e gli utenti di Microsoft Entra.

La rappresentazione dei tipi di accesso di Microsoft Entra non è supportata

La rappresentazione con EXECUTE AS USER o EXECUTE AS LOGIN delle entità Di sicurezza Microsoft Entra seguenti non è supportata:

  • Alias degli utenti di Microsoft Entra. In questo caso viene restituito l'errore seguente: 15517.
  • Account di accesso e utenti di Microsoft Entra basati su applicazioni o entità servizio Di Microsoft Entra. In questo caso vengono restituiti gli errori seguenti: 15517 e 15406.

La replica transazionale deve essere riconfigurata dopo il failover geografico

Se la replica transazionale è abilitata in un database in un gruppo di failover, l'amministratore Istanza gestita di SQL 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.

tempdb struttura e contenuto viene ricreato

Il tempdb database è sempre suddiviso in 12 file di dati e la struttura dei file non può essere modificata. Non è possibile modificare le dimensioni massime per ogni file e non è possibile aggiungere nuovi file a tempdb. Il tempdb database viene sempre ricreato come database vuoto all'avvio o al failover dell'istanza e le eventuali modifiche apportate in tempdb non vengono mantenute.

I log degli errori non sono permanenti

I log degli errori disponibili in Istanza gestita di SQL 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 verificarsi lacune nella cronologia dei log degli errori perché Istanza gestita di SQL è stato spostato più volte in più macchine virtuali.

Inaccessibilità dell'istanza temporanea tramite il listener del gruppo di failover durante l'operazione di ridimensionamento

Il ridimensionamento dell'istanza gestita a volte richiede lo spostamento dell'istanza in un cluster virtuale diverso, insieme ai record DNS gestiti dal servizio associati. Se l'istanza 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, ovvero il listener di sola lettura, se l'istanza è la replica geografica secondaria corrente) viene spostata nel nuovo cluster virtuale.

Nella progettazione dell'operazione di ridimensionamento corrente, i record DNS del listener vengono rimossi dal cluster virtuale di origine prima che l'istanza gestita stessa venga completamente migrata al nuovo cluster virtuale, che in alcune situazioni può causare 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: "Errore 40532: Impossibile aprire il server "xxx.xxx.xxx.xxx" richiesto dall'account di accesso. Accesso non riuscito. (Microsoft SQL Server, Errore: 40532)".

Il problema verrà risolto tramite la riprogettazione dell'operazione di ridimensionamento.

Risolto

L'esecuzione di query su una tabella esterna ha esito negativo e viene visualizzato un messaggio di errore "non supportato"

L'esecuzione di query su una tabella esterna potrebbe non riuscire con il messaggio di errore generico "Le query su tabelle esterne non sono supportate con il livello di servizio corrente o il livello di prestazioni di questo database. Valutare un aumento del livello di servizio o delle prestazioni del database". L'unico tipo di tabella esterna supportato in Istanza gestita di SQL di Azure sono le tabelle esterne PolyBase (in anteprima). Per consentire query su tabelle esterne PolyBase, è necessario abilitare PolyBase nell'istanza gestita eseguendo sp_configure il comando .

Le tabelle esterne correlate alla funzionalità query elastica di database SQL di Azure non sono supportate in Istanza gestita di SQL, ma la creazione e l'esecuzione di query non sono bloccate in modo esplicito. Con il supporto per le tabelle esterne PolyBase, sono stati introdotti nuovi controlli, bloccando l'esecuzione di query di qualsiasi tipo di tabella esterna nell'istanza gestita, a meno che PolyBase non sia abilitato.

Se si usano tabelle esterne di Query elastiche non supportate per eseguire query sui dati in database SQL di Azure o Azure Synapse dall'istanza gestita, è consigliabile usare invece la funzionalità Server collegato. Per stabilire la connessione al server collegato da Istanza gestita di SQL a database SQL, seguire le istruzioni riportate in questo articolo. Per stabilire la connessione a Linked Server da Istanza gestita di SQL a SQL Synapse, vedere le istruzioni dettagliate. Poiché la configurazione e il test della connessione al server collegato richiede tempo, è possibile usare una soluzione alternativa come soluzione temporanea per abilitare l'esecuzione di query su tabelle esterne correlate alla funzionalità query elastica:

Soluzione alternativa: eseguire i comandi seguenti (una volta per istanza) che abilitano le query su tabelle esterne:

sp_configure 'polybase enabled', 1;
GO

RECONFIGURE;
GO

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 sono in grado di accedere usando l'autenticazione di SQL Server.

Il ripristino del backup manuale senza CHECKSUM potrebbe avere esito negativo

In determinate circostanze, il backup manuale dei database eseguiti in un'istanza gestita senza CHECKSUM potrebbe non riuscire a essere ripristinato. In questi casi, riprovare a ripristinare il backup fino a quando non si riesce.

Soluzione alternativa: eseguire backup manuali dei database in istanze gestite con CHECKSUM abilitato.

L'agente non risponde durante la modifica, la disabilitazione o l'abilitazione di processi esistenti

In determinate circostanze, la modifica, la disabilitazione o l'abilitazione di un processo esistente può causare la mancata risposta dell'agente. Il problema viene attenuato automaticamente al rilevamento, con conseguente riavvio del processo dell'agente.

Autorizzazioni per il gruppo di risorse non applicate a Istanza gestita di SQL

Quando il ruolo di Azure collaboratore Istanza gestita di SQL viene applicato a un gruppo di risorse (RG), non viene applicato a Istanza gestita di SQL e non ha alcun effetto.

Soluzione alternativa: configurare un ruolo collaboratore Istanza gestita di SQL per gli utenti a livello di sottoscrizione.

I processi di SQL Agent possono essere interrotti dal riavvio del processo dell'agente

(Risolto nel marzo 2020) SQL Agent crea una nuova sessione ogni volta che viene avviato un processo, aumentando gradualmente il consumo di memoria. Per evitare di raggiungere il limite di memoria interno, che blocca l'esecuzione dei processi pianificati, il processo di Agent viene riavviato dopo che il consumo di memoria raggiunge la soglia. Potrebbe causare l'interruzione dei processi in esecuzione al momento del riavvio.

Parametro @query non supportato in sp_send_db_mail

Il parametro @query nella procedura sp_send_db_mail non funziona.

Messaggio di errore fuorviante in portale di Azure suggerisce la ricreazione dell'entità servizio

La pagina di amministrazione di Active Directory di portale di Azure per Istanza gestita di SQL di Azure può visualizzare il messaggio di errore seguente, anche se l'entità servizio esiste già:

"Istanza gestita necessita di un'entità servizio per accedere all'ID Microsoft Entra (in precedenza Azure Active Directory). Fare clic qui per creare un'entità servizio"

È possibile ignorare questo messaggio di errore se l'entità servizio per l'istanza gestita esiste già e/o l'autenticazione di Microsoft Entra nell'istanza gestita funziona.

Per verificare se l'entità servizio esiste, passare alla pagina Applicazioni aziendali nella portale di Azure, scegliere Identità gestite dall'elenco a discesa Tipo di applicazione, selezionare Applica e digitare il nome dell'istanza gestita nella casella di ricerca. Se il nome dell'istanza viene visualizzato nell'elenco dei risultati, l'entità servizio esiste già e non sono necessarie altre azioni.

Se sono già state seguite le istruzioni del messaggio di errore e il collegamento è stato selezionato dal messaggio di errore, l'entità servizio dell'istanza gestita è stata ricreata. In tal caso, assegnare le autorizzazioni di lettura di Microsoft Entra ID all'entità servizio appena creata per consentire il corretto funzionamento dell'autenticazione di Microsoft Entra. Questa operazione può essere eseguita tramite Azure PowerShell seguendo le istruzioni riportate di seguito.

Contribuire al contenuto

Per contribuire alla documentazione di Azure SQL, vedere la guida per i collaboratori di Docs.

Passaggi successivi

Per un elenco degli aggiornamenti e dei miglioramenti Istanza gestita di SQL, vedere Istanza gestita di SQL aggiornamenti del servizio.

Per gli aggiornamenti e i miglioramenti apportati a tutti i servizi di Azure, vedere Aggiornamenti del servizio.