Esporta (0) Stampa
Espandi tutto

Limitazione del database SQL di Azure

Aggiornamento: febbraio 2015

Questo argomento descrive in dettaglio il meccanismo della limitazione del motore, i codici di errore associati e il modo in cui risolvere gli errori che possono verificarsi.

Nella tabella indicata di seguito vengono fornite informazioni sul meccanismo di limitazione del motore e sul relativo codice di errore restituito, nonché indicazioni per risolvere il problema.

 

Meccanismo di limitazione del motore Codice di errore restituito Indicazione

La limitazione del motore segue questa procedura per ridurre il carico e proteggere l'integrità di sistema.

  1. Determina la riduzione del carico necessaria per riportare il sistema a uno stato integro.

  2. Contrassegna i database dei sottoscrittori che utilizzano un numero eccessivo di risorse come candidati per la limitazione. Se la limitazione del motore si verifica a causa di un tipo leggermente superato, determinati database potrebbero non essere considerati come candidati per la limitazione. Se la limitazione del motore si verifica a causa di un tipo superato in modo significativo, tutti i database dei sottoscrittori possono essere candidati per la limitazione, ad eccezione dei database che non hanno ricevuto alcun carico nel ciclo di limitazione immediatamente precedente al ciclo corrente.

  3. Calcola il numero di database candidati che devono essere limitati per riportare il sistema a uno stato integro valutando i modelli cronologici di utilizzo delle risorse dei database candidati.

  4. Limita il numero calcolato di database candidati finché il carico del sistema non tornerà al livello desiderato. A seconda se la limitazione è totale o parziale, il grado di limitazione applicato o la modalità di limitazione può variare. È possibile determinare il grado e la modalità della limitazione applicata mediante i valori di ID incidente e Codice nel messaggio di errore. Qualsiasi database limitato rimarrà in questo stato almeno per l'intera durata di un ciclo (10 secondi), ma la limitazione potrebbe persistere per vari cicli per riportare il sistema a uno stato integro.

40501: Il servizio è attualmente occupato. Eseguire nuovamente la richiesta dopo 10 secondi. ID incidente: <ID>. Codice: <codice>.

noteNota
I valori ID incidente e Codice possono essere utilizzati per determinare quali richieste sono limitate e se si tratta di una limitazione parziale o totale. Per altre informazioni, vedere le sezioni "ID evento imprevisto di limitazione" e "Decodifica dei codici motivo" più avanti in questo argomento.

Eseguire il back-off ed effettuare nuovamente la richiesta dopo 10 secondi.

L'ID evento imprevisto di limitazione nell'errore 40501 è un valore GUID che consente di identificare in modo univoco un evento imprevisto di limitazione.

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: <ID>. Code: <code>.

Se non è possibile determinare il motivo per cui si è verificata la limitazione o persiste e non si è in grado di risolvere il problema, contattare il Supporto tecnico di Microsoft e indicare l'ID evento imprevisto (<ID>) indicato nel messaggio di errore. Questo ID evento imprevisto verrà utilizzato dal Supporto tecnico di Microsoft per recuperare altre informazioni correlate all'evento imprevisto di limitazione. L'ID evento imprevisto può essere utilizzato per ottenere le informazioni seguenti:

  • Ora di inizio dell'evento di limitazione imprevisto.

  • Tipo di limitazione (confronto tra la limitazione parziale e quella totale).

  • Tipo di risorsa, ad esempio CPU, a causa della quale viene rilevato l'evento imprevisto di limitazione.

  • Tipo di applicazione in esecuzione al momento dell'evento imprevisto di limitazione.

Dopo aver appreso la causa radice sottostante dal Supporto tecnico Microsoft, sarà possibile apportare le modifiche appropriate all'applicazione.

In questa sezione viene descritto come decodificare i codici motivo restituiti dal codice di errore seguente relativo alla limitazione del motore.

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: <ID>. Code: <code>.

Il codice motivo (<codice>) nel messaggio di errore è un numero decimale che contiene informazioni sulla modalità di limitazione e sui tipi di risorse superati.

  • La modalità di limitazione enumera i tipi di istruzione rifiutati.

  • Il tipo di risorsa specifica le risorse superate. La limitazione può essere utilizzata in più tipi di risorse contemporaneamente, ad esempio CPU e I/O.

Considerare come esempio il seguente messaggio di errore, in cui il codice motivo è 131075.

