Partage via

Résoudre les erreurs de connexion temporaires dans SQL Database et SQL Managed Instance

  • Article

S’applique à : Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics

Cet article décrit comment empêcher, résoudre, diagnostiquer et limiter les erreurs de connexion et les erreurs temporaires que votre application cliente rencontre lorsqu’elle interagit avec Azure SQL Database, Azure SQL Managed Instance et Azure Synapse Analytics. Découvrez comment configurer une logique de nouvelle tentative, générer la chaîne de connexion et ajuster les autres paramètres de connexion.

Erreurs temporaires

Une erreur temporaire s’explique par une cause sous-jacente qui se résout d’elle-même en peu de temps. Les erreurs temporaires surviennent de temps en temps lorsque le système Azure réaffecte rapidement des ressources matérielles pour mieux équilibrer les différentes charges de travail. La plupart de ces événements de reconfiguration se terminent en moins de 60 secondes. Durant cette reconfiguration, vous pouvez rencontrer des problèmes de connexion à votre base de données dans SQL Database. Les applications qui se connectent à votre base de données doivent être conçues de sorte à s’attendre à de telles erreurs temporaires. Pour les gérer, implémentez une logique de nouvelle tentative dans leur code au lieu de les exposer aux utilisateurs comme des erreurs d’application.

Si votre programme client utilise ADO.NET, votre programme est informé de l’erreur temporaire par la levée d’une exception SqlException.

Connexion et commande

Retentez la connexion SQL Database et SQL Managed Instance ou rétablissez-la, en fonction de ce qui suit :

  • Une erreur temporaire se produit pendant une tentative de connexion

Retentez la connexion après un délai de quelques secondes.

  • Une erreur temporaire se produit lors d’une commande de requête SQL Database et SQL Managed Instance

Ne retentez pas immédiatement la commande. Établissez plutôt la connexion après un certain délai. Retentez ensuite la commande.

Logique de nouvelle tentative pour les erreurs temporaires

Les programmes clients qui rencontrent occasionnellement une erreur temporaire sont plus solides lorsqu’ils contiennent une logique de nouvelle tentative. Si votre programme communique avec votre base de données dans SQL Database par le biais d’un intergiciel (middleware) tiers, demandez au fournisseur s’il contient une logique de nouvelle tentative pour les erreurs temporaires.

Principes de nouvelle tentative

  • Si l’erreur est temporaire, réessayez d’ouvrir une connexion.
  • Ne retentez pas directement une instruction SELECT SQL Database ou SQL Managed Instance qui a échoué avec une erreur temporaire. Au lieu de cela, établir une nouvelle connexion et relancer l’instruction SELECT.
  • Si une instruction UPDATE SQL Database ou SQL Managed Instance échoue avec une erreur temporaire, établissez une nouvelle connexion avant de retenter l’instruction UPDATE. La logique de nouvelle tentative doit s’assurer que la transaction de base de données est complètement terminée ou que la transaction entière a été annulée.

Autres considérations

  • Un fichier de commandes qui démarre automatiquement après les heures de travail et qui s’achève avant le matin peut se permettre d’attendre très longtemps entre deux tentatives.
  • Un programme d’interface utilisateur doit prendre en compte la tendance qu’ont les hommes à l’abandon en cas d’attente trop longue. La solution ne consiste pas à retenter l’opération à chaque seconde, car une telle stratégie pourrait submerger le système de requêtes.

Augmentation de l’intervalle entre les tentatives

Nous vous recommandons de patienter 5 secondes avant votre première nouvelle tentative. Si vous effectuez une nouvelle tentative avant 5 secondes, vous risquez de submerger le service cloud. Pour chaque nouvelle tentative suivante, le délai doit augmenter de manière exponentielle, sans dépasser 60 secondes.

Pour en savoir plus sur la période de blocage des clients qui utilisent ADO.NET, consultez Regroupement de connexions (ADO.NET).

Vous pouvez également définir le nombre maximal de tentatives avant l’arrêt automatique du programme.

Exemples de code avec la logique de nouvelle tentative

