Warum wird SQL Server SET DEADLOCK_PRIORITY HIGH nicht beachtet?

8

Ich habe ein Deadlock-Diagramm für SQL Server 2012 erfasst (mit Gail Shaws Abfrage), die einen Prozess mit taskpriority=" 10 "zeigt, der als Deadlock-Opfer über 2 Prozesse mit taskpriority=" 0 "ausgewählt wurde.

Nach meinem Verständnis wird die Deadlock-Priorität zuerst überprüft, und Prozesse mit niedrigerer Priorität werden als Opfer ausgewählt. Nur wenn alle Prozesse gleich sind, sind andere Faktoren relevant. Kann irgendjemand etwas darüber sagen, warum DEADLOCK_PRIORITY möglicherweise nicht geehrt wird?

Interessanterweise SET DEADLOCK_PRIORITY Die MSDN-Seite sagt, dass HIGH auf 5 abgebildet ist, und mein Code verwendet definitiv HIGH, also bin ich mir nicht sicher, woher die 10 kommt.

Ärgerlich ist das Opfer ein wichtiger Geschäftsprozess, während die Überlebenden beide SSMS Intellisense-Abfragen sind.

Bearbeiten

Erstens geht es in dieser Frage darum, warum DEADLOCK_PRIORITY nicht beachtet würde, nicht, welche Deadlocks es sind oder wie man sie verhindert oder umgeht oder was das im Beispiel unten verursacht hat. Das sind alles interessante Gespräche, aber nicht hier.

Zweitens, ein paar zusätzliche Fakten, die relevant sein könnten, basierend auf Links, die von @SteveFord gefunden wurden; Die Sperrpartitionierung ist auf diesem SQL Server aktiviert und die SQL Server-Version ist älter als 2012 CU6 (wenn der Patch in KB2776344 veröffentlicht wurde.

Drittens ist für Interessierte hier eine sanierte Deadlock-Grafik zu sehen, die den Prozess mit höherer Priorität als Opfer darstellt. Ich habe SQL entfernt und ein paar Namen geändert, alles andere ist intakt.

%Vor%     
Rhys Jones 22.01.2018, 12:09
quelle

1 Antwort

2

Es sieht so aus, als wäre der Befehl, der getötet wird, eine ALTER PARTITION FUNCTION. Es ist interessant zu bemerken, dass dies eine SCH-M-Sperre erfordert, die nicht mit SCH-S-Sperren kompatibel ist, die für alles genommen werden. Ich denke, das könnte eine Ursache sein.

Siehe michaeljswart.com/2013/04/the-sch-m-lock -ist-böse .

Siehe auch diese Beschreibung eines SCH-M-Deadlocks von einer ALTER PARTITION-Funktion und einer Abfrage, die eine Statistikaktualisierung in SQL 2014 & amp; 2016, aber vielleicht auch 2012: Deadlock Tritt auf, wenn Sie eine SCH-M-Sperre erwerben

Wenn Sie Ihr Diagramm betrachten, hat ein Prozess eine gemeinsame (Update-) Sperre für sysschobjs und wartet auf eine SCH-S-Sperre auf Ihrem Tisch. Ihr Prozess hat eine SCH-M-Sperre auf Ihrem Tisch und wartet auf eine X-Sperre auf sysschobjs. sysschobjs ist eine System Basistabelle, die hinter sysobjects steht. Siehe die Diskussion hier Technet: SQL-Abfrage, die oft Deadlock verursacht

Hoffe, das hilft

  

Aktualisierung   Wenn Sie dies weiter erforschen wollen, habe ich die Beschreibung des MS-Patents gefunden, wie der Deadlock-Monitor hier Opfer

wählt
    
Steve Ford 05.02.2018, 20:50
quelle