Risolvere i problemi di connettività e altri errori

Si applica a:Database SQL di AzureIstanza gestita di Azure SQLDatabase SQL in Fabric

Si ricevono messaggi di errore quando la connessione al database SQL di Azure, al database SQL in Microsoft Fabric o all'istanza gestita di SQL di Azure ha esito negativo.

Come sempre, applicare le procedure consigliate e delle linee guida di progettazione durante il processo di progettazione delle applicazioni.

Steps to fix common connection issues (Passaggi per risolvere i problemi di connessione comuni)

1. Assicurarsi che TCP/IP sia abilitato come protocollo client nel server applicazioni. Nei server applicazioni in cui non sono installati gli strumenti SQL, verificare che TCP/IP sia abilitat eseguendo cliconfg.exe (utilità di rete client di SQL Server).

2. Controllare la stringa di connessione dell'applicazione per verificare che sia configurata correttamente. Assicurarsi, ad esempio, che il stringa di connessione specifichi la porta corretta (1433) e il nome completo del server. Si veda Ottenere informazioni sulla connessione utilizzando SQL Server Management Studio.

3. Provare ad aumentare il valore del timeout della connessione. È consigliabile usare un timeout di connessione di almeno 30 secondi.

4. Testare la connettività tra il server delle applicazioni e il database SQL di Azure usando Avvio rapido: usare SSMS per connettersi a e interrogare il database SQL di Azure o l'Istanza SQL gestita di Azure, un file UDL, ping o telnet. Per altre informazioni, vedere Risoluzione dei problemi di connettività e Diagnostica per i problemi di connettività.

   Nota

   Come passaggio per la risoluzione dei problemi, è anche possibile testare la connettività in un computer client diverso.

5. Come procedura consigliata, le applicazioni connesse al cloud devono usare la logica di ripetizione dei tentativi.

Se questi passaggi non risolvono il problema, provare a raccogliere altri dati e quindi contattare il supporto tecnico. Se l'applicazione è un servizio cloud, abilitare la registrazione. Questo passaggio restituisce un timestamp UTC dell'errore. Per altre informazioni su come abilitare la registrazione, vedere Abilitare la registrazione diagnostica per le app Web nel servizio app di Azure. Inoltre, database SQL restituisce l'ID di traccia. I servizi di assistenza clienti di Microsoft possono usare queste informazioni.

Errori di connettività causati da override di file DNS o host personalizzati

Se l'applicazione presenta errori di accesso permanenti (errori 18456, 40532 o 40615) isolati in reti client specifiche mentre il servizio Azure SQL è integro, la causa potrebbe essere una configurazione DNS personalizzata che aggiunge il nome di dominio completo del server a un indirizzo IP del gateway Azure SQL obsoleto.

Perché succede

database SQL di Azure usa una flotta di gateway regionali. Azure ritira periodicamente e sostituisce i gateway come parte delle normali operazioni, tra cui l'aggiornamento hardware, il ridimensionamento e la migrazione basata sullo stato di integrità. Il DNS Azure autorevole per <server>.database.windows.net viene aggiornato automaticamente per riflettere i gateway attivi correnti.

Quando l'ambiente esegue l'override di questa risoluzione DNS (tramite una voce di file host, un record CNAME statico o una zona DNS privata che mappa il FQDN del server a un indirizzo IP specifico), il client viene bloccato su tale IP. Se il gateway in tale indirizzo IP viene ritirato o riassegnato in un secondo momento, le connessioni passano all'endpoint errato. Il gateway Azure SQL verifica il nome di dominio completo in ingresso contro il server di destinazione e una discrepanza causa errori di accesso.

Rilevare un override DNS

Eseguire i controlli seguenti dal client interessato.

1. Controllare la presenza di override nel file hosts locale:

   :: Windows
   type C:\Windows\System32\drivers\etc\hosts | findstr /i "database.windows.net"
   

   # Linux or macOS
   grep -i "database.windows.net" /etc/hosts
   

2. Confrontare la risoluzione DNS del client con il DNS autoritativo di Azure.

   :: Client or recursive resolver
   nslookup <server>.database.windows.net
   
   :: Authoritative public DNS
   nslookup <server>.database.windows.net 208.67.222.222
   

   # PowerShell
   Resolve-DnsName -Name "<server>.database.windows.net" -DnsOnly
   

   Se il resolver client restituisce un indirizzo IP diverso rispetto al DNS autorevole, è attivo un override DNS.

3. Verificare la presenza di override della zona DNS privata o CNAME:

   nslookup -type=CNAME <server>.database.windows.net
   

   az network private-dns record-set list \
     --resource-group <ResourceGroup> \
     --zone-name database.windows.net \
     --output table
   

Correggere l'override

1. Rimuovere l'override. Eliminare il record del file hosts, rimuovere il record CNAME statico o eliminare il record di zona DNS privato che collega il FQDN del server a un indirizzo IP specifico.

2. Svuotare le cache DNS nel client e in qualsiasi sistema di risoluzione intermedio:

   :: Windows
   ipconfig /flushdns
   

   # Linux (systemd-resolved)
   sudo systemd-resolve --flush-caches
   
   # macOS
   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   