Des exemples de code avec logique de nouvelle tentative sont disponibles aux emplacements suivants :

Tester votre logique de nouvelle tentative

Pour tester la logique de nouvelle tentative, vous devez simuler ou provoquer une erreur pouvant être corrigée alors que votre programme est en cours d’exécution.

Test par le biais de la déconnexion du réseau

Pour tester votre logique de nouvelle tentative, vous pouvez déconnecter votre ordinateur client du réseau pendant l’exécution du programme. L’erreur est :

  • SqlException.Number = 11001
  • Message : « Cet hôte est inconnu. »

Dans le cadre de la nouvelle tentative numéro un, vous pouvez reconnecter votre ordinateur client au réseau, puis tenter de vous connecter.

Pour concrétiser ce test, débranchez votre ordinateur du réseau avant lancer votre programme. Votre programme reconnaît alors un paramètre d’exécution qui fait en sorte que le programme :

  • Ajoute temporairement 11001 à sa liste d’erreurs à considérer comme provisoire.
  • Tente sa première connexion comme d’habitude.
  • Une fois l’erreur détectée, supprime 11001 de sa liste.
  • Affiche un message indiquant à l’utilisateur de connecter l’ordinateur au réseau.
  • Suspend toute exécution à l’aide de la méthode Console.ReadLine ou d’une boîte de dialogue contenant un bouton OK. L’utilisateur appuie sur la touche Entrée après la connexion de l’ordinateur au réseau.
  • Essaie de nouveau de se connecter, et attend la réussite.

Teste en fournissant un nom d’utilisateur mal orthographié au moment de la connexion

Votre programme peut délibérément mal orthographier le nom d’utilisateur avant la première tentative de connexion. L’erreur est :

  • SqlException.Number = 18456
  • Message : « Échec de la connexion pour l’utilisateur 'WRONG_MyUserName' »

Dans le cadre de la première nouvelle tentative, votre programme peut corriger les fautes d’orthographe et tenter de se connecter.

Pour mettre ce test en pratique, votre programme reconnaît un paramètre d’exécution, qui fait en sorte que le programme :

  • Ajoute temporairement 18456 à sa liste d’erreurs à prendre en compte comme provisoire.
  • Ajoute volontairement ’WRONG_’ au nom d’utilisateur.
  • Une fois l’erreur détectée, supprime 18456 de la liste.
  • Supprime ’WRONG_’ du nom d’utilisateur.
  • Essaie de nouveau de se connecter, et attend la réussite.

Paramètres de connexion .NET Sql pour les nouvelles tentatives de connexion

Si votre programme client se connecte à votre base de données dans Azure SQL Database à l’aide de la classe .NET Framework System.Data.SqlClient.SqlConnection, utilisez .NET 4.6.1 ou une version ultérieure (ou .NET Core) afin de pouvoir utiliser la fonctionnalité de nouvelle tentative de connexion. Pour plus d’informations sur cette fonctionnalité, consultez Propriété SqlConnection.ConnectionString.

Lorsque vous générez la chaîne de connexion pour votre objet SqlConnection, coordonnez les valeurs entre les paramètres suivants :

  • ConnectRetryCount : la valeur par défaut est 1. La plage s’étend de 0 à 255.
  • ConnectRetryInterval : la valeur par défaut est de 10 secondes. La plage s’étend de 1 à 60.
  • Connection Timeout : la valeur par défaut est de 15 secondes. La plage s’étend de 0 à 2147483647.
  • Command Timeout : la valeur par défaut est de 30 secondes. La plage s’étend de 0 à 2147483647.

