Wir verwenden Clustered Columnstore Index in unserer Transaktionstabelle, die Order Erfüllungen führt. Diese Tabelle wird regelmäßig durch verschiedene Sitzungen aktualisiert. Aber jede Sitzung ist spezifisch für Auftragsnummer und daher versuchen sie nicht dieselbe Zeile gleichzeitig zu aktualisieren. Aber wir sehen uns mit Problemen konfrontiert, die durch die folgenden Szenarien entstehen können.Deadlock im Clustered Columnstore Index
- Reihengruppe Verriegelungs & Seitensperre
- Reihengruppe Verriegelungs & Zeilengruppe
Dies ist nicht spezifisch für eine gespeicherte Prozedur zu verriegeln. Es ist aufgrund mehrerer gespeicherter Prozeduren, die diese Tabelle sequentiell nacheinander aktualisieren, als Teil der Auftragserfüllung.
Die Probe Schema der Tabelle ist sehr einfach:
CREATE TABLE OrderFulfillments
(
OrderJobNumber INT NOT NULL,
FulfilledIndividualID BIGINT NOT NULL,
IsIndividualSuppressed BIT NOT NULL,
SuppressionReason VARCHAR(100) NULL
)
ich für Ihre Referenzprobe Deadlock Graph gegeben haben. Bitte lassen Sie mich wissen, welchen Ansatz ich nehmen kann, um diese Sackgasse zu vermeiden. Wir benötigen den columnstore-Index in dieser Tabelle, da wir Aggregationsoperationen durchführen, um zu sehen, wie oft ein Individuum bereits erfüllt wurde. Ohne columnstore index ist es möglicherweise langsamer.
Sie müssen sich fragen, welche Abfragen die Blockierung verursachen. Wenn die Aktualisierungen wirklich sequentiell waren, sind die Antworten nicht die Aktualisierungen, sondern andere Prozesse wie SELECT-Anweisungen in der Tabelle. Finden Sie heraus, was der last_wait_type von sys.DM_exec_requests ist –
Und ja, eine Select-Anweisung verwendet immer noch eine gewisse Ebene der Sperrung. –
Danke clifton. Ich habe NOLOCK bei jeder ausgewählten Abfrage angewendet. Nur für UPDATE haben wir NOLOCK nicht, um Datenkorruption zu vermeiden. Also, Select ist das nicht das Problem hier. Es ist Lock-Eskalation auf Rowgroup-Ebene, die den Deadlock verursacht. Ich werde Sie mit Wartestatusinformationen –