Was könnte ein möglicher Grund für diesen Deadlock-Typ sein? (im Allgemeinen kein Deadlock)
Sperren Sie die Kommunikationspuffer-Ressourcen
Befindet sich auf diesem angezeigten System nur noch wenig Speicher und die Anzahl der Puffer ist überschritten?
Detaillierter Fehler:
Die Transaktion (Prozess-ID 59) war für die Ressourcen des Sperren-Kommunikationspuffers mit einem anderen Prozess gesperrt und wurde als Deadlock-Opfer ausgewählt. Führen Sie die Transaktion erneut aus
Antworten:
Die vollständige Meldung, die häufig angezeigt wird:
Transaktion (Prozess-ID 53) war bei Sperre gesperrt | 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 von SQL Server als parallel ausgeführt wurden. Diese werden manchmal als "abfrageinterne parallele Deadlocks" bezeichnet. Ich habe ein paar Aussagen gesehen, dass dies auch darauf hinweist, dass die Systemressourcen niedrig sind, was in geringem Maße beteiligt sein könnte.
Als allgemeine Richtlinie habe ich festgestellt, ob es sich um einen parallelen Deadlock handelt, wenn Sie das XML-Deadlock-Diagramm ziehen (dies kann mit der system_health-Sitzung ab 2008 durchgeführt werden). In der werden verschiedene Prozess-IDs angezeigt, die dasselbe Codebit aufweisen Ausführungsstapel.
Schauen Sie sich auch die Ressourcenliste des Deadlock-Diagramms an und notieren Sie den Typ des Kellnerereignisses. Sie werden am häufigsten "e_xxxxxx" anzeigen, oder so ähnlich 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. Im Allgemeinen beginne ich mit einem Blick auf den Ausführungsplan der Abfrage / Prozedur und konzentriere mich auf die Bereiche, in denen die parallele Ausführung angezeigt wird. Versuchen Sie dann zunächst, die Abfrage zu optimieren, und beginnen Sie als letztes Mittel möglicherweise, Abfragetipps zu verwenden.
Der häufigste Abfragehinweis, den Sie zur Behebung dieser Deadlocks sehen, ist die Implementierung MAXDOP 1. Bevor Sie dies tun, können Sie jedoch überprüfen, auf welche Serverebene MAXDOP und Cost Threshold eingestellt sind. Der Kostengrenzwert ist in der Regel 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 bin nicht so begeistert von MAXDOP-Abfragetipps, aber das bedeutet nicht, dass sie nicht ihren Platz und Zweck haben. nur meine Meinung.