Les paramètres de nouvelle tentative de connexion (ConnectRetryCount et ConnectRetryInterval) s’appliquent à la résilience de connexion. La résilience de connexion inclut les types distincts suivants :

  • La résilience des connexions ouvertes fait référence à la méthode SqlConnection.Open ou OpenAsync() initiale. La première tentative de connexion est comptabilisée comme la tentative zéro. ConnectRetryCount s’applique aux nouvelles tentatives suivantes. Par conséquent, si la connexion zéro échoue (cela peut ne pas se produire immédiatement), ConnectRetryInterval est appliqué en premier, avant les tentatives ConnectRetryCount (et ConnectRetryInterval). Pour que toutes les nouvelles tentatives possibles puissent avoir lieu, la propriété Connexion Timeout doit laisser du temps pour chacune d’elles.

  • La résilience des connexions inactives fait référence à la détection et la reconnexion automatiques des connexions inactives existantes qui ont été interrompues. La première tentative de reconnexion d’une connexion inactive interrompue est comptabilisée comme la première nouvelle tentative. Pour que toutes les nouvelles tentatives possibles puissent avoir lieu, Command Timeout doit laisser du temps pour chacune d’elles.

Exemple : Supposons les valeurs suivantes pour les paramètres ConnectRetryCount et ConnectRetryInterval :

ConnectRetryCount:  3 ConnectRetryInterval : 10 secondes

Regardez de quelle façon ces valeurs sont utilisées dans les scénarios suivants :

Scénario : Nouvelle connexion

4:10:00 - Connection.Open() - tentative zéro

4:10:01 - Échec de connexion détecté

4:10:11 - Nouvelle tentative 1 --> La première nouvelle tentative se produit après ConnectRetryInterval

4:10:21 - Nouvelle tentative 2

4:10:31 - Nouvelle tentative 3

Pour ce scénario, les valeurs que vous choisissez doivent satisfaire à la condition suivante :
Connection Timeout > = ConnectRetryCount * ConnectionRetryInterval

Par exemple, si le nombre est 3 et que l’intervalle est de 10 secondes, un délai d’expiration de 29 secondes seulement ne laisse pas suffisamment de temps au système pour faire une troisième et dernière nouvelle tentative de connexion :

29 < 3 * 10

Scénario : Connexion inactive

ConnectRetryCount:  3 ConnectRetryInterval : 10 secondes

4:10:00 - Connexion interrompue détectée à l’exécution de la commande

4:10:00 - Nouvelle tentative 1 -->Nouvelle tentative immédiate

4:10:10 - Nouvelle tentative 2

4:10:20 - Nouvelle tentative 3

Il ne s’agit pas de la connexion initiale. Par conséquent, Connection Timeout ne s’applique pas. Toutefois, étant donné que la récupération de la connexion a lieu durant l’exécution de la commande, le paramètre Command Timeout s’applique. La valeur par défaut de Command Timeout est de 30 secondes. La récupération de la connexion est habituellement rapide, mais une panne intermittente peut ralentir la récupération et impacter ainsi la durée d’exécution de la commande.

Pour ce scénario, si vous souhaitez permettre toutes les nouvelles tentatives de récupération de la connexion inactive, les valeurs que vous choisissez doivent satisfaire à la condition suivante :
Command Timeout > (ConnectRetryCount - 1) * ConnectionRetryInterval

Par exemple, si le nombre est 3 et que l’intervalle est de 10 secondes, une valeur de délai d’expiration de commande inférieure à 20 secondes ne laissera pas suffisamment de temps pour faire la troisième et dernière nouvelle tentative de connexion : (3 - 1) * 10 = 20'

De plus, n’oubliez pas que la commande elle-même a besoin de temps pour s’exécuter une fois la connexion récupérée.

Notes

Les valeurs de durée fournies dans ces scénarios servent uniquement à des fins de démonstration. Les temps de détection réels dans les deux scénarios dépendent de l’infrastructure sous-jacente.

Connexion et commande

Les paramètres ConnectRetryCount et ConnectRetryInterval permettent à votre objet SqlConnection de recommencer l’opération de connexion sans notification à votre programme ou renvoi du contrôle à celui-ci. Les nouvelles tentatives peuvent se produire dans les situations suivantes :

  • Appel de la méthode SqlConnection.Open
  • Appel de la méthode SqlConnection.Execute

Il existe une subtilité. Si une erreur temporaire se produit pendant l’exécution de votre requête, votre objet SqlConnection ne retente pas l’opération de connexion. Il ne relance certainement pas votre requête. Toutefois, SqlConnection vérifie très rapidement la connexion avant d’envoyer votre requête pour exécution. Si la vérification rapide détecte un problème de connexion, SqlConnection réessaye l’opération de connexion. Si la nouvelle tentative réussit, votre requête est envoyée pour exécution.

