Toutes les interblocages sont provoqués par une mauvaise requête

Question

"La transaction (ID de processus 63) a été bloquée sur les ressources du tampon de communication avec un autre processus et a été choisie comme victime de l'interblocage. Raisons d'échec possibles: Problèmes avec la requête, propriété "ResultSet" non définie correctement, paramètres non définis correctement ou connexion non établie correctement. "

Cette situation d'impasse peut-elle être provoquée par un processus stocké par proc comme SQL Mail?

Answer 1

Deux tables accédant à la même table en même temps se produisent tout le temps dans une application. Généralement cela ne provoquera pas une impasse. Une impasse se produit généralement lorsque vous dites que le processus A tente de mettre à jour le tableau 1, puis le tableau 2 et le tableau 3, et que le processus B tente de mettre à jour le tableau 3, puis le tableau 1. A 'aura une ressource verrouillée dont le processus' B 'a besoin et le processus' B 'a un processus de ressources' A 'nécessaire. SQL Server détecte cela comme un blocage et renvoie l'un des processus en tant que transaction ayant échoué. En résumé, vous avez deux processus qui tentent de mettre à jour les mêmes tables en même temps, mais pas dans le même ordre. Cela conduira souvent à des blocages.

Un moyen facile de gérer cela dans votre application est de gérer la transaction échouée et simplement ré-exécuter la transaction. Il sera presque toujours exécuté avec succès. Une meilleure solution consiste à s'assurer que vos processus mettent à jour les tables dans le même ordre, autant que possible.

Answer 2

Si une requête select peut obtenir les informations dont elle a besoin à partir d'un index au lieu de la table de base, alors les index manquants sont une autre cause fréquente d'interblocages. il ne sera pas bloqué par des mises à jour/insertions sur la table elle-même

Pour être sûr, utilisez le profileur SQL pour tracer les événements "Deadlock Graph", vous montrera le détail de l'impasse elle-même.

Answer 3

Basé sur this, je ne pense pas que SQL Mail lui-même directement être le coupable. Je dis «directement» parce que je ne sais pas ce que vous faites avec. Toutefois, je suppose SQL Mail est probablement lent par rapport au reste de vos opérations SQL, donc si vous faites beaucoup avec cela, il pourrait indirectement créer un goulot d'étranglement qui mène à un blocage si vous maintenez sur les tables tout en envoyer le message SQL.

Il est difficile de recommander une stratégie spécifique sans avoir trop de détails sur ce que vous faites. En résumé, vous devriez examiner s'il existe un moyen de vous libérer de la dépendance à l'égard de la table, comme l'utilisation de NOLOCK, l'utilisation d'une table temporaire ou d'une table "temporaire" ou simplement le refactoring du SP. c'est faire l'appel.