Problème d'interblocage dû à un verrou de mise à jour

Question

Nous avons un problème d'interblocage que nous essayons de détecter. J'ai un graphe de blocage (xdl) généré à partir de Profiler. Il montre l'instruction SQL perdue comme une instruction Select simple, pas une instruction Update, Delete ou Insert. Le graphique montre l'instruction Select perdue comme demandant un verrou partagé sur une ressource **but also owning an Update lock on a resource**. C'est ce qui me déconcerte. Pourquoi une instruction Select qui ne fait pas partie d'une insertion, d'une mise à jour ou d'une suppression contient-elle un verrou de mise à jour sur une ressource?

Je dois ajouter que le verrou de mise à jour qu'il possède est sur la table qui est sélectionnée par l'instruction Select perdante.

EDIT: Veuillez ne pas suggérer d'utiliser NoLock. Oui cela résoudrait le problème mais en introduit un nouveau - un problème de lecture sale. Cette requête frappe un serveur de production. Ce que je veux vraiment savoir, c'est pourquoi une instruction Select émet un verrou de mise à jour. Une instruction select crée un verrou partagé.

Answer 1

Vous êtes sûr que le SELECT possède le verrou U? Comme vous le savez, les verrous U et X (ainsi que les verrous S sérialisables) sont conservés pendant la durée de la transaction , et non l'instruction. Il est donc parfaitement possible qu'une transaction qui a émis une écriture possède un verrou U, à partir d'une instruction précédemment exécutée. Pourquoi posséder un verrou U, par opposition à un verrou X (c'est-à-dire qu'il possède un verrou U qui n'a pas été mis à niveau vers un X) est un peu un casse-tête en soi, mais je peux envisager deux façons se produire.
Il est donc parfaitement possible d'avoir une instruction SELECT pour posséder des verrous X/U si cela fait partie d'une transaction à plusieurs instructions. Un SELECT autonome avec un verrou en U sous sa ceinture, c'est un peu inhabituel, je pense.

L'interblocage SELECT ou UPDATE typique se produit sur les scénarios d'ordre d'accès à l'index, comme celui décrit dans Read/Write deadlock. Je crois que vous avez fait une lecture assidue du graphique de l'impasse, mais si ce n'est pas trop demander, pouvez-vous le partager?

Oh, et btw, avez-vous considéré l'instantané en lecture anticipée?

Answer 2

essayez de sélectionner avec l'indice nolock. Cela résoudrait le problème.

par exemple select * from table (nolock)

Answer 3

Peut-être que la sélection a été appelé avec UPDLOCK? Quoi qu'il en soit, pouvez-vous utiliser l'isolation des clichés et éliminer le problème?