Le paramètre ConnectRetryCount doit-il être combiné avec la logique de nouvelle tentative d’application

Supposons que votre application possède une logique de nouvelle tentative personnalisée robuste. Elle peut réessayer l’opération de connexion quatre fois. Si vous ajoutez ConnectRetryInterval et ConnectRetryCount = 3 à votre chaîne de connexion, vous augmentez le nombre de nouvelles tentatives à 4 * 3, soit 12 nouvelles tentatives. Vous ne souhaitez peut-être pas un si grand nombre de nouvelles tentatives.

Connexions à votre base de données dans SQL Database

Connexion : Chaîne de connexion

La chaîne de connexion nécessaire pour vous connecter à votre base de données est légèrement différente de la chaîne utilisée pour se connecter à SQL Server. Il est possible de copier la chaîne de connexion de votre base de données à partir du portail Azure.

Obtenir la chaîne de connexion sur le portail Azure

Utilisez le portail Azure pour obtenir la chaîne de connexion nécessaire pour que votre programme client interagisse avec Azure SQL Database.

  1. Sélectionnez Tous les services>Bases de données SQL.

  2. Saisissez le nom de votre base de données dans la zone de texte du filtre située en haut à gauche du volet des bases de données SQL.

  3. Sélectionnez la ligne qui correspond à votre base de données.

  4. Une fois que le volet de votre base de données s’affiche, pour un meilleur confort visuel, sélectionnez les boutons de réduction afin de réduire les panneaux que vous avez utilisés pour la navigation et le filtrage de la base de données.

  5. Dans le volet de votre base de données, sélectionnez Afficher les chaînes de connexion aux bases de données.

  6. Copiez la chaîne de connexion appropriée. Par exemple, si vous prévoyez d’utiliser la bibliothèque de connexions ADO.NET, copiez la chaîne appropriée de l’onglet ADO.NET.

    Copier la chaîne de connexion ADO pour votre base de données

  7. Modifiez la chaîne de connexion si nécessaire. Par exemple, insérez votre mot de passe dans la chaîne de connexion, ou supprimez « @<nom_serveur> » à partir du nom d’utilisateur si le nom du serveur ou de l’utilisateur est trop long.

  8. Dans le format de votre choix, collez les informations de chaîne de connexion dans votre code de programme client.

Pour plus d’informations, consultez Connection strings and configuration files (Chaînes de connexion et fichiers de configuration).

Connexion : Adresse IP

Vous devez configurer SQL Database pour accepter les communications à partir de l’adresse IP de l’ordinateur qui héberge votre programme client. Pour définir cette configuration, modifiez les paramètres du pare-feu via le portail Azure.

Si vous oubliez de configurer l’adresse IP, votre programme échoue en envoyant un message d’erreur pratique indiquant l’adresse IP nécessaire.

  1. Connectez-vous au portail Azure.

  2. Dans la liste de gauche, sélectionnez Tous les services.

  3. Faites défiler l’écran, puis sélectionnez Serveurs SQL.

    Rechercher votre serveur Azure SQL Database sur le portail

  4. Dans la zone de texte de filtre, tapez les premières lettres du nom de votre serveur. La ligne correspondante s’affiche.

  5. Sélectionnez la ligne de votre serveur. Un volet dédié à votre serveur s’affiche.

  6. Dans le volet serveur, sélectionnez Paramètres.

  7. Sélectionnez Pare-feu.

    Sélectionnez Paramètres > Pare-feu

  8. Sélectionnez Ajouter une adresse IP cliente. Dans la première zone de texte, tapez un nom pour votre nouvelle règle.

  9. Tapez les valeurs d’adresse IP basse et haute de la plage que vous souhaitez autoriser.

    • Pour des raisons pratiques, vous pouvez terminer les valeurs basses par .0 et les valeurs hautes par .255.

  10. Sélectionnez Enregistrer.