40501: The service is currently busy. Retry the request after 10 seconds. Incident ID: {5DE17AB8-A6E34BE5-A2E95BB5D4CC4155}. Code: 131075.

Nel diagramma seguente viene illustrato come decodificare i codici motivo.

Decodifica dei codici motivo

Per ottenere la modalità di limitazione, applicare il modulo 4 al codice motivo. L'operazione modulo restituisce il resto di un numero diviso per un altro. Per ottenere il tipo di limitazione e il tipo di risorsa, dividere il codice motivo per 256, come mostrato nel passaggio 1. Convertire il quoziente del risultato nell'equivalente binario, come mostrato nei passaggi 2 e 3. Nel diagramma sono elencati tutti i tipi di limitazione e tutti i tipi di risorse. Confrontare il tipo di limitazione in uso con i bit del tipo di risorsa, come mostrato nel diagramma.

Nella tabella seguente viene fornito un elenco delle modalità di limitazione.

 

Codice modalità di limitazione Descrizione Tipi di istruzione rifiutati Istruzioni che possono ancora essere elaborate

0

Nessuna limitazione

Nessuna

Tutte

1

Rifiuto di aggiornamenti/inserimenti

INSERT, UPDATE, CREATE TABLE | INDEX

DELETE, DROP TABLE | INDEX, TRUNCATE

2

Rifiuto di qualsiasi scrittura

INSERT, UPDATE, DELETE, CREATE, DROP

SELEZIONA

3

Rifiuto di tutto

Tutte

Nessuna

Per ottenere la modalità di limitazione, applicare il modulo 4 al codice motivo. 131075 % 4 = 3. Il risultato 3 indica che la modalità di limitazione è "Rifiuto di tutto".

Per ottenere il tipo di limitazione e il tipo di risorsa, dividere il codice motivo per 256. Convertire quindi il quoziente del risultato nell'equivalente binario. 131075 / 256 = 512 (decimale) e 512 (decimale) = 10 00 00 00 00 (binario). Ciò significa che al database è stata applicata una limitazione a causa della CPU (tipo di risorsa 4) e della limitazione totale (10).

Nel codice di esempio indicato di seguito viene utilizzata la classe ThrottlingCondition nel blocco di applicazioni per la gestione di errori temporanei (noto anche come "Topaz") in Enterprise Library Integration Pack for Azure per decodificare il codice motivo dell'errore di limitazione del motore (40501). Per scaricare gli assembly del blocco di applicazioni per la gestione di errori temporanei e il codice sorgente per utilizzare la classe ThrottlingCondition, vedere Enterprise Library 5.0 Integration Pack for Azure.

In questo codice di esempio viene richiesto di immettere il codice motivo ottenuto nell'errore di limitazione del motore (40501) e quindi vengono visualizzati la modalità di limitazione, il tipo di limitazione e il tipo di risorsa per il codice motivo specificato.

using System;
using Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.Data;

namespace ThrottlingDecoder
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Write("Enter a throttling code to be decoded: ");
            var rawCode = Console.ReadLine();
            int reasonCode;

            if (Int32.TryParse(rawCode, out reasonCode))
            {
                var throttlingCode = ThrottlingCondition.FromReasonCode(reasonCode);

                Console.WriteLine("\nBreakdown for throttling reason code {0}:\n", reasonCode);

                Console.WriteLine("Throttling mode: {0}", throttlingCode.ThrottlingMode);
                Console.WriteLine("Throttled On CPU: {0}", throttlingCode.IsThrottledOnCpu);
                Console.WriteLine("Throttled On DB Size: {0}", throttlingCode.IsThrottledOnDatabaseSize);
                Console.WriteLine("Throttled On DB Reads: {0}", throttlingCode.IsThrottledOnDataRead);
                Console.WriteLine("Throttled On DB Free space: {0}", throttlingCode.IsThrottledOnDataSpace);
                Console.WriteLine("Throttled On Log Free Size: {0}", throttlingCode.IsThrottledOnLogSpace);
                Console.WriteLine("Throttled On Log Writes: {0}", throttlingCode.IsThrottledOnLogWrite);
                Console.WriteLine("Throttled On Worker Threads: {0}", throttlingCode.IsThrottledOnWorkerThreads);
                
                Console.WriteLine("\nThrottled resources:");

                foreach (var res in throttlingCode.ThrottledResources)
                {
                   if (res.Item2 != ThrottlingType.None) Console.ForegroundColor = ConsoleColor.Red;
                    Console.WriteLine("Resource type {0} is throttled on {1}", res.Item1, res.Item2);
                    if (res.Item2 != ThrottlingType.None) Console.ResetColor();
                }
            }
            else
            {
                Console.WriteLine("Sorry, but the input you provided does not seem to be a valid number.");
            }
            Console.Read();
        }
    }
}

Il gateway TDS del database SQL esegue nuovi tentativi di connessione per circa 30 secondi prima di segnalare un errore. Se si prevede un volume elevato di traffico di applicazioni, creare la logica di ripetizione tentativi nell'applicazione. Se una connessione ha esito negativo, effettuare le operazioni indicate di seguito.

  • Gestire le disconnessioni temporanee e per inattività.

    noteNota
    Installare l'aggiornamento dell'affidabilità 1 per .NET Framework 4 per correggere il problema relativo a SqlClient che restituisce connessioni inattive all'applicazione. Con questo aggiornamento, SqlClient verifica se la connessione nel pool è inattiva prima di restituirla all'applicazione. Se la connessione è inattiva, SqlClient si riconnette prima di restituirla all'applicazione. Per altre informazioni su questo problema, vedere Riduzione al minimo degli errori del pool di connessioni nel database SQL.

  • Provare a eseguire una nuova connessione al database SQL in intervalli di 10 secondi finché le risorse non saranno disponibili e la connessione non verrà ristabilita. A seconda dell'applicazione, dei database e del carico di lavoro della rete, potrebbe essere necessario aumentare il tempo di ritardo.

  • Modificare il carico di lavoro se una connessione viene nuovamente terminata. Se una connessione viene nuovamente terminata, esaminare il codice di errore, individuare il problema reale e tentare di modificare il carico di lavoro. È possibile implementare una coda o un meccanismo di ritardo nell'applicazione client per ridurre il carico di lavoro.

    Un'altra soluzione potrebbe essere rappresentata da una nuova progettazione dell'applicazione e del database per rimuovere colli di bottiglia di risorse. Verificare che un numero eccessivo di operazioni DDL o DML da parte dell'applicazione non determini un overload del database tempdb. Accertarsi inoltre che le transazioni non blocchino alcuna risorsa. Laddove appropriato, valutare l'opportunità di eseguire il partizionamento del database in più unità minori.

  • Assicurarsi che il codice possa correggere la limitazione. Gli utenti devono presupporre che le connessioni possano disconnettersi in qualsiasi momento in un'applicazione. È pertanto opportuno effettuare una richiesta batch in una singola transazione laddove possibile. In questo modo si ridurranno le probabilità per cui un batch potrebbe completarsi parzialmente e impostare il database su uno stato imprevisto/non testato. A tale scopo, è consigliabile eseguire BEGIN TRANS/COMMIT TRANS per ogni batch ad hoc e all'inizio e alla fine di ogni stored procedure.

  • Comprendere in che modo la logica di ripetizione tentativi influisce sulla precisione di un'applicazione (idempotenza). In fase di esecuzione di aggiornamenti o inserimenti è importante sapere cosa accade se una connessione viene disconnessa prima del completamento. Se la transazione viene interrotta, la prima azione da eseguire consiste nel tentare una nuova connessione. Se invece viene eseguito il commit della transazione, una nuova esecuzione potrebbe costituire una scelta non corretta. Gli utenti che eseguono modifiche non idempotenti potrebbe dover modificare lo schema di database logico per poter rilevare commit ripetuti di transazioni in base alla logica di ripetizione tentativi utilizzata per evitare disconnessioni.

Utilizzare il codice tentativi per registrare errori di limitazione in modo da distinguere situazioni di connessione temporanea, limitazione, errori gravi di sintassi, stored procedure mancanti e così via. Questa condizione risulta particolarmente utile in scenari di risoluzione dei problemi se non si è in grado di connettersi al database SQL. In questo caso i tentativi di risoluzione dei problemi si concentreranno sulle informazioni registrate e la capacità di risolvere i problemi sarà correlata alla qualità delle informazioni registrate. Per altre informazioni sull'implementazione della registrazione nelle applicazioni del database SQL, vedere Implementazione della registrazione per le applicazioni del database SQL di Azure.

Vedere anche

Mostra:
© 2015 Microsoft