SQL Server : Quand ré-exécuter une requête coté applicatif
Voici une liste de messages (non limitative) qui lorsqu'ils sont rencontrés il est utile de ré exécuter la transaction ou la requête ayant échouée.
-
Message d'erreur 1222
- Lock request time out period exceeded.
- Délai de requête de verrou dépassé.
Ce message ne se produira que si vous avez l'option SET LOCK_TIMEOUT définie dans votre connexion. Celle-ci permet d'abandonner l'acquisition d'un verrou si elle dure plus que le nombre de millisecondes spécifiés. Utile si vous ne voulez pas être bloqué par un processus et être notifié dans l'application et au besoin réessayer plus tard la même requête. Par contre si le serveur est très chargé il n'y aucune garantie que la réexécution de la requête ultérieurement puisse se faire.
-
Message d'erreur 1205
- Transaction (Process ID %d) was deadlocked on %.*ls resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
- La transaction (ID de processus %1!) a été bloquée sur les ressources %2! par un autre processus et a été choisie comme victime. Ré-exécutez la transaction.
Un message classique qui concerne les Deadlocks (inter blocable). SQL Server détecte 2 processus ou plus étant bloqués les uns par les autres, un ou plusieurs de ces processus doit être arrêté par SQL Server pour débloquer les autres. Ce cas est classique et les causes sont nombreuses, peut savent que pour résoudre « « temporairement » le problème, une simple réexécution de la même requêtes quelques secondes plus tard suffit (et on logue la requête pour investiguer par la suite).
-
Message d'erreur 3960
- Snapshot isolation transaction aborted due to update conflict. You cannot use snapshot isolation to access table '%.*ls' directly or indirectly in database '%.*ls' to update, delete, or insert the row that has been modified or deleted by another transaction. Retry the transaction or change the isolation level for the update/delete statement.
- La transaction d'isolement d'instantané a été abandonnée en raison d'un conflit de mise à jour. Vous ne pouvez pas utiliser l'isolement d'instantané pour accéder à la table '%1!' directement ou indirectement dans la base de données '%2!' afin de mettre à jour, de supprimer ou d'insérer la ligne modifiée ou supprimée par une autre transaction. Réexécutez la transaction ou changez le niveau d'isolement pour l'instruction de mise à jour/suppression.
Dans le cas d'une transaction se déroulant dans la niveau d'isolation SNAPSHOT (nouveau à partir de SQL Server 2005), cette erreur se produire si une autre transaction a modifié les données que vous souhaitez vous-même mettre à jour.
Une bonne pratique dans une application sera d'avoir une boucle qui à la suite de la rencontre d'une des erreurs mentionnées précédemment réessayera la même requête, avec un temps d'attente entre chaque boucle. Par exemple, 5 tentative avec 1 seconde d'attente entre chaque. A ce système il serait aussi intéressant de loguer systématiquement les requêtes engendrant des erreurs côté serveur, il est en effet pas très aisé de retrouver l'erreur et les requête impliqué directement depuis SQL Server, l'application ne que mieux faire !
Comme indiqué au début cette liste est non limitative, mais reprend des cas courant .
Bonne exécution…
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :