it-swarm.com.de

SQL Server: Deadlock bei Sperrkommunikationspufferressourcen

Was könnte ein möglicher Grund für diesen Deadlock-Typ sein? (kein Deadlock im Allgemeinen)

Kommunikationspufferressourcen sperren

Ist dieses angezeigte System schwach im Speicher und die Anzahl der Puffer ist abgelaufen?

Detaillierter Fehler:

Die Transaktion (Prozess-ID 59) wurde in Sperrkommunikationspufferressourcen mit einem anderen Prozess blockiert und als Deadlock-Opfer ausgewählt. Führen Sie die Transaktion erneut aus

32
usman shaheen

Die vollständige Nachricht, die häufig gesehen wird:

Die Transaktion (Prozess-ID 53) war bei Sperre | blockiert Kommunikationspufferressourcen mit einem anderen Prozess und wurde als Deadlock-Opfer ausgewählt. Führen Sie die Transaktion erneut aus.

Dieser Sperrtyp tritt häufig bei Deadlock-Abfragen auf, die SQL Server als parallel ausgeführt hat. Diese werden manchmal als "parallele Deadlocks innerhalb von Abfragen" bezeichnet. Ich habe einige Aussagen gesehen, die auch darauf hinweisen, dass die Systemressourcen niedrig sind, was meiner Meinung nach in geringem Maße eine Rolle spielen könnte.

Eine allgemeine Richtlinie, die mir aufgefallen ist, um festzustellen, ob es sich um einen parallelen Deadlock handelt, besteht darin, dass Sie beim Abrufen des XML-Deadlock-Diagramms (dies kann mit der system_health-Sitzung ab 2008 durchgeführt werden) unterschiedliche Prozess-IDs feststellen, die dasselbe Codebit innerhalb von anzeigen Ausführungsstapel.

Sehen Sie sich auch die Ressourcenliste des Deadlock-Diagramms an und notieren Sie den Typ des Kellnerereignisses. Sie zeigen am häufigsten "e_xxxxxx" oder so etwas vielleicht:

<waiter-list>
 <waiter event="e_waitPipeGetRow" type="consumer" id="process821d828" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process8209198" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process3827c18" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process3809eb8" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process8226b08" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process9acb6d8" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process6188d7828" />
 <waiter event="e_waitPipeGetRow" type="consumer" id="process381cef8" />
</waiter-list>

Um das Problem zu lösen, werden verschiedene Wege online und in Büchern angeboten. Ich beginne im Allgemeinen mit dem Ausführungsplan der Abfrage/Prozedur und konzentriere mich auf die Bereiche, in denen die parallele Ausführung angezeigt wird. Von dort aus versuchen Sie zunächst, die Abfrage zu optimieren, und verwenden dann als letztes Mittel möglicherweise Abfragehinweise.

Der häufigste Abfragehinweis, der zur Behebung dieser Deadlocks angezeigt wird, ist die Implementierung von MAXDOP 1. Bevor Sie dies tun, können Sie jedoch überprüfen, auf welche Serverebene MAXDOP und Kostenschwelle eingestellt sind. Der Kostenschwellenwert ist im Allgemeinen standardmäßig auf 5 festgelegt, und ich möchte diesen Wert zunächst auf 35 oder 40 erhöhen. Wenn die betreffende Abfrage für diesen Codeabschnitt geringe Kosten verursacht, muss sie möglicherweise überhaupt nicht parallel ausgeführt werden. Ich mag es nicht so sehr, MAXDOP-Abfragehinweise zu verwenden, aber das bedeutet nicht, dass sie nicht ihren Platz und Zweck haben. nur meine Meinung.

28
user507