Ursache dafür, dass ein Prozess ein Deadlock-Opfer ist

Ich habe einen Prozess mit einem Select, dessen Abschluss in der Größenordnung von 5 bis 10 Minuten lange dauert.
Ich verwende NOLOCK derzeit nicht als Hinweis auf das MS SQL-Datenbankmodul.
Gleichzeitig führt ein anderer Prozess Aktualisierungen und Einfügungen in dieselbe Datenbank und dieselben Tabellen durch.
Der erste Prozess wurde vor kurzem gestartet und endet vorzeitig mit einer Nachricht

SQLEXCEPTION: Die Transaktion wurde für Sperrressourcen mit einem anderen Prozess blockiert und als Deadlock-Opfer ausgewählt.

Dieser erste Prozess wird an anderen Standorten unter identischen Bedingungen ausgeführt, jedoch mit kleineren Datenbanken. Daher dauert die betreffende select-Anweisung viel kürzer (in der Größenordnung von etwa 30 Sekunden). Auf diesen anderen Websites wird die Deadlock-Nachricht auf diesen anderen Websites nicht angezeigt. Ich habe diese Nachricht auch nicht auf der Site erhalten, auf der das Problem anfänglich auftritt, aber ich gehe davon aus, dass ich mit dem Wachstum der Datenbank einen bestimmten Schwellenwert überschritten habe. Hier sind meine Fragen:

1. Könnte die Zeit, die eine Transaktion benötigt, um ausgeführt zu werden, die Wahrscheinlichkeit erhöhen, dass der zugehörige Prozess als Deadlock-Opfer gekennzeichnet wird.
2. Wenn ich die Auswahl mit einem NOLOCK-Hinweis ausführe, wird das Problem dadurch behoben?
3. Ich vermute, dass ein Datum / Uhrzeit-Feld, das als Teil der WHERE-Klausel in der select-Anweisung überprüft wird, die langsame Suchzeit verursacht. Kann ich basierend auf diesem Feld einen Index erstellen? Ist es ratsam?

Frage 1: Könnte die Zeit, die für die Ausführung einer Transaktion benötigt wird, die Wahrscheinlichkeit erhöhen, dass der zugehörige Prozess als Deadlock-Opfer gekennzeichnet wird.

Nein. Das SELECT ist das Opfer, da es nur Daten gelesen hat. Daher sind mit der Transaktion geringere Kosten verbunden. Daher wird es als Opfer ausgewählt:

Standardmäßig wählt das Datenbankmodul als Deadlock-Opfer die Sitzung aus, in der die Transaktion ausgeführt wird , deren Rollback am kostengünstigsten ist . Alternativ kann ein Benutzer mithilfe der SET DEADLOCK_PRIORITYAnweisung die Priorität von Sitzungen in einer Deadlock-Situation angeben . DEADLOCK_PRIORITY kann auf LOW, NORMAL oder HIGH oder alternativ auf einen beliebigen ganzzahligen Wert im Bereich (-10 bis 10) gesetzt werden.

Q2. Wenn ich die Auswahl mit einem NOLOCK-Hinweis ausführe, wird das Problem dadurch behoben?

Aus mehreren Gründen:

• Sie sollten zuerst versuchen, den Deadlock ordnungsgemäß zu beseitigen, indem Sie die Grundursache untersuchen
• Dirty Reads sind inkonsistente Lesevorgänge .
• Der richtige Weg, um Dirty Reads anzugeben, ist die Verwendung von Transaktionsisolationsstufen
• Es gibt eine viel bessere Lösung: Lesen Sie den festgeschriebenen Schnappschuss .

Q3. Ich vermute, dass ein Datum / Uhrzeit-Feld, das als Teil der WHERE-Klausel in der select-Anweisung überprüft wird, die langsame Suchzeit verursacht. Kann ich basierend auf diesem Feld einen Index erstellen? Ist es ratsam?

Wahrscheinlich. Die Ursache für den Deadlock ist höchstwahrscheinlich eine schlecht indizierte Datenbank. 10-Minuten-Abfragen sind unter so engen Bedingungen akzeptabel, dass ich zu 100% sicher bin, dass sie in Ihrem Fall nicht akzeptabel sind.

Mit 99% iger Sicherheit erkläre ich, dass Ihr Deadlock durch einen großen Tabellenscan verursacht wird, der mit Aktualisierungen in Konflikt steht. Beginnen Sie mit der Erfassung des Deadlock-Diagramms , um die Ursache zu analysieren. Sie müssen sehr wahrscheinlich das Schema Ihrer Datenbank optimieren. Bevor Sie Änderungen vornehmen, lesen Sie dieses Thema Entwerfen von Indizes und die Unterartikel.

Hier erfahren Sie, wie dieses spezielle Deadlock-Problem tatsächlich aufgetreten ist und wie es tatsächlich behoben wurde. Dies ist eine ziemlich aktive Datenbank mit täglich 130.000 Transaktionen. Die Indizes in den Tabellen in dieser Datenbank wurden ursprünglich geclustert. Der Kunde hat uns gebeten, die Indizes nicht gruppiert zu machen. Sobald wir das taten, begann die Blockade. Als wir die Indizes als Cluster wiederhergestellt haben, wurde das Deadlocking gestoppt.

Die Antworten hier sind einen Versuch wert, aber Sie sollten auch Ihren Code überprüfen. Lesen Sie hier speziell die Antwort von Polyfun: Wie können Sie Deadlocks in einer SQL Server 2005- und C # -Anwendung beseitigen ?

Es erklärt das Problem der Parallelität und wie die Verwendung von "with (updlock)" in Ihren Abfragen Ihre Deadlock-Situation korrigieren kann - abhängig davon, was genau Ihr Code tut. Wenn Ihr Code diesem Muster folgt, ist dies wahrscheinlich eine bessere Lösung, bevor Sie auf schmutzige Lesevorgänge usw. zurückgreifen.

Obwohl @ Remus Rusanu ‚s ist bereits eine ausgezeichnete Antwort, falls man freut sich einen besseren Einblick auf SQL Server Deadlock verursacht und Trace - Strategien, würde ich vorschlagen , Sie lesen Brad McGehee ‘ s Wie die Spur Deadlocks mit SQL Server 2005 Profiler