Pour plus d’informations, consultez Configurer les paramètres du pare-feu dans SQL Database.

Connexion : Ports

En règle générale, vous devez simplement vous assurer que le port 1433 est ouvert pour la communication sortante sur l’ordinateur qui héberge le programme client.

Par exemple, lorsque votre programme client est hébergé sur un ordinateur Windows, vous pouvez utiliser le pare-feu Windows sur l’hôte pour ouvrir le port 1433.

  1. Ouvrez le Panneau de configuration.
  2. Sélectionnez Tous les éléments du Panneau de configuration>Pare-feu Windows>Paramètres avancés>Règles de trafic sortant>Actions>Nouvelle règle.

Si votre programme client est hébergé sur une machine virtuelle Azure, lisez Ports au-delà de 1433 pour ADO.NET 4.5 et SQL Database.

Pour obtenir des informations générales sur la configuration des ports et des adresses IP dans votre base de données, consultez Pare-feu Azure SQL Database.

Connexion : ADO.NET 4.6.2 ou version ultérieure

Si votre programme utilise des classes ADO.NET comme System.Data.SqlClient.SqlConnection pour se connecter à SQL Database, nous vous recommandons d’utiliser .NET Framework version 4.6.2 ou ultérieure.

À compter d’ADO.NET 4.6.2

  • Une nouvelle tentative d’ouverture de connexion est effectuée immédiatement pour Azure SQL, ce qui améliore les performances des applications compatibles avec le cloud.

À compter d’ADO.NET 4.6.1

  • Pour SQL Database, l’ouverture d’une connexion à l’aide de la méthode SqlConnection.Open en améliore la fiabilité. La méthode Open intègre désormais de meilleurs mécanismes de nouvelle tentative en réponse à des défaillances temporaires, pour certaines erreurs se produisant avant le délai d’expiration de la connexion.
  • Le regroupement de connexions est pris en charge, ce qui contribue à garantir que l’objet de connexion qu’il donne à votre programme fonctionne.

Si vous utilisez un objet de connexion provenant d’un pool de connexions, nous vous recommandons de faire en sorte que votre programme interrompe temporairement la connexion lorsque vous ne l’utilisez pas immédiatement. Il n’est pas coûteux de rouvrir une connexion, ce qui n’est pas le cas de la création d’une connexion.

Si vous utilisez ADO.NET 4.0 ou version antérieure, nous vous recommandons d’effectuer une mise à niveau vers la dernière version d’ADO.NET. Depuis août 2018, ADO.NET 4.6.2 est disponible au téléchargement.

Diagnostics

Diagnostics : vérifier si les utilitaires peuvent se connecter

Si votre programme ne parvient pas à se connecter à votre base de données SQL Database, une option de diagnostic consiste à essayer de se connecter avec un programme utilitaire. Dans l’idéal, l’utilitaire se connecte à l’aide de la bibliothèque que votre programme utilise.

Sur un ordinateur Windows, vous pouvez essayer ces utilitaires :

  • SQL Server Management Studio (ssms.exe), qui se connecte à l’aide d’ADO.NET
  • sqlcmd.exe, qui se connecte en utilisant ODBC

Une fois votre programme connecté, faites un test avec une courte requête SQL SELECT.

Diagnostics : vérifier les ports ouverts

Si vous pensez que les tentatives de connexion échouent en raison de problèmes de port, vous pouvez exécuter un utilitaire sur votre ordinateur pour obtenir des rapports sur les configurations de port.

Sur Linux, les utilitaires suivants peuvent vous être utiles :

  • netstat -nap
  • nmap -sS -O 127.0.0.1: Modifiez la valeur de l’exemple pour refléter votre adresse IP.

Sur Windows, l’utilitaire PortQry.exe peut s’avérer utile. Voici un exemple d’exécution qui a demandé l’état d’un port sur une base de données dans SQL Database et qui a été exécuté sur un ordinateur portable :

[C:\Users\johndoe\]
>> portqry.exe -n johndoesvr9.database.windows.net -p tcp -e 1433

Querying target system called: johndoesvr9.database.windows.net

Attempting to resolve name to IP address...
Name resolved to 23.100.117.95

querying...
TCP port 1433 (ms-sql-s service): LISTENING

[C:\Users\johndoe\]
>>

Diagnostics : Consigner les erreurs

Un problème intermittent est parfois mieux diagnostiqué par la détection d’une tendance générale observée sur plusieurs jours ou semaines.

Votre client peut aider à consigner toutes les erreurs qu’il rencontre un diagnostic. Vous pouvez mettre en corrélation les entrées de journal d’activité avec des informations sur les erreurs de base consignées en interne par SQL Database lui-même.

Enterprise Library 6 (EntLib60) offre des classes .NET gérées afin de faciliter la journalisation. Pour en savoir plus, voir 5 - Un jeu d’enfants : utilisation du bloc d’application de journalisation.

Diagnostics : examiner les journaux d’activité d’erreur système

Voici quelques instructions Transact-SQL SELECT qui permettent d’interroger les journaux d’activité d’erreur et d’autres informations.

Interrogation de journaux Description
SELECT e.*
FROM sys.event_log AS e
WHERE e.database_name = 'myDbName'
AND e.event_category = 'connectivity'
AND 2 >= DateDiff
  (hour, e.end_time, GetUtcDate())
ORDER BY e.event_category,
  e.event_type, e.end_time;		 La vue sys.event_log propose des informations sur les événements individuels, notamment ceux qui peuvent causer des erreurs temporaires ou des problèmes de connectivité.

Dans l’idéal, vous pouvez mettre en corrélation les valeurs start_time ou end_time avec les informations indiquant quand votre programme client a rencontré des problèmes.

Vous devez vous connecter à la base de données MASTER pour exécuter cette requête.
SELECT c.*
FROM sys.database_connection_stats AS c
WHERE c.database_name = 'myDbName'
AND 24 >= DateDiff
  (hour, c.end_time, GetUtcDate())
ORDER BY c.end_time;		 La vue sys.database_connection_stats agrège des nombres de différents types d’événements, pour permettre des diagnostics supplémentaires.

Vous devez vous connecter à la base de données MASTER pour exécuter cette requête.

Diagnostics : rechercher les événements liés aux problèmes dans le journal de SQL Database

Vous pouvez rechercher des entrées sur les problèmes survenus dans le journal de SQL Database. Essayez l’instruction Transact-SQL SELECT qui suit dans la base de données MASTER :

SELECT
   object_name
  ,CAST(f.event_data as XML).value
      ('(/event/@timestamp)[1]', 'datetime2')                      AS [timestamp]
  ,CAST(f.event_data as XML).value
      ('(/event/data[@name="error"]/value)[1]', 'int')             AS [error]
  ,CAST(f.event_data as XML).value
      ('(/event/data[@name="state"]/value)[1]', 'int')             AS [state]
  ,CAST(f.event_data as XML).value
      ('(/event/data[@name="is_success"]/value)[1]', 'bit')        AS [is_success]
  ,CAST(f.event_data as XML).value
      ('(/event/data[@name="database_name"]/value)[1]', 'sysname') AS [database_name]
FROM
  sys.fn_xe_telemetry_blob_target_read_file('el', null, null, null) AS f
WHERE
  object_name != 'login_event'  -- Login events are numerous.
  and
  '2015-06-21' < CAST(f.event_data as XML).value
        ('(/event/@timestamp)[1]', 'datetime2')
ORDER BY
  [timestamp] DESC
;

quelques-unes d’entre elles ont renvoyé des lignes de sys.fn_xe_telemetry_blob_target_read_file

L’exemple suivant montre à quoi peut ressembler une ligne retournée. Les valeurs null indiquées ne sont en général pas nulles dans d’autres lignes.

object_name                   timestamp                    error  state  is_success  database_name

database_xml_deadlock_report  2015-10-16 20:28:01.0090000  NULL   NULL   NULL        AdventureWorks

Enterprise Library 6

