So verhindern Sie partitionierte Columnstore-Deadlocks bei SELECT

Ich habe drei CCI-Tabellen (Clustered Columnstore Index) in SQL Server 2016. Alle diese CCIs befinden sich im selben Partitionierungsschema, basierend auf der Mandanten-ID. In letzter Zeit und uneinheitlich erhalte ich Deadlocks bei einfachen select-Anweisungen von Verknüpfungen zu diesen Tabellen. Beispielabfrage, die blockiert:

SELECT  TOP 33 r.tenantid
FROM    Table_r r
        INNER JOIN Table_cm cm ON r.MyKey=cm.MyKey 
        INNER JOIN Table_pe pe ON r.MyKey=pe.MyKey 
WHERE   r.TenantId = 69
        AND pe.TenantId = 69
        AND cm.TenantId = 69

Fehlermeldung:

Die Transaktion (Prozess-ID 56) wurde für generische wartbare Objektressourcen mit einem anderen Prozess blockiert und als Deadlock-Opfer ausgewählt. Führen Sie die Transaktion erneut aus.

Hinweise:

• Wenn die Abfrage neben der CCI einen anderen Index verwendet, blockiert sie nicht.
• Wenn ich zwei der drei Tenantid-Filter entferne, blockiert dies nicht.
• Wenn ich Top 32 oder niedriger auswähle, blockiert es nicht.
• Wenn ich OPTION (MAXDOP 1) hinzufüge, blockiert es nicht.
• Ich kann dies in meinem verschlüsselten PROD-Replikat, PROD READ-ONLY Secondary und PROD selbst wiedergeben.
• Ich kann dieses Verhalten in DEV oder INT nicht wiederholen.
• Es blockiert immer noch, wenn ich WITH (NOLOCK) zu allen 3 Tabellenverknüpfungen hinzufüge
• Die Abfrage blockiert sich selbst. Es wird blockiert, wenn keine anderen aktiven Prozesse vorhanden sind.
• Abfragepläne ohne Parallelität blockieren nicht

Deadlock xml hier

Unsere PROD-Version:

Microsoft SQL Server 2016 (SP2-CU5) (KB4475776) - 13.0.5264.1 (X64) 10. Januar 2019 18:51:38 Copyright (c) Microsoft Corporation Enterprise Edition (64-Bit) unter Windows Server 2012 R2 Standard 6.3 (Build 9600) :) (Hypervisor)

Wie verhindere ich Deadlocks bei dieser Abfrage?

Da Sie mit SQL Server 2016 arbeiten, ist es erwähnenswert, dass es mindestens eine öffentliche Fehlerbehebung für parallele Deadlocks mit Columnstore-Indizes gibt:

UPDATE: Ein Deadlock tritt auf, wenn Sie eine parallele Abfrage für einen Clustered Columnstore-Index in SQL Server 2016 und 2017 ausführen

(Danke an Denis Rubashkin für die anfängliche Bereitstellung des Links)

Dies wurde als Teil von SP1 CU7 veröffentlicht. Wenn Sie dieser CU nicht gewachsen sind, sollten Sie es versuchen. Dieser Fix wäre auch in SP2 (einer der CUs) enthalten.

Im Allgemeinen sind die beiden Ansätze zum Beheben von Deadlocks bei der Parallelität zwischen Abfragen:

• Vermeiden Sie Parallelität (indem Sie die Abfrage so einstellen, dass sie nicht parallel verläuft, einen MAXDOPHinweis verwenden usw.) - dies wird in der anderen Antwort von Thomas Costers behandelt
• Wenden Sie die neuesten Service Pack- / kumulativen Updates auf SQL Server an

Haben Sie den folgenden Blog über Intra-Query Parallel Thread Deadlocks überprüft ?

Die SyncPointRessource zeigt die Verwendung eines Austauschereignisses an, wenn ich mich nicht irre.
Wenn Sie sich die Teilnehmer Ihres Deadlocks ansehen, sehen Sie, dass sie alle von derselben Spid (55) und Batch (0) stammen, aber unterschiedliche Threads verwenden. Dies zeigt an, dass sie alle Teil derselben parallelen Abfrage sind, und wird durch die Tatsache bestätigt, dass Sie keine Deadlocks erhalten, wenn Sie die Abfrage mit ausführen MAXDOP 1. Im Fall von Intra-Query-Parallel-Thread-Deadlocks blockieren sich die Threads einer einzelnen Abfrage gegenseitig und warten auf Synchronisationsobjekte, in Ihrem Fall SyncPoints.

Als ich das letzte Mal Zeuge dieser Art von Verhalten wurde, konnte ich die Abfrage weiter optimieren und so verhindern, dass die Abfrage einen parallelen Ausführungsplan verwendet. Ich vermute, Sie haben dasselbe getan, indem Sie Ihre Ergebnismenge auf 32 Datensätze beschränkt oder einen anderen Index verwendet haben.
Eine andere Option wäre MAXDOP 1, Ihrer Anfrage etwas hinzuzufügen , obwohl dies kein großer Fan dieser Option ist.

Bevor Sie jedoch mit diesen beiden Optionen herumspielen, überprüfen Sie zunächst, ob Sie die neueste SP / CU verwenden.