Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à : 
.NET Framework .NET Standard
La logique de nouvelle tentative configurable (CRL) permet à Microsoft.Data.SqlClient de relancer certaines opérations SqlConnection et SqlCommand après des défaillances transitoires. Vous choisissez quelles erreurs comptent, combien de tentatives faire, combien de délais augmentent entre les tentatives, et quelles commandes sont sûres à répéter.
Le CRL est désactivé par défaut. Vous l’activez en assignant un fournisseur à une connexion, une commande, ou les deux. Les deux fournisseurs sont indépendants : attribuer un fournisseur à une connexion ne l’applique pas aux commandes créées à partir de cette connexion.
Note
CRL est disponible chez Microsoft. Data.SqlClient 3.0 et versions ultérieures. Par défaut, c’est SqlConfigurableRetryFactory.CreateNoneRetryProvider, qui ne réessaie pas.
Nouvelles tentatives de la CRL
| Scénario | Attribuer le fournisseur à | Défaillances typiques |
|---|---|---|
| Ouvre une connexion | SqlConnection.RetryLogicProvider | Basculement, limitation du débit, brève indisponibilité de la base de données et défaillances de transport lors de l’établissement de la connexion. |
| Exécuter une commande | SqlCommand.RetryLogicProvider | Échecs de certaines instructions qu'il est possible de répéter en toute sécurité en dehors d'une transaction. |
Pour le catalogue partagé d’erreurs de connexion éligibles à une nouvelle tentative sur SQL Server, Azure SQL Database, Azure SQL Managed Instance, base de données SQL dans Microsoft Fabric, et les pools SQL dédiés dans Azure Synapse Analytics, voir Liste d’erreurs transitoires intégrées.
Choisissez un chemin de configuration
| Tâche | Article |
|---|---|
| Créer et assigner un fournisseur en code | Configurer la logique de réessayage dans SqlClient |
| Comparez les fournisseurs fixes, incrémentals, exponentiels et sans réessai | Fournisseurs de logique de tentative intégrés dans SqlClient |
| Définir les paramètres par défaut à l’échelle de l’application dans un fichier de configuration | Configurez la logique de réessayage SqlClient avec un fichier de configuration |
| Implémentez un intervalle personnalisé, un prédicat d’erreur ou un fournisseur | Créer un fournisseur de tentatives personnalisé pour SqlClient |
Concevoir une politique de réessai sûre
- Ne réessayez que les erreurs susceptibles d’être résolues sans modifier les données d’entrée de l’application.
- Limiter les nouvelles tentatives à la fois par le nombre maximal de tentatives et par le délai maximal. Une boucle de réessai sans limite peut transformer une panne en charge soutenue.
- Considérez
NumberOfTriesle nombre total de tentatives, y compris l’opération initiale. - Ajoutez une temporisation aléatoire afin que de nombreux clients ne réessaient pas simultanément. Les fournisseurs intégrés ajoutent automatiquement de la gigue.
- Réessayez la transaction dans son intégralité, et non pas une seule instruction qu'elle contient. Les fournisseurs de commandes intégrés ne réessaient pas les commandes sur une connexion avec une transaction active.
- Limitez les nouvelles tentatives d’exécution d’une commande aux opérations idempotentes, ou aux opérations protégées par un mécanisme d’idempotence au niveau de l’application.
- Enregistrez l’événement Retrying pour pouvoir distinguer les pannes transitoires récupérées des incidents persistants.
Pour des conseils généraux sur l’architecture, consultez le modèle de nouvelle tentative. Pour les conseils sur les erreurs Azure SQL, voir Erreurs transitoires.
Délais d’attente côté client et reprise sans serveur
Le CRL ne réessaie que les erreurs que le pilote reçoit effectivement. Un délai d’attente côté client se manifeste par l’erreur -2, qui ne figure pas dans la liste intégrée des erreurs transitoires ; les fournisseurs intégrés ne réessaient donc pas une Open() ni une commande qui atteint le délai d’attente côté client.
ConnectTimeout et CommandTimeout doivent être suffisamment longues pour couvrir l’opération à elles seules.
Cette condition est la plus importante pour la couche de calcul Serverless pour Azure SQL Database avec l’auto-pause activée. Une base de données mise en pause automatiquement reprend lors du premier Open(), et la reprise peut prendre de 30 à 60 secondes, voire plus. Augmentez ConnectTimeout à au moins 60 secondes lorsque la cible peut faire une pause automatique. La logique de réessai gère alors les défauts transitoires restants (par exemple 40613, 40197, et 40501) pendant que la base de données est en ligne.