Un interblocage de la transaction s'est produit sur les ressources avec un autre processus. Elle a été choisie comme victime de l'interblocage. Réexécutez la transaction

Résumé

Cette erreur se produit quand Microsoft® SQL Server™ rencontre un interblocage. Un interblocage se produit quand deux processus (ou plus) tentent d'accéder à une ressource pour laquelle l'autre processus détient un verrou. Étant donné que chaque processus a une demande pour une autre ressource, aucun processus ne peut se terminer. Quand un interblocage est détecté, SQL Server annule la commande dont la durée de traitement est la plus courte et retourne 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 d'interblocage 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 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 fonctions suivantes du lot. Cependant, étant donné qu'une situation d'interblocage est survenue et que les fonctions qui l'ont provoquée ont été annulées, les fonctions ultérieures du traitement par lots risquent fortement d'échouer avec une erreur plus grave, comme « 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é.

Si cela peut sembler inutile d'annuler un traitement par lots après avoir reçu un message d'interblocage 1205, c'est néanmoins nécessaire car le serveur n'arrête pas toujours le traitement par lots dans une situation d'interblocage. 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 :

*** Interblocage détecté *** == Processus 7 choisi comme victime de l'interblocage == Interblocage détecté à : 1998-09-10 16:39:29.17 == Informations sur les sessions impliquées : SPID : 7 ECID : 0 Type d'instruction : UPDATE Tampon d'entrée : update t1 set c1 = c1 where c1 = 2 SPID : 8 ECID : 0 Type d'instruction : UPDATE Tampon d'entrée : update t1 set c1 = c1 where c1 = 1 == Informations sur les verrous d'interblocage impliqués : == Verrou : CLÉ : 2:117575457:1 (010001000000) Base de données : tempdb Table : t1 Index : i1 - Détenu par : SPID 7 ECID 0 Mode "S" - Demandé par : SPID 8 ECID 0 Mode "X" == Verrou : CLÉ : 2:117575457:1 (020002000000) Base de données : tempdb Table : t1 Index : i1 - Détenu par : SPID 8 ECID 0 Mode "S" - Demandé par : SPID 7 ECID 0 Mode "X"

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 l'interblocage. Dans le résultat ci-dessus, notez que le blocage concerne des verrous de clé dans la table t1, index i1. La sortie de l'interblocage montre les processus qui détiennent les verrous impliqués dans l'interblocage et les sessions en attente des verrous devant être octroyés ainsi que les modes de verrouillage associés.

• Par défaut, le processus ayant généré le moins de données dans le journal est choisi comme victime de l'interblocage et est annulé automatiquement. Pour influencer le choix de la session à annuler, définissez DEADLOCK_PRIORITY pour une session.

Paramètres remplaçables