3. Verifica che il DNS ora risolva il gateway corrente di Azure.

   nslookup <server>.database.windows.net
   

   Verificare che l'indirizzo IP restituito sia compreso negli intervalli IP del gateway pubblicati per l'area del server. Per l'elenco, vedere la sezione Indirizzi IP del gateway in Architettura della connettività.

4. Ritestare la connettività usando Controllo connettività di Azure SQL o SQL Server Management Studio (SSMS).

Evitare questo problema

• Non associare mai FQDN dei server Azure SQL su indirizzi IP specifici nei file host, nei record CNAME statici o nelle zone DNS private. Azure SQL gateway sono dinamici e cambiano nel tempo.
• Se si usano gli elenchi di indirizzi consentiti del firewall in base agli indirizzi IP del gateway, consentire tutti gli intervalli IP del gateway per la tua regione invece dei singoli indirizzi IP. Se possibile, usare il tag del Sql.<region> servizio.
• Per la connettività privata, usare collegamento privato di Azure o endpoint privati anziché gli override DNS. Gli endpoint privati forniscono indirizzi IP privati stabili all'interno della rete virtuale e instradano direttamente al gateway.
• Sottoscrivere gli avvisi di integrità dei servizi per database SQL di Azure per ricevere notifiche sulle migrazioni del gateway nell'area.

Riferimento rapido

Implementare la logica di ripetizione dei tentativi

È fortemente raccomandato che le applicazioni client utilizzino una logica di ripetizione dei tentativi, in modo da poter ristabilire una connessione dopo aver dato all'errore temporaneo il tempo per correggersi. È consigliabile attendere 5 secondi prima di riprovare. Al primo tentativo con un ritardo inferiore a 5 secondi, si rischia di sovraccaricare il servizio cloud. Il ritardo dovrebbe crescere in modo esponenziale per ogni tentativo successivo, fino a un massimo di 60 secondi.

Per esempi di codice relativi alla logica di ripetizione dei tentativi, vedere:

• Connettersi in modo resiliente a SQL con ADO.NET
• Connettere in modo resiliente a SQL con PHP

Per altre informazioni sulla gestione degli errori temporanei nell'applicazione, vedere Risolvere gli errori di connessione temporanei.

Per i client che usano ADO.NET, è disponibile una discussione sul periodo di blocco in Pool di connessioni (ADO.NET).

Messaggi di errore temporanei (40197, 40613 e altri)

