Cette erreur se produit lorsque Microsoft® SQL Server™ rencontre un interblocage. Un interblocage se produit lorsque deux processus (ou plus) tentent d'accéder à une ressource pour laquelle l'autre processus a défini un verrou. Étant donné que chaque processus contient une demande pour une autre ressource, aucun processus ne peut se terminer. Lorsqu'un blocage est détecté, SQL Server annule la commande dont la durée de traitement est la plus faible et renvoie le message d'erreur 1205 à l'application cliente. Cette erreur n'est pas irrécupérable et ne peut pas provoquer la fin du lot.
Solutions
Dans certains cas, une condition de blocage peut être à l'origine du renvoi de FAIL par la fonction DB-Library (dbsqlexec, dbsqlok, dbresults ou dbnextrow). Le programme doit toujours vérifier les codes de retour de chaque fonction DB-Library. Si FAIL est renvoyé par l'une de ces fonctions DB-Library, le programme doit annuler le lot et ne doit pas essayer de continuer. Dans certains cas, il est possible de continuer l'exécution des autres fonctions du lot. Cependant, étant donné qu'une situation de blocage est survenue et que les fonctions l'ayant provoquée ont été annulées, les fonctions ultérieures du traitement par lots risquent fortement d'échouer avec une erreur plus grave, par exemple « Objet introuvable ».
Dans d'autres cas, une condition de blocage ne provoquera pas le renvoi de FAIL par une fonction DB-Library. Dans ces cas, le programme doit vérifier si le gestionnaire de messages contient le message d'erreur 1205 et utiliser la fonction dbsetuserdata pour le communiquer à l'application. Le programme doit ensuite vérifier l'indicateur de blocage après chaque appel de fonction DB-Library et annuler le traitement par lots si un blocage est détecté.
Il a beau sembler inutile d'annuler un traitement par lots après avoir reçu un message de blocage 1205, cela est néanmoins nécessaire car le serveur n'arrête pas toujours le traitement par lots dans une situation de blocage. Si le traitement par lots n'est pas annulé, toute tentative d'envoi d'un nouveau lot peut se terminer par l'erreur DB-Library 10038 « Résultats en attente ».
Vous pouvez également utiliser l'instruction SET DEADLOCK_PRIORITY (LOW ou NORMAL). SET DEADLOCK_PRIORITY contrôle la réaction de la session en cas de blocage. Avec LOW, le processus sera la victime privilégiée d'un blocage. Avec NORMAL, la session utilisera la méthode par défaut de traitement des blocages.
Lorsqu'un blocage n'est pas résolu, il s'avère souvent utile d'utiliser l'indicateur de trace 1204 pour collecter plus d'informations. L'indicateur de trace 1204 imprime les chaînes et la victime du blocage, comme indiqué dans l'exemple de résultat :
Ces informations de blocage peuvent être interprétées comme suit :
La première section indique la victime et l'heure du blocage, ainsi que les sessions concernées. Pour chaque session, le SPID en cours, le type d'instruction et une partie du tampon d'entrée sont affichés.
La deuxième section contient des détails sur les verrous impliqués dans le blocage. Dans le résultat ci-dessus, notez que le blocage concerne des verrous de clé dans la table t1, index i1. Le résultat du blocage indique les processus qui détiennent les verrous impliqués dans le blocage et les sessions en attente des verrous devant être octroyés ainsi que les modes de verrouillage associés.
Le processus ayant généré le moins de données dans le journal sera, par défaut, choisi comme victime du blocage et sera annulé automatiquement. Pour influencer la restauration de session, définissez DEADLOCK_PRIORITY pour une session.
Home
FRA