Exporter (0) Imprimer
Développer tout

Limitation associée à Base de données SQL Azure

Mis à jour: juin 2014

Cette rubrique décrit le mécanisme de limitation du moteur, les codes d'erreur associés et la résolution des erreurs que vous pouvez rencontrer.

Le tableau suivant fournit des informations sur le mécanisme de limitation du moteur, le code d'erreur correspondant retourné et des recommandations pour résoudre l'erreur.

 

Mécanisme de limitation du moteur Code d'erreur retourné Recommandation

La limitation du moteur suit les étapes ci-après pour réduire la charge et protéger l'intégrité du système :

  1. Détermine la réduction de charge nécessaire pour rétablir l'intégrité du système.

  2. Marque les bases de données d'abonnés qui consomment trop de ressources en tant que candidates pouvant faire l'objet d'une limitation. Si la limitation du moteur se produit en raison d'un type légèrement dépassé, certaines bases de données sont susceptibles de ne pas être considérées en tant que candidates pouvant faire l'objet d'une limitation. Si la limitation du moteur est due à un type dépassé de manière significative, toutes les bases de données d'abonnés sont des candidates pouvant faire l'objet d'une limitation, à l'exception des bases de données d'abonnés qui n'ont pas reçu de charge au cours du cycle de limitation qui précède le cycle de limitation actuel.

  3. Calcule le nombre de bases de données candidates devant être limitées pour rétablir l'intégrité du système en évaluant les modèles d'utilisation des ressources d'historique des bases de données candidates.

  4. Limite le nombre calculé de bases de données candidates jusqu'à ce que la charge du système soit revenue au niveau souhaité. Selon qu'il s'agisse d'une limitation matérielle ou d'une limitation logicielle, le niveau de limitation appliqué ou le mode de limitation diffère. Déterminez le niveau et le mode de limitation appliqués à l'aide des valeurs d'ID de l'incident et de code figurant dans le message d'erreur. Les bases de données limitées le sont au minimum pendant la durée d'un cycle de limitation (10 secondes). Cependant, la limitation persiste souvent pendant plusieurs cycles de limitation afin de rétablir l'intégrité du système.

40501 : le service est actuellement occupé. Réessayez la demande après 10 secondes. ID de l'incident : <ID>. Code : <code>.

noteRemarque
Les valeurs ID d'incident et Code permettent de déterminer quelles demandes sont limitées et s'il s'agit d'une limitation logicielle ou matérielle. Pour plus d'informations, consultez les sections « ID d'incident de limitation » et « Décodage des codes de raison » plus loin dans cette rubrique.

Interrompez et renvoyez la demande après 10 secondes.

L'ID d'incident de limitation dans l'erreur 40501 est une valeur de GUID qui identifie de façon unique un incident de limitation.

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

Si vous ne parvenez pas à déterminer pourquoi la limitation s'est produite ou si elle persiste, et vous ne savez pas la résoudre, contactez le support technique Microsoft et indiquez l'ID d'incident (<ID>) dans le message d'erreur. Grâce à cet ID, le support technique de Microsoft peut rassembler des informations en rapport avec l'incident de limitation. L'ID de l'incident permet de rassembler les informations suivantes :

  • L'heure de début de l'incident de limitation.

  • Le type de limitation (logicielle ou matérielle).

  • Le type de ressource (UC, par exemple) en raison duquel survient l'incident de limitation.

  • Les applications en cours d'exécution au moment de cet incident de limitation.

Une fois que le support technique Microsoft vous a appris la cause sous-jacente du problème, apportez les modifications appropriées à votre application.

Cette section décrit comment décoder les codes de raison renvoyés par le code d'erreur de limitation du moteur suivant :

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

Le code de raison (<code>) dans le message d'erreur est un nombre décimal qui contient des informations sur le mode de limitation et les types de ressources dépassés.

  • Le mode de limitation énumère les types d'instructions rejetés.

  • Le type de ressource spécifie les ressources dépassées. La limitation peut se produire simultanément sur plusieurs types de ressources, tels que le processeur et les E/S.

Examinez l'exemple de message d'erreur suivant, où le code de raison est 131075 :

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

Le diagramme suivant explique comment décoder les codes de raison.

Décodage des codes de raison

Pour obtenir le mode de limitation, appliquez le modulo 4 au code de raison. L'opération modulo renvoie le reste d'un nombre divisé par un autre. Pour obtenir le type de limitation et le type de ressource, divisez le code de raison par 256 comme illustré à l'étape 1. Convertissez ensuite le quotient du résultat en son équivalent binaire, comme expliqué aux étapes 2 et 3. Le diagramme répertorie tous les types de limitations et les types de ressources. Comparez votre type de limitation avec les bits de type de ressource, comme illustré dans le diagramme.

Le tableau suivant fournit une liste des modes de limitation.

 

Code de mode de limitation Description Types d'instructions rejetés Instructions qui peuvent encore être traitées

0

Aucune limitation

Aucune

Tous

1

Rejeter les mises à jour / insertion

INSERT, UPDATE, CREATE TABLE | INDEX

DELETE, DROP TABLE | INDEX, TRUNCATE

2

Rejeter toutes les écritures

INSERT, UPDATE, DELETE, CREATE, DROP

SÉLECTIONNER

3

Rejeter tout

Tous

Aucune

Pour obtenir le mode de limitation, appliquez le modulo 4 au code de raison. 131075 % 4 = 3. Le résultat 3 signifie que le mode de limitation est « Rejeter tout ».

Pour obtenir le type de limitation et le type de ressource, divisez le code de raison par 256. Convertissez ensuite le quotient du résultat en son équivalent binaire. 131075 / 256 = 512 (décimal) et 512 (décimal) = 10 00 00 00 00 (binaire). Cela signifie que la base de données a été limitée par limitation de processeur (type de ressource 4) et de matériel (10).

L'exemple de code suivant utilise la classe ThrottlingCondition dans le bloc d'd'applications de gestion des erreurs temporaires (également appelé Topaz) dans le pack d'intégration Enterprise Library pour Azure pour décoder le code de raison de l'erreur de limitation du moteur (40501). Pour télécharger les assemblys et le code source du bloc d'applications de gestion des erreurs temporaires de façon à utiliser la classe ThrottlingCondition, consultez Pack d'intégration Enterprise Library 5.0 pour Azure.

Cet exemple de code vous invite à entrer le code de raison obtenu dans l'erreur de limitation du moteur (40501), puis affiche le mode de limitation, le type de limitation et le type de ressource pour le code de raison spécifié.

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();
        }
    }
}

La passerelle TDS Base de données SQL effectue une nouvelle tentative de connexion pendant environ 30 secondes avant de signaler un échec. Si vous prévoyez un trafic d'application élevé, construisez la logique de nouvelle tentative dans votre application. Si une connexion échoue, procédez comme suit :

  • Gérez l'inactivité et les déconnexions temporaires.

    noteRemarque
    Installez Reliability Update 1 pour .NET Framework 4.0 qui résout le problème lié à SqlClient qui retourne des connexions mortes à l'application. Avec cette mise à jour, SqlClient vérifie si la connexion dans le pool est morte avant de la retourner à l'application. Si la connexion est morte, SqlClient la rétablit avant de la retourner à l'application. Pour plus d'informations sur ce problème, consultez la rubrique relative à la réduction des erreurs de pool de connexions dans Base de données SQL.

  • Effectuez une nouvelle tentative de connexion par intervalle de 10 secondes jusqu'à ce que les ressources soient disponibles et que votre connexion soit rétablie. En fonction de l'application, des bases de données et de la charge de travail réseau, vous devez augmenter le délai.

  • Modifiez votre charge de travail si la connexion est de nouveau arrêtée. Dans ce cas, recherchez le code d'erreur, déterminez quel est le problème, puis modifiez votre charge de travail. Implémentez un mécanisme de file d'attente ou de délai dans votre application cliente pour réduire la charge de travail.

    Une autre solution consiste à refondre vos application et base de données de façon à supprimer les goulets d'étranglement des ressources. Veillez à ce que votre application ne surcharge pas tempdb via des opérations DDL ou DML excessives. En outre, assurez-vous que les transactions ne bloquent pas les ressources. Le cas échéant, envisagez de partitionner votre base de données dans plusieurs bases de données.

  • Assurez-vous que le code peut être récupéré après limitation. Les utilisateurs doivent supposer que les connexions peuvent être déconnectées à tout moment dans une application. Par conséquent, autant que possible, exécutez une demande de traitement dans une seule transaction. Cela réduit les cas où un traitement est partiellement achevé et place la base de données dans un état inattendu/non testé. Pour cela, exécutez BEGIN TRANS/COMMIT TRANS autour de chaque traitement ad hoc et au début/à la fin de chaque procédure stockée.

  • Comprenez la façon dont la logique de nouvelle tentative affecte une application (idempotence). Lorsque vous effectuez des opérations de mise à jour ou d'insertion, il est important de comprendre ce qui se produit lorsqu'une connexion est déconnectée avant qu'un indicateur de réussite ne soit retourné. Si la transaction est annulée, il convient d'effectuer une nouvelle tentative de connexion. Si la transaction est validée, le fait de réexécuter la transaction est probablement une opération incorrecte. Les utilisateurs qui apportent des modifications qui ne sont pas idempotentes devront peut-être modifier le schéma de base de données logique pour pouvoir détecter les transactions validées plusieurs fois en fonction de la logique de nouvelle tentative utilisée pour se protéger contre les déconnexions.

Utilisez le code de nouvelle tentative pour consigner les erreurs de limitation, afin de distinguer la syntaxe de connexion temporaire, de limitation et de défaillance matérielle, les procédures stockées manquantes, etc. Cela s'avère particulièrement utile dans des scénarios de dépannage si vous n'êtes pas en mesure de vous connecter à Base de données SQL. Dans ce cas, les efforts de dépannage sont axés sur les informations consignées et la capacité de résolution est corrélée à la qualité de ces informations. Pour plus d'informations sur l'implémentation de la journalisation dans les applications Base de données SQL, consultez Implémentation de la journalisation pour les applications Base de données SQL Azure.

Voir aussi

Afficher:
© 2014 Microsoft