L'infrastruttura Azure è in grado di riconfigurare dinamicamente i server quando si verificano carichi di lavoro intensi nel servizio del database SQL. Questo comportamento dinamico potrebbe causare la perdita della connessione del programma client al database o all'istanza. Questo tipo di errore è chiamato errore temporaneo. Gli eventi di riconfigurazione del database avvengono in seguito a eventi pianificati (ad esempio nel caso degli aggiornamenti software) o non pianificati (ad esempio per l'arresto anomalo di un processo o per il bilanciamento del carico). La maggior parte degli eventi di riconfigurazione è di breve durata e deve essere completata in meno di 60 secondi al massimo. Tuttavia, il completamento di questi eventi in alcuni casi può richiedere più tempo, ad esempio quando una transazione di grandi dimensioni provoca un ripristino a esecuzione prolungata. Nella tabella seguente sono elencati vari errori temporanei che le applicazioni possono ricevere durante la connessione a database SQL di Azure.

Elenco di codici di errore temporanei

Passaggi per risolvere problemi di connettività temporanei

1. Controllare nel Dashboard dei servizi di Microsoft Azure le eventuali interruzioni note che si sono verificate durante il periodo in cui l’applicazione ha segnalato errori.
2. Le applicazioni che si connettono a un servizio cloud, come il database SQL di Azure, devono prevedere il verificarsi periodico di eventi di riconfigurazione e implementare la logica di ripetizione per gestire gli errori, invece di lasciare che vengano visualizzati dagli utenti come errori dell'applicazione.
3. Quando un database sta per raggiungere i limiti delle risorse, può sembrare che si stia verificando un problema di connettività temporaneo. Vedere Limiti delle risorse.
4. Se i problemi di connettività persistono oppure se l'applicazione rileva l'errore per più di 60 secondi o se vengono visualizzate più occorrenze dell'errore in un dato giorno, inoltrare una richiesta di supporto tecnico di Azure selezionando Ottieni supporto nel sito Supporto tecnico di Azure .

Si è verificato un errore di rete o specifico dell'istanza mentre veniva stabilita la connessione al server

Il problema si verifica se l'applicazione non riesce a connettersi al server.

Per risolvere questo problema, provare i passaggi (nell'ordine presentato) nella sezione Passaggi per risolvere i problemi di connessione comuni.

Il server/l’istanza non è stato trovata o non è accessibile (errori 26, 40, 10053)

Errore 26: Errore durante l'individuazione del server specificato

System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.(provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

Errore 40: Impossibile aprire una connessione con il al server

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

Errore 10053: Si è verificato un errore a livello di trasporto durante la ricezione dei risultati dal server

10053: A transport-level error has occurred when receiving results from the server. (Provider: TCP Provider, error: 0 - An established connection was aborted by the software in your host machine)

Questi problemi si verificano se l'applicazione non riesce a connettersi al server.

Per risolvere questi problemi, provare i passaggi (nell'ordine presentato) nella sezione Passaggi per risolvere i problemi di connessione comuni.

Impossibile connettersi al server a causa di problemi del firewall

Errore 40615: Impossibile connettersi al < nomeserver >

Per risolvere questo problema, configurare le impostazioni del firewall nel database SQL mediante il portale di Azure.

Errore 5: Impossibile connettersi al < nomeserver >

Per risolvere questo problema, assicurarsi che la porta 1433 sia aperta per le connessioni in uscita in tutti i firewall tra il client e Internet.

Impossibile accedere al server (errori 18456, 40531)

Accesso non riuscito per l'utente “< Nome utente >“

Login failed for user '<User name>'.This session has been assigned a tracing ID of '<Tracing ID>'. Provide this tracing ID to customer support when you need assistance. (Microsoft SQL Server, Error: 18456)

Per risolvere questo problema, contattare l'amministratore dei servizi per fornire un nome utente e una password validi.

In genere, l'amministratore dei servizi può seguire la procedura seguente per aggiungere l'account di accesso:

1. Accedere al server con SQL Server Management Studio (SSMS).

2. Eseguire la seguente query SQL nel database master per verificare se il nome di accesso è disabilitato:

   SELECT name, is_disabled FROM sys.sql_logins;
   

3. Se il nome corrispondente è disabilitato, si può decidere di abilitarlo usando la seguente istruzione:

   ALTER LOGIN <User name> ENABLE;
   

4. Se il nome utente di accesso SQL non esiste, modificare ed eseguire la query SQL seguente per creare un nuovo account di accesso SQL:

   CREATE LOGIN <SQL_login_name, sysname, login_name>
   WITH PASSWORD = '<password, sysname, Change_Password>';
   GO
   

5. In Esplora oggetti SSMS, espandere Database.

6. Selezionare il database a cui si desidera concedere l'autorizzazione per l'utente.

7. Fare clic con il pulsante destro del mouse sulla cartella Sicurezza e scegliere Nuovo e quindi Utente.

8. Nello script generato con segnaposti sostituire i parametri del modello SSMS seguendo la procedura qui sotto ed eseguirlo, ad esempio:

   CREATE USER [<user_name, sysname, user_name>]
   FOR LOGIN [<login_name, sysname, login_name>]
   WITH DEFAULT_SCHEMA = [<default_schema, sysname, dbo>];
   GO
   
   -- Add user to the database owner role
   EXEC sp_addrolemember N'db_owner', N'<user_name, sysname, user_name>';
   GO
   

   È anche possibile usare sp_addrolemember per eseguire il mapping di utenti specifici per ruoli specifici del database.

   Nota

   In database SQL di Azure, prendere in considerazione la sintassi più recente ALTER ROLE per la gestione dell'appartenenza ai ruoli del database.

Per altre informazioni, vedere Autorizzare l’accesso al database.

Errori di timeout della connessione scaduti

Il timeout della connessione è scaduto

System.Data.SqlClient.SqlException (0x80131904): Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=3; handshake=29995;

System.Data.SqlClient.SqlException (0x80131904): Timeout scaduto

System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

System.Data.Entity.Core.EntityException: il provider sottostante non è riuscito nell'apertura.

System.Data.Entity.Core.EntityException: The underlying provider failed on Open. -> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. -> System.ComponentModel.Win32Exception: The wait operation timed out

Non è possibile connettersi a < nome del server >

Cannot connect to <server name>.ADDITIONAL INFORMATION:Connection Timeout Expired. The timeout period elapsed during the post-login phase. The connection could have timed out while waiting for server to complete the login process and respond; Or it could have timed out while attempting to create multiple active connections. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=231; handshake=983; [Login] initialization=0; authentication=0; [Post-Login] complete=13000; (Microsoft SQL Server, Error: -2) For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=-2&LinkId=20476 The wait operation timed out

Queste eccezioni possono verificarsi a causa di problemi di connessione o di query. Per verificare che questo errore sia causato da problemi di connettività, si veda Verificare se un errore è causato da un problema di connettività.

I timeout di connessione si verificano perché l'applicazione non è in grado di connettersi al server. Per risolvere questo problema, provare i passaggi (nell'ordine presentato) nella sezione Passaggi per risolvere i problemi di connessione comuni.

Risolvere gli errori di connettività degli endpoint privati

Le connessioni a database SQL di Azure tramite un endpoint privato possono non funzionare con timeout di connessione o con errori di handshake di pre-accesso. Eseguire i passaggi seguenti nell'ordine. Ogni passaggio risolve una modalità di errore distinta.

Passaggio 1: Verificare l'endpoint privato e la risoluzione DNS

Verificare che l'endpoint privato sia stato creato e che il DNS venga risolto all'indirizzo IP privato.

Passaggio 2: Aggiungere una regola del firewall a livello di server per l'indirizzo IP in uscita

Anche con un endpoint privato, database SQL di Azure applica comunque regole del firewall IP a livello di server sull'IP di origine visualizzato dal gateway.

1. Identifica l'indirizzo IP in uscita. Per il traffico locale instradato tramite un gateway VPN o ExpressRoute, l'indirizzo IP in uscita è in genere il gateway o l'IP privato NAT all'interno della rete virtuale. Dall'interno di Azure, si tratta dell'IP privato della macchina virtuale o di un indirizzo IP front-end del servizio di bilanciamento del carico.

2. Aggiungere una regola del firewall a livello di server per l'INDIRIZZO IP o la subnet:

   EXECUTE sp_set_firewall_rule
       @name = N'AllowPrivateEndpointSubnet',
       @start_ip_address = '10.0.1.0',
       @end_ip_address = '10.0.1.255';
   

Passaggio 3: Aprire le porte corrette nei firewall perimetrali o locali

Le porte necessarie dipendono dai criteri di connessione:

Se una connessione ha esito positivo dall'interno della rete virtuale ma ha esito negativo dall'ambiente locale, è probabile che il firewall locale blocchi le porte più elevate dell'intervallo 1433-65535 . Aprire l'intervallo di porte oppure modificare i criteri di connessione del server in Proxy. Per altre informazioni, vedere Uso dei criteri di connessione di reindirizzamento con endpoint privati.

Passaggio 4: Verificare il routing simmetrico per scenari UDR, appliance virtuale di rete e NAT

Se il traffico verso l'endpoint privato SQL passa attraverso un'appliance virtuale di rete (NVA), Firewall di Azure o un gateway NAT, il traffico di ritorno deve seguire lo stesso percorso. Il routing asimmetrico causa reset TCP o perdite silenziose.

Fatti chiave:

• Azure crea una route di sistema /32 per ogni IP dell'endpoint privato (ad esempio 10.0.1.4/32 con il tipo di hop successivo InterfaceEndpoints). Una route definita dall'utente (UDR) può eseguire l'override di questa route di sistema solo con un prefisso uguale o più specifico (un altro /32).

• Se si instrada il traffico in uscita a un'appliance virtuale di rete, l'appliance virtuale di rete deve applicare SNAT (Source Network Address Translation) in modo che i pacchetti restituiti tornino all'appliance virtuale di rete invece di passare direttamente al client. Senza SNAT, il percorso restituito è asimmetrico.

• I criteri di rete degli endpoint privati (NSG e il supporto UDR nella subnet dell'endpoint privato) sono disabilitati per impostazione predefinita. Per applicare le regole del gruppo di sicurezza di rete o UDR al traffico dei punti finali privati, abilitare i criteri di rete nella subnet.

  az network vnet subnet update \
    --name <SubnetName> \
    --vnet-name <VNetName> \
    --resource-group <ResourceGroup> \
    --private-endpoint-network-policies Enabled
  

Se una connessione funziona senza un'appliance virtuale di rete ma si verifica il timeout quando viene instradata attraverso un'appliance virtuale di rete, la /32 route di sistema invia il traffico di ritorno direttamente al client e ignora la tabella di stato dell'appliance virtuale di rete. Aggiungere una /32 UDR per l'IP dell'endpoint privato che punta alla NVA e abilitare SNAT sulla NVA.

Passaggio 5: Usare Network Watcher per confermare la connettività end-to-end

Se i passaggi precedenti hanno un aspetto corretto ma le connessioni hanno ancora esito negativo, usare Azure Network Watcher per isolare l'errore:

Riferimento rapido

Errori di terminazione della connessione di rete

Le librerie client SQL si connettono a database SQL di Azure e Istanza gestita di SQL di Azure usando il protocollo di rete TCP. Una libreria client usa un componente di livello inferiore denominato provider TCP per gestire le connessioni TCP. Quando il provider TCP rileva che un host remoto termina in modo imprevisto una connessione TCP esistente, la libreria client genera un errore. Poiché l'errore è un errore client e non un errore di SQL Server, non è incluso alcun numero di errore SQL. Il numero di errore è invece 0 e viene usato il messaggio di errore del provider TCP.

Esempi di errori di terminazione della connessione di rete includono:

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) An existing connection was forcibly closed by the remote host

A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

The client was unable to establish a connection because of an error during connection initialization process before login. Possible causes include the following: the client tried to connect to an unsupported version of SQL Server; the server was too busy to accept new connections; or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)

Errori di terminazione di connessione possono verificarsi perché il database o il pool elastico non è temporaneamente disponibile. Possono verificarsi anche a causa di vari problemi nell'infrastruttura di rete tra il server di database e l'applicazione client, inclusi firewall, appliance di rete e così via. Questi problemi possono essere temporanei o permanenti. Come indicazioni generali, le applicazioni devono usare un numero fisso di tentativi per questi errori prima di considerarli errori permanenti.

Errori di governance delle risorse

Database SQL di Azure usa un'implementazione della governance delle risorse basata su Resource Governor per applicare i limiti delle risorse. Scopri di più sullagestione delle risorse nel database SQL di Azure.

Gli errori di governance delle risorse più comuni sono elencati per primi con i dettagli, seguiti da una tabella di messaggi di errore di governance delle risorse.

Errori 10928 e 10936: ID della risorsa: 1. Il limite di richiesta per il [database/pool elastico] è pari a %d ed è stato raggiunto

Se viene raggiunto il limite a livello di database, il messaggio di errore dettagliato in questo caso sarà il seguente: Resource ID : 1. The request limit for the database is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance.

Se viene raggiunto il limite del pool elastico, il messaggio di errore dettagliato in questo caso legge: Resource ID : 1. The request limit for the elastic pool is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance. I limiti del pool elastico sono superiori ai limiti del database. Per altre informazioni, vedere Gestione delle risorse nel database SQL di Azure. Si potrebbero incontrare dei limiti quando più database nel pool utilizzano una risorsa (come i lavoratori) contemporaneamente.

Questo messaggio di errore indica che è stato raggiunto il limite di lavoro per il database o il pool elastico. Il valore massimo dei lavoratori simultanei per l'obiettivo di servizio del database o del pool elastico sarà mostrato al posto del segnaposto %d.

Connettersi con la Connessione Amministrativa Dedicata (DAC), se necessario

Se si verifica un evento imprevisto live in cui viene raggiunto il limite di lavoro, è possibile che venga visualizzato l'errore 10928 quando ci si connette usando SQL Server Management Studio (SSMS). Una sessione può connettersi usando la Connessione diagnostica per amministratori di database (DAC) anche quando è stata raggiunta la soglia massima di lavoro.

Per stabilire una connessione con il DAC da SSMS:

• Nel menu selezionare File> Nuovo > Query del motore di database
• Nella finestra di dialogo sulla connessione nel campo Nome server immettere admin:<fully_qualified_server_name> (ad esempio, admin:servername.database.windows.net).
• Selezionare Opzioni >>
• Selezionare la scheda Proprietà connessione
• Nella casella Connessione al database: digitare il nome del database
• Selezionare Connetti.

Se ricevi l'errore 40613, Database '%.*ls' on server '%.*ls' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '%.*ls', ciò potrebbe indicare che un'altra sessione è già connessa al DAC. Una sola sessione può connettersi alla DAC (Dedicated Admin Connection) per un database singolo o un pool elastico alla volta.

Se si verifica l'errore 'Impossibile connettersi al server’ dopo aver selezionato Connetti, nel caso in cui si stia utilizzando una versione di SSMS precedente alla 18.9, è possibile che la sessione DAC sia stata comunque stabilita correttamente. Le versioni precedenti di SSMS cercavano di fornire IntelliSense per le connessioni al DAC. Questa operazione è fallita perché il DAC supporta solo un singolo processo di lavoro e IntelliSense richiede un processo di lavoro separato.

Non è possibile usare una connessione DAC con Esplora Oggetti in SSMS.

Controlla l'uso di max_worker_percent

Per trovare le statistiche sull'utilizzo delle risorse per il database per 14 giorni, eseguire una query sulla vista del catalogo di sistema sys.resource_stats. La colonna max_worker_percent mostra la percentuale di lavoratori utilizzati rispetto al limite di lavoratori per il database. Connetti al database master sul server logico per interrogare sys.resource_stats.

SELECT start_time, end_time, database_name, sku, avg_cpu_percent, max_worker_percent, max_session_percent 
FROM sys.resource_stats;

È anche possibile eseguire query sulle statistiche dell'ultima ora sull'utilizzo delle risorse dalla vista di gestione dinamica sys.dm_db_resource_stats. Collegati direttamente al tuo database per interagire con sys.dm_db_resource_stats.

SELECT end_time, avg_cpu_percent, max_worker_percent, max_session_percent
FROM sys.dm_db_resource_stats;

Ridurre l'utilizzo dei lavoratori quando possibile

Le catene di blocco possono causare un aumento improvviso del numero di lavoratori in un database. Un volume elevato di query concorrenti parallele può causare un numero elevato di lavoratori. Aumentare il massimo grado di parallelismo (MAXDOP) o impostare MAXDOP su zero può aumentare il numero di lavoratori attivi.

Gestire un incidente con personale insufficiente seguendo i seguenti passaggi:

1. Indagare se si verifica un blocco del processo o se è possibile identificare un volume elevato di lavoratori concorrenti. Eseguire la query seguente per esaminare le richieste correnti e verificare eventuali blocchi quando il database restituisce l'Errore 10928. Per eseguire la query, potrebbe essere necessario connettersi alla Dedicated Admin Connection (DAC).

   SELECT
       r.session_id, r.request_id, r.blocking_session_id, r.start_time, 
       r.status, r.command, DB_NAME(r.database_id) AS database_name,
       (SELECT COUNT(*) 
           FROM sys.dm_os_tasks AS t 
           WHERE t.session_id=r.session_id and t.request_id=r.request_id) AS worker_count,
       i.parameters, i.event_info AS input_buffer,
       r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
       r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
   FROM sys.dm_exec_requests as r
   JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
   OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
   WHERE s.is_user_process=1;
   GO
   

   1. Cercare le righe con un oggetto blocking_session_id per identificare le sessioni bloccate. Trova ciascun blocking_session_id nell'elenco per determinare se anche la sessione è bloccata. Seguendo i valori blocking_session_id e session_id, si arriverà al blocco principale: una sessione che non è bloccata ma blocca. Ottimizzare la query del blocco "head".

      Suggerimento

      Per informazioni più dettagliate sulla risoluzione dei problemi di esecuzione prolungata o blocco delle query, vedere Comprendere e risolvere i problemi di blocco.

   2. Per identificare un volume elevato di lavoratori simultanei, esaminare il numero complessivo di richieste e la colonna worker_count per ciascuna di esse. Worker_count è il numero di lavoratori al momento del campionamento e può cambiare nel tempo durante l'esecuzione della richiesta. Ottimizzare le query per ridurre l'utilizzo delle risorse se la causa dell'aumento del numero di lavoratori è costituita da query simultanee in esecuzione con un livello di parallelismo ideale. Per ulteriori informazioni, vedere Ottimizzazione delle query/Indicazioni.

2. Valutare l'impostazione massimo grado di parallelismo (MAXDOP) per il database.

Aumentare i limiti dei lavoratori

Se il database o il pool elastico raggiunge costantemente il limite dei worker nonostante il fatto di risolvere i blocchi, ottimizzare le query e convalidare l'impostazione MAXDOP, considera di scalare verso l'alto il database o il pool elastico per aumentare il limite dei worker.

Trovare i limiti delle risorse per database SQL di Azure in base al livello di servizio e alle dimensioni di calcolo:

• Limiti di risorse per i database singoli usando il modello di acquisto vCore
• Limiti delle risorse per i pool elastici secondo il modello di acquisto vCore
• Limiti di risorse per i database singoli usando il modello di acquisto DTU
• Limiti di risorse per i pool elastici usando il modello di acquisto basato su DTU

Scopri di più sulla governance delle risorse dei worker nel database SQL di Azure.

Errore 10929: ID della risorsa: 1

10929: Resource ID: 1. The %s minimum guarantee is %d, maximum limit is %d and the current usage for the database is %d. However, the server is currently too busy to support requests greater than %d for this database. See http://go.microsoft.com/fwlink/?LinkId=267637 for assistance. Otherwise, please try again later.

Errore 40501: il servizio è attualmente occupato

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: %ls. Code: %d.

L’errore 40501 è un errore di limitazione del motore, che indica che i limiti delle risorse vengono superati.

Per altre informazioni sui limiti delle risorse, vedere Gestione delle risorse nel database SQL di Azure.

Errore 40544: Il database ha raggiunto la quota massima

40544: The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions. Incident ID: <ID>. Code: <code>.

Questo errore si verifica quando il database ha raggiunto la quota di dimensioni.

I passaggi seguenti consentono di risolvere il problema o di fornire altre opzioni:

1. Controllare le dimensioni correnti del database usando il dashboard nel portale di Azure.

   Nota

   Per identificare le tabelle che utilizzano la maggior parte dello spazio e sono quindi potenziali candidati per la pulizia, eseguire la query SQL seguente:

   SELECT o.name,
    SUM(p.row_count) AS 'Row Count',
    SUM(p.reserved_page_count) * 8.0 / 1024 AS 'Table Size (MB)'
   FROM sys.objects o
   JOIN sys.dm_db_partition_stats p on p.object_id = o.object_id
   GROUP BY o.name
   ORDER BY [Table Size (MB)] DESC;
   GO
   

2. Se le dimensioni correnti non superano le dimensioni massime supportate per l'edizione, è possibile usare ALTER DATABASE per aumentare l'impostazione MAXSIZE.

3. Se il database supera già le dimensioni massime supportate per l'edizione, provare uno o più dei passaggi seguenti:

   • Eseguire normali attività di pulizia del database. Ad esempio, pulire i dati indesiderati usando troncamento/eliminazione, oppure trasferire i dati utilizzando SQL Server Integration Services (SSIS) o l'utilità di copia bulk (bcp).
   • Partizionare o eliminare i dati, eliminare gli indici o consultare la documentazione per trovare le soluzioni possibili.
   • Per il ridimensionamento del database, vedere Ridimensionare le risorse del database singolo e Ridimensionare le risorse del pool elastico.

Errore 40549: Sessione terminata perché è presente una transazione a lunga esecuzione

40549: Session is terminated because you have a long-running transaction. Try shortening your transaction.

Se si verifica ripetutamente questo errore, provare a risolvere il problema seguendo questa procedura:

1. Eseguire la query seguente per visualizzare le sessioni aperte con un valore elevato per la colonna duration_ms:

   SELECT
       r.start_time, DATEDIFF(ms,start_time, SYSDATETIME()) as duration_ms, 
       r.session_id, r.request_id, r.blocking_session_id,  
       r.status, r.command, DB_NAME(r.database_id) AS database_name,
       i.parameters, i.event_info AS input_buffer,
       r.last_wait_type, r.open_transaction_count, r.total_elapsed_time, r.cpu_time,
       r.logical_reads, r.writes, s.login_time, s.login_name, s.program_name, s.host_name
   FROM sys.dm_exec_requests as r
   JOIN sys.dm_exec_sessions as s on r.session_id=s.session_id
   OUTER APPLY sys.dm_exec_input_buffer (r.session_id,r.request_id) AS i
   WHERE s.is_user_process=1
   ORDER BY start_time ASC;
   GO
   

   È possibile ignorare le righe in cui la colonna input_buffer mostra una query da sys.fn_MSxe_read_event_stream: queste richieste sono correlate alle sessioni di Eventi Estesi.

2. Esaminare la colonna blocking_session_id per verificare se il blocco contribuisce alle transazioni di lunga durata.

   Nota

   Per altre informazioni sulla risoluzione dei problemi di blocco nel database SQL di Azure, vedere Informazioni e risoluzione dei problemi di blocco.

3. Prendere in considerazione l'invio in batch delle query. Per informazioni sull’invio in batch, vedere Come usare l’invio in batch per migliorare le prestazioni delle applicazioni di database SQL di Azure e Istanza gestita di SQL di Azure

Errore 40551: Sessione terminata a causa di un utilizzo eccessivo di tempdb

40551: The session has been terminated because of excessive TEMPDB usage. Try modifying your query to reduce the temporary table space usage.

Per risolvere il problema, seguire questa procedura:

1. Modificare le query per ridurre l'utilizzo dello spazio delle tabelle temporanee.
2. Eliminare gli oggetti temporanei dopo che non sono più necessari.
3. Troncare le tabelle o rimuovere le tabelle inutilizzate.

Errore 40552: Sessione terminata a causa di un utilizzo eccessivo dello spazio del log delle transazioni

40552: The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction.

Per risolvere il problema, procedere con i metodi seguenti:

• Il problema può verificarsi a causa di operazioni di inserimento, aggiornamento o eliminazione. Cerca di ridurre subito il numero di righe su cui si opera implementando l'invio in batch o suddividendole in più transazioni più piccole.
• Il problema può verificarsi a causa di operazioni di ricompilazione dell'indice. Per risolvere questo problema, assicurarsi che il numero di righe interessate nella tabella * (dimensione media del campo aggiornato in byte + 80) < 2 gigabyte (GB).
• Per una ricompilazione dell'indice, le dimensioni medie del campo aggiornato devono essere sostituite dalle dimensioni medie dell'indice.
• Per altre informazioni, vedere Risoluzione dei problemi relativi a un log delle transazioni completo in database SQL di Azure e Risoluzione dei problemi relativi a un log delle transazioni completo in Istanza gestita di SQL di Azure.

Errore 40553: Sessione terminata a causa di un utilizzo eccessivo dell’utilizzo memoria

40553: The session has been terminated because of excessive memory usage. Try modifying your query to process fewer rows.

Per risolvere questo problema, provare a ottimizzare la query.

Per una procedura di risoluzione dei problemi approfondita, vedere La mia query funziona correttamente nel cloud?

Per altre informazioni su altri errori di memoria insufficiente e query di esempio, vedere Risolvere gli errori di memoria insufficiente con database SQL di Azure.

Tabella dei messaggi di errore di governance delle risorse

Errori relativi al pool elastico

Di seguito sono elencati gli errori riguardanti la creazione e l'uso di pool elastici:

Impossibile aprire il database "master" richiesto dall'account di accesso. L'accesso non è riuscito

Questo problema si verifica perché l'account non dispone dell'autorizzazione per accedere al database master. Tuttavia, per impostazione predefinita, SQL Server Management Studio (SSMS) tenta di connettersi al database master.

Per risolvere il problema, seguire questa procedura:

1. Nella schermata di accesso di SSMS selezionare Opzioni e quindi selezionare Proprietà connessione.

2. Nel campo Connessione al database immettere il nome predefinito del database dell'utente come database di accesso predefinito e quindi selezionare Connessione.

   

Errori di sola lettura

Se si tenta di scrivere in un database di sola lettura, viene visualizzato un errore. In alcuni scenari, la causa dello stato di sola lettura del database potrebbe non essere immediatamente chiara.

Errore 3906: Impossibile aggiornare il database "databaseName" perché è di sola lettura.

Quando si tenta di modificare un database di sola lettura, viene generato il seguente errore.

Msg 3906, Level 16, State 2, Line 1
Failed to update database "%d" because the database is read-only.

Esistono varie possibili spiegazioni del motivo per cui un database è di sola lettura.

Dopo un failover manuale, le applicazioni si connettono ancora alla replica precedente

In database SQL di Azure, dopo un failover in un'altra replica, l'applicazione potrebbe ancora connettersi alla replica primaria precedente a causa del DNS. Il routing di connessione al gruppo di failover viene implementato tramite DNS.

Possibili cause principali:

1. Durante il failover, gli endpoint del gruppo di failover vengono aggiornati per puntare ai nuovi server primari e secondari pertinenti, modificando il target della relativa voce DNS. Per impostazione predefinita, le voci DNS vengono create con un TTL di 30 secondi, il che significa che i client DNS memorizzano nella cache queste voci per 30 secondi. Di conseguenza, gli aggiornamenti ai record DNS non vengono propagati immediatamente; le voci non saranno aggiornate fino a quando tutti i client e i nodi intermedi non abbiano aggiornato le cache. Possono quindi essere necessari da 0 a circa 10 minuti (a seconda della topologia di rete) affinché gli account di accesso agli endpoint del gruppo di failover vengano indirizzati alle nuove destinazioni in seguito a un failover. Lo svuotamento delle cache DNS potrebbe anche essere inutile, dal momento che i nodi di rete intermedi che rispondono alle richieste DNS memorizzano nella cache anche i risultati DNS per un certo periodo di tempo.

   La soluzione alternativa consigliata per questo problema è semplicemente attendere l'aggiornamento delle voci DNS nel client. Attualmente, questa soluzione porta alla risoluzione del problema nell'arco di 10 minuti.

2. Alcune librerie client SQL usano una funzionalità denominata "pool di connessioni" che riutilizza le connessioni alla stessa origine dati anziché chiuderle e riaprirle ogni volta che è necessaria una nuova connessione di database. In particolare, il pool di connessioni è abilitato in ADO.NET per impostazione predefinita. Se combinato con il problema descritto al punto 1), il pooling di connessioni può far sì che le connessioni appena aperte riutilizzino una connessione al vecchio database, impedendo così all'applicazione di connettersi al nuovo database primario all'infinito.

Soluzioni:

Esistono tre possibili soluzioni alternative a questo problema DNS dopo un failover del Failover Group:

1. Modificare l'applicazione per richiamare SQLConnection.ClearAllPools o SQLConnection.ClearPool(conn) ogni volta che viene rilevato un errore di “sola lettura”.
2. Nella stringa di connessione dell'applicazione, specificare Pooling=False per disattivare il pooling delle connessioni. Questa opzione deve essere controllata, in quanto potrebbe avere un impatto significativo sulle prestazioni se l'applicazione apre e chiude frequentemente le connessioni.
3. Un'altra opzione per evitare i ritardi di replica/memorizzazione nella cache DNS consiste nel connettersi direttamente usando il nome del server logico database SQL di Azure (del server secondario originale, ora il nuovo database primario) per un intervallo di tempo dopo l’errore 3906.

È possibile che si sia connessi a una replica di sola lettura

Per database SQL di Azure e Istanza Gestita di Azure SQL, potresti essere connesso a un database su una replica di sola lettura. In questo caso, la query seguente che usa la funzione DATABASEPROPERTYEX() restituisce READ_ONLY:

SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability');
GO

Se ci si connette usando SQL Server Management Studio, verificare se è stato specificato ApplicationIntent=ReadOnly nella scheda Parametri aggiuntivi di connessionenelle opzioni di connessione.

Se la connessione proviene da un'applicazione o da un client che usa un stringa di connessione, verificare se la stringa di connessione ha specificato ApplicationIntent=ReadOnly. Per ulteriori informazioni, vedere Connessione a una replica di sola lettura.

Il database può essere impostato su sola lettura

Se si usa database SQL di Azure, è possibile che il database stesso sia stato impostato su sola lettura. È possibile verificare lo stato del database con la query seguente:

SELECT name, is_read_only
FROM sys.databases
WHERE database_id = DB_ID();

È possibile modificare lo stato di sola lettura per un database in database SQL di Azure usando ALTER DATABASE Transact-SQL. Non è attualmente possibile impostare un database in un'istanza gestita in sola lettura.

Verificare se un errore è causato da un problema di connettività

Per verificare se un errore è causato da un problema di connettività, esaminare l'analisi dello stack per i frame che mostrano chiamate per aprire una connessione come le seguenti (si noti il riferimento alla classe SqlConnection):

System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry)
 at System.Data.SqlClient.SqlConnection.Open()
 at AzureConnectionTest.Program.Main(String[] args)
ClientConnectionId:<Client connection ID>

Quando l'eccezione viene attivata da problemi delle query, si noterà uno stack di chiamate simile al seguente (si noti il riferimento alla classe SqlCommand). In questo caso, ottimizzare le query.

  at System.Data.SqlClient.SqlCommand.ExecuteReader()
  at AzureConnectionTest.Program.Main(String[] args)
  ClientConnectionId:<Client ID>

Per altre informazioni sull'ottimizzazione delle prestazioni, vedere:

• Come gestire indici e statistiche in Azure SQL
• Ottimizzare le applicazioni e i database per le prestazioni nel database SQL di Azure
• Monitorare le prestazioni usando le viste a gestione dinamica
• Gestione del Query Store nel database SQL di Azure

Contenuto correlato

• Architettura della connettività
• Controllo di accesso alla rete del database SQL di Azure e Azure Synapse Analytics
• Risoluzione dei problemi relativi a un log delle transazioni completo in database SQL di Azure
• Risoluzione dei problemi relativi a un log delle transazioni completo in Istanza gestita di SQL di Azure
• Risolvere gli errori di connessione temporanei
• Analizzare e impedire i deadlock nel database SQL di Azure e nel database SQL di Fabric