"Transaktion (Prozess-ID 63) wurde bei Sperren | Kommunikationspuffer-Ressourcen mit einem anderen Prozess blockiert und wurde als Deadlock-Opfer ausgewählt. Führen Sie die Transaktion erneut aus." Mögliche Fehlerursachen: Probleme mit der Abfrage, Eigenschaft "ResultSet" nicht korrekt gesetzt, Parameter nicht korrekt gesetzt oder Verbindung nicht korrekt hergestellt. "
Könnte dieser Deadlock durch etwas verursacht werden, das proc wie SQL-Mail verwendet? Oder ist es immer so etwas wie zwei Anwendungen, die gleichzeitig auf dieselbe Tabelle zugreifen?
Zwei Tabellen, die gleichzeitig auf dieselbe Tabelle zugreifen, finden in einer Anwendung die ganze Zeit statt. Im Allgemeinen führt dies nicht zu einem Deadlock. Ein Deadlock tritt normalerweise auf, wenn Sie sagen, dass Prozess 'A' versucht, Tabelle 1 und dann Tabelle 2 und dann Tabelle 3 zu aktualisieren, und Prozess 'B' versucht, Tabelle 3, dann Tabelle 2 und dann Tabelle 1 zu aktualisieren. A 'wird eine Ressource haben, die diesen Prozess' B 'benötigt und Prozess' B 'benötigt einen Ressourcenprozess, den' A 'benötigt. SQL Server erkennt dies als Deadlock und rollt einen der Prozesse als fehlgeschlagene Transaktion zurück.
Die Quintessenz ist, dass Sie zwei Prozesse haben, die versuchen, die gleichen Tabellen zur gleichen Zeit zu aktualisieren, aber nicht in der gleichen Reihenfolge. Dies führt oft zu Deadlocks.
Eine einfache Möglichkeit, dies in Ihrer Anwendung zu handhaben, besteht darin, die fehlgeschlagene Transaktion zu behandeln und die Transaktion einfach erneut auszuführen. Es wird fast immer erfolgreich ausgeführt. Eine bessere Lösung besteht darin, sicherzustellen, dass Ihre Prozesse Tabellen in der gleichen Reihenfolge aktualisieren, so viel wie möglich.
Fehlende Indizes sind eine weitere häufige Ursache für Deadlocks. Wenn eine Select-Abfrage die benötigten Informationen aus einem Index anstelle der Basistabelle abrufen kann, wird sie nicht durch Aktualisierungen / Einfügungen in der Tabelle selbst blockiert.
Um sicher zu gehen, verwenden Sie den SQL-Profiler, um nach "Deadlock Graph" -Ereignissen zu suchen, die Ihnen die Details des Deadlocks selbst zeigen.
Basierend auf diesem , denke ich nicht an SQL Mail selbst wäre direkt der Schuldige. Ich sage "direkt", weil ich nicht weiß, was du damit machst. Allerdings nehme ich an, dass SQL Mail im Vergleich zu den anderen SQL-Befehlen wahrscheinlich langsam ist. Wenn Sie also eine Menge damit machen, könnte dies indirekt einen Engpass verursachen, der zu einem Deadlock führt, wenn Sie Halten Sie sich beim Senden der SQL-Mail an Tabellen fest.
Es ist schwierig, eine bestimmte Strategie zu empfehlen, ohne zu viele Details über das zu haben, was Sie tun. Kurz gesagt, sollten Sie darüber nachdenken, ob es eine Möglichkeit gibt, Ihre Abhängigkeit vom Halten auf dem Tisch zu brechen, während Sie NOLOCK verwenden, eine temporäre Tabelle oder eine Nicht-Temp- "Halte" -Tabelle verwenden oder einfach den SP refaktorisieren das macht den Anruf.
Tags und Links sql-server deadlock