Problème de verrou de SQL Server 2008

Question

Je me suis retrouvé dans une situation d'interblocage où j'ai du mal à trouver la cause ... Le graphique Deadlock suggère qu'une instruction UPDATE est devenue la victime sur une instruction SELECT ... que l'instruction uPDATE tente d'acquérir un index sur une autre table qui est jamais mentionné dans la déclaration de mise à jour ...

Voici comment mon instruction uPDATE ressemble ...

UPDATE Table set col1 = @P1 where col2 = @P2 

Cette déclaration a acquis une X verrouille l'index col2, mais tente également d'acquérir un index sur une colonne définie dans une autre table qui n'est aucunement liée à l'U Instruction PDATE ...

Et l'instruction SELECT qui a remporté la situation de blocage n'a rien à voir avec la table ou l'index dans l'instruction update mais a essayé d'acquérir un index sur la table dans l'instruction UPDATE. causant finalement le DEADLOCK.

Answer 1

La transaction mise à jour/lock comprendra des choses comme:

• déclenche
• validation de clé étrangère (? Est col1 un fk)
• contraintes de contrôle (sur col1 en utilisant udf)
• vues indexées (qui utilise table.col1 ou table.col2)

L'un de ceux-ci pourrait provoquer un verrouillage de la table apparemment non liée

Answer 2

En plus des autres excellentes réponses, quelque chose à considérer est un select qui acquiert généralement un verrou de lecture partagé, ce qui permet à une série de sélections de maintenir un verrou partagé sur la ressource. L'instruction update peut ne jamais avoir l'opportunité d'obtenir un verrou exclusif. Normalement, le moteur fait un bon travail pour empêcher ce type de famine, mais si vous utilisez la mise à jour dans une transaction avec une autre déclaration (s), cela peut compliquer le problème. Si c'est le cas, donnez plus de détails sur ce qui se passe dans la transaction.