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 sull'Istanza gestita di SQL di Azure, vedere Cos’è l'Istanza gestita di SQL di Azure?, e Cosa c’è di nuovo nell'Istanza gestita di SQL di Azure?
Nota
Microsoft Entra ID era precedentemente conosciuto come Azure Active Directory (Azure AD).
Problemi noti
Ha una soluzione alternativa
L'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'Istanza gestita di SQL di Azure nella scheda Backup. 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. Facendo clic sul collegamento Gestisci si apre un nuovo pannello 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 Backup tim (UTC) nell'elenco per distinguere i backup appartenenti ai database con lo stesso nome presente nell'istanza in periodi diversi. In alternativa, usare i comandi di PowerShell Get-AzSqlInstanceDatabaseLongTermRetentionBackup e Remove-AzSqlInstanceDatabaseLongTermRetentionBackup o i comandi CLI az sql midb ltr-backup list e az sql midb ltr-backup delete per gestire backup a lungo termine usando il parametro DatabaseState e il valore restituitoDatabaseDeletionTime per filtrare i backup per un database.
La destinazione event_file della sessione eventi di system_health non è accessibile
Quando si tenta di leggere il contenuto della destinazione event_file della 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 sessione system_health nell'Istanza gestita di SQL di Azure in modo sicuro. Nel frattempo, i clienti possono risolvere questo problema creando un equivalente della sessione system_health con una destinazione event_file nell'archiviazione BLOB di Azure. 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.
La procedura sp_send_dbmail potrebbe non riuscire quando il parametro @query viene usato nelle istanze gestite abilitate per Nov22FW.
La procedura sp_send_dbmail potrebbe non riuscire quando viene usato il parametro @query e ciò influisce sulle istanze che presentano il ciclo di funzionalità di novembre 2022 abilitato. Gli errori si verificano quando la stored procedure viene eseguita nell'account amministratore di sistema.
Questo problema è causato da un bug noto correlato al modo in cui sp_send_dbmail utilizza la rappresentazione.
Soluzione alternativa: assicurarsi di chiamare sp_send_dbmail con l'account personalizzato appropriato creato e non nell'account amministratore di sistema.
Di seguito è riportato un esempio di come creare un account dedicato e modificare gli oggetti esistenti che inviano email 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 sul cambio di 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 viene usato il parametro @query.
La procedura sp_send_dbmail può avere temporaneamente esito negativo quando viene usato il parametro @query. 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 al modo in cui sp_send_dbmail utilizza la rappresentazione e il pooling 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 di output @mailitem_id. 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’email. 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 aver rimosso di un'istanza gestita 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 dal Gruppo di trust del server 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.
Non è possibile eseguire transazioni distribuite 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 trust del server nel 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 l’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 Azure Key Vault
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. In alcune circostanze potrebbe non essere possibile configurare TDE con chiave gestita dal cliente in un nuovo Istanza gestita di SQL di Azure.
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 a Microsoft Entra ID. 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 il gruppo di failover si estende su più istanze in sottoscrizioni o gruppi di risorse di Azure, non è possibile avviare il failover manuale 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 accessi non amministratore di sistema vengono aggiunti a uno dei ruoli predefiniti del database di SQL Agent, si verifica un problema per cui le autorizzazioni EXECUTE esplicite devono essere concesse alle stored procedure del database master per il corretto funzionamento di questi accessi. Se si verifica questo problema, viene visualizzato il messaggio di errore The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229).
Soluzione alternativa: una volta aggiunti gli accessi a un ruolo predefinito del database di SQL Agent (SQLAgentUserRole, SQLAgentReaderRole o SQLAgentOperatorRole) per ognuno degli accessi aggiunti a questi ruoli, eseguire lo script T-SQL seguente per concedere esplicitamente 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 di OLTP in memoria non vengono applicati
In alcuni casi, il livello di servizio business critical non applicherà correttamente i limiti di memoria massima per gli oggetti ottimizzati per la memoria. L'Istanza gestita di SQL può consentire al carico di lavoro di usare più memoria per le operazioni di OLTP in memoria e questo potrebbe 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 avranno esito negativo più velocemente se raggiungono i limiti.
Soluzione alternativa: monitorare l'utilizzo della risorsa di archiviazione OLTP in memoria usando SQL Server Management Studio per garantire che il carico di lavoro non usi più memoria di quella disponibile. Aumentare i limiti di memoria che dipendono dal numero di vCore oppure ottimizzare il carico di lavoro per usare meno memoria.
Errore sbagliato restituito durante il tentativo di rimozione di un file non vuoto
SQL Server e Istanza gestita di SQL non consentono all'utente di rimuovere un file non vuoto. Se si tenta di rimuovere un file di dati non vuoto usando l'istruzione ALTER DATABASE REMOVE FILE, l'errore Msg 5042 – The file '<file_name>' cannot be removed because it is not empty non verrà restituito immediatamente. Istanza gestita proverà a rimuovere 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
L'istruzione RESTORE in corso, il processo di migrazione del servizio di migrazione dati e il ripristino temporizzato predefinito bloccheranno l'aggiornamento del 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 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 pool di istanze non sono interessate. La creazione o la modifica delle operazioni del livello di servizio non avrà esito negativo e non scadrà per timeout. Queste operazioni procederanno dopo 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.
Potrebbe essere necessario riconfigurare Resource Governor sul livello di servizio business critical dopo il failover
Resource Governor è una funzionalità che consente di limitare le risorse assegnate al carico di lavoro dell'utente e potrebbe classificare erroneamente un carico di lavoro dell'utente dopo il failover o la modifica del livello di servizio avviata dall'utente (ad esempio, la modifica delle dimensioni massime di vCore o della risorsa di archiviazione delle istanze).
Soluzione alternativa: eseguire ALTER RESOURCE GOVERNOR RECONFIGURE periodicamente o come parte di un processo di SQL Agent che esegue l'attività SQL quando l'istanza viene avviata se si usa Resource Governor.
È necessario inizializzare nuovamente le finestre di dialogo Service Broker tra database 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 si trovano nella coda del mittente. Qualsiasi modifica di vCore o delle dimensioni della risorsa di archiviazione dell'istanza in Istanza gestita di SQL, causerà la modifica del valore service_broke_guid nella vista sys. databases per tutti i database. Qualsiasi DIALOG creata usando l'istruzione BEGIN DIALOG che fa riferimento a Service Broker in un altro database interromperà l'invio 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 sono presenti messaggi che non vengono inviati dopo la modifica del livello di servizio, 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 gestita di SQL per utilizzo generico ha fino a 35 TB di spazio di archiviazione riservati 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 gestita di SQL per utilizzo generico potrebbe avere un file di grandi dimensioni da 1,2 TB in 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 dimostra che, in determinate circostanze, a causa di una distribuzione specifica dei file, un'istanza gestita di SQL può raggiungere il limite di 35 TB riservato a un disco Premium di Azure allegato anche quando non 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, 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 inseriti in un'istanza gestita di SQL e i server collegati o le query distribuite che fanno riferimento all'istanza corrente talvolta non riescono a 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 più necessaria da marzo 2020): usare SqlConnection.ChangeDatabase(String) per usare un altro database nel contesto di una connessione invece di 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, Accesso) 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 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 accessi. Questi account di accesso non rappresentano una minaccia per la sicurezza. Possono essere tranquillamente ignorati. Questi account di accesso non devono essere eliminati perché almeno uno di essi viene usato per la replica transazionale.
La tabella per i backup manuali nel msdb 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à Microsoft Entra seguenti non è supportata:
- Utenti con alias di Microsoft Entra. In questo caso viene restituito il seguente errore:
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:
15517e15406.
È necessario riconfigurare la replica transazionale dopo il failover geografico
Se la replica transazionale è abilitata in un database in un gruppo di failover automatico, l'amministratore dell'istanza gestita di SQL deve eseguire la pulizia di tutte le pubblicazioni nel database primario precedente e riconfigurarle sul nuovo database primario dopo che si è verificato un failover in un'altra area. Per altre informazioni, vedere Replica.
La struttura e il contenuto di tempdb vengono ricreati
Il database tempdb viene sempre suddiviso in 12 file di dati e la struttura del file non può essere modificata. Le dimensioni massime per file non possono essere modificate e non è possibile aggiungere nuovi file a tempdb. Il database tempdb viene sempre ricreato come database vuoto quando l'istanza viene avviata o si effettua il failover e tutte le modifiche apportate in tempdb non verranno mantenute.
I log degli errori non sono permanenti
I log degli errori disponibili in Istanza gestita di SQL non sono permanenti e le relative dimensioni non sono incluse nel limite di archiviazione massimo. I log degli errori potrebbero essere cancellati automaticamente se si esegue il failover. Potrebbero esserci gap nella cronologia dei log degli errori perché Istanza gestita di SQL è stata spostata più volte su diverse macchine virtuali.
Inaccessibilità temporanea dell'istanza 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, 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 o il livello di prestazioni corrente 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 nelle istanze gestite eseguendo il comando sp_configure.
Le tabelle esterne correlate alla funzionalità di 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 state bloccate in modo esplicito. Con il supporto per le tabelle esterne PolyBase sono stati introdotti nuovi controlli che bloccano l'esecuzione di query su qualsiasi tipo di tabella esterna nell'istanza gestita, a meno che PolyBase non sia abilitato.
Se si usano tabelle esterne di query elastica non supportate per eseguire query sui dati in Database SQL di Azure o Azure Synapse dall'istanza gestita, usare 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 una connessione al server collegato da Istanza gestita di SQL a SQL Synapse, controllare le istruzioni dettagliate. Poiché la configurazione e il test della connessione al server collegato richiedono tempo, è possibile usare una 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 ogni istanza) per abilitare 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 alcuni casi, il backup manuale dei database eseguito in un’Istanza gestita senza CHECKSUM potrebbe non essere ripristinato. In tal caso, riprovare a ripristinare il backup fino a quando non l'operazione non ha esito positivo.
Soluzione alternativa: eseguire backup manuali dei database in Istanza gestita con CHECKSUM abilitato.
L'agente non risponde dopo la modifica, la disabilitazione o l'abilitazione di processi esistenti
In alcune circostanze, la modifica, la disabilitazione o l'abilitazione di un processo esistente può causare la mancata risposta da parte dell'agente. Il problema viene risolto automaticamente al momento del rilevamento, con conseguente riavvio del processo dell'agente.
Autorizzazioni per il gruppo di risorse non applicate a Istanza gestita di SQL
Il ruolo Azure collaboratore di Istanza gestita di SQL, quando applicato a un gruppo di risorse (RG), non viene applicato a Istanza gestita e non ha alcun effetto.
Soluzione alternativa: configurare il ruolo Collaboratore di 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 a marzo 2020) SQL Agent crea una nuova sessione ogni volta che si avvia il processo, aumentando gradualmente il consumo di memoria. Per evitare di raggiungere il limite di memoria interna bloccando l'esecuzione dei processi pianificati, il processo dell'agente verrà riavviato quando 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 che suggerisce la nuova creazione dell'entità servizio
La pagina di amministrazione di Active Directory di portale di Azure per l'Istanza gestita di SQL di Azure può mostrare il messaggio di errore seguente, anche se l'entità servizio esiste già:
"Istanza gestita necessita di un'entità servizio per accedere a Microsoft Entra ID (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 nel 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 SQL di Azure, vedere la Guida per i collaboratori di Docs.
Contenuto correlato
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.
Commenti e suggerimenti
Presto disponibile: nel corso del 2024 verranno dismessi i problemi di GitHub come meccanismo di feedback per il contenuto e verranno sostituiti con un nuovo sistema di feedback. Per altre informazioni, vedere: https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per