Enterprise Library 6 (EntLib60) est une infrastructure de classes .NET qui vous permet d’implémenter des clients de cloud fiables, notamment SQL Database. Pour rechercher des rubriques dédiées à chaque zone dans laquelle EntLib60 peut être utile, consultez Enterprise Library 6.

La logique de nouvelle tentative pour la gestion des erreurs temporaires est un domaine où EntLib60 peut être utile. Pour plus d’informations, voir 4 - Perseverance, Secret of All Triumphs: Use the Transient Fault Handling Application Block.

Notes

Le code source pour EntLib60 est publiquement disponible par téléchargement depuis le Centre de téléchargement. Microsoft ne prévoit pas d’apporter des mises à jour de maintenance ou de fonctionnalité supplémentaires à EntLib.

Classes EntLib60 pour les erreurs temporaires et les nouvelles tentatives

Les classes EntLib60 suivantes sont particulièrement utiles pour la logique de nouvelle tentative. Toutes ces classes se trouvent dans ou sous l’espace de noms Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.

Dans l’espace de noms Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling :

  • Classe RetryPolicy
    • ExecuteAction
  • ExponentialBackoff
  • SqlDatabaseTransientErrorDetectionStrategy
  • Classe ReliableSqlConnection
    • ExecuteCommand

Dans l’espace de noms Microsoft.Practices.EnterpriseLibrary.TransientFaultHandling.TestSupport:

  • AlwaysTransientErrorDetectionStrategy
  • NeverTransientErrorDetectionStrategy

Voici quelques liens vers des informations sur EntLib60 :

EntLib60 : le bloc de journalisation

  • Le bloc de journalisation est une solution très flexible et configurable qui vous permet de :
    • Créer et stocker des messages du journal dans de nombreux emplacements.
    • Classer et filtrer les messages.
    • Recueillir des informations contextuelles utiles pour le débogage et le suivi, ainsi que pour les exigences d’audit et de journalisation en général.
  • Le bloc de journalisation extrait les fonctionnalités issues de la destination de journalisation de façon que le code d’application soit cohérent, quels que soient l’emplacement et le type du magasin de journalisation cible.

Pour en savoir plus, voir 5 - Un jeu d’enfants : utilisation du bloc d’application de journalisation.

Code source de la méthode EntLib60 IsTransient

Ensuite, à partir de la classe SqlDatabaseTransientErrorDetectionStrategy, le code source C# pour la méthode IsTransient. Le code source clarifie les erreurs considérées comme temporaires qui peuvent faire l’objet de nouvelles tentatives.

public bool IsTransient(Exception ex)
{
  if (ex != null)
  {
    SqlException sqlException;
    if ((sqlException = ex as SqlException) != null)
    {
      // Enumerate through all errors found in the exception.
      foreach (SqlError err in sqlException.Errors)
      {
        switch (err.Number)
        {
            // SQL Error Code: 40501
            // The service is currently busy. Retry the request after 10 seconds.
            // Code: (reason code to be decoded).
          case ThrottlingCondition.ThrottlingErrorNumber:
            // Decode the reason code from the error message to
            // determine the grounds for throttling.
            var condition = ThrottlingCondition.FromError(err);

            // Attach the decoded values as additional attributes to
            // the original SQL exception.
            sqlException.Data[condition.ThrottlingMode.GetType().Name] =
              condition.ThrottlingMode.ToString();
            sqlException.Data[condition.GetType().Name] = condition;

            return true;

          case 10928:
          case 10929:
          case 10053:
          case 10054:
          case 10060:
          case 40197:
          case 40540:
          case 40613:
          case 40143:
          case 233:
          case 64:
            // DBNETLIB Error Code: 20
            // The instance of SQL Server you attempted to connect to
            // does not support encryption.
          case (int)ProcessNetLibErrorCode.EncryptionNotSupported:
            return true;
        }
      }
    }
    else if (ex is TimeoutException)
    {
      return true;
    }
    else
    {
      EntityException entityException;
      if ((entityException = ex as EntityException) != null)
      {
        return this.IsTransient(entityException.InnerException);
      }
    }
  }

  return false;
}

Étapes suivantes