Können Fremdschlüssel Deadlocks verursachen und READ COMMITTED SNAPSHOT behindern?

Dies ist eine Folgefrage von: /programming/7684477/is-it-possible-to-set-transaction-isolation-level-snapshot-automatically

Ich habe immer noch Deadlock / Timeout-Situationen in der ASP.NET-Anwendung, wenn gleichzeitig große Berichte ausgeführt werden READ_COMMITTED_SNAPSHOT ON.

Ich habe also zwei Fragen:

1. Wie kann ich überprüfen, ob der Transaction Isolation Level Snapshot erwartungsgemäß funktioniert?
2. Ich gehe davon aus, dass die Fremdschlüssel (in den Tabellen der Web-Applikation zu den Report-Tabellen) für Deadlocks verantwortlich sind. Ich fand diesen interessanten Artikel :

Hinweis SQL Server erwirbt gemeinsam genutzte Sperren, wenn Fremdschlüssel überprüft werden, auch wenn die Transaktion einen Snapshot mit festgeschriebenem Lesezugriff (Read Committed Using Row Versioning) oder eine Snapshot-Isolationsstufe verwendet. Beachten Sie dies, wenn Sie Deadlock-Diagramme von Transaktionen untersuchen, wenn diese Transaktionsisolationsstufen verwendet werden. Wenn freigegebene Sperren angezeigt werden, überprüfen Sie, ob die Sperren für ein Objekt verwendet werden, auf das ein Fremdschlüssel verweist.

Wie kann ich überprüfen, ob die FK wirklich für die Deadlock- / Timeout-Situationen verantwortlich sind? Heißt das, ich könnte diese Fremdschlüssel löschen, um Deadlocks zu verhindern (was wäre ein akzeptabler Aufwand)?

Hinweis : Ich lese nur aus den Tabellen, die Deadlocks verursachen.

Alle Gedanken zu diesem Thema werden sehr geschätzt.

Edit Hier ist ein Deadlock-Graph . Vielleicht könnte mir jemand helfen zu verstehen, was den Deadlock verursacht. Es hat den Anschein, dass es ohne Berichte, die nur von der Webanwendung erstellt wurden, passiert ist, wenn zwei Transaktionen dieselbe Tabelle schreiben möchten (ein Update und eine Einfügung, die Einfügung lautet Stored-Procedure). Warum werden Seitensperren aktiviert und wie werden nur Zeilensperren aktiviert? Das Insert-SP nutzt schon TRANSACTION ISOLATION LEVEL REPEATABLE READ.

Ich habe den starken Verdacht, dass zwei Trigger (ein Update und ein Insert) für die Deadlocks verantwortlich sind. Hier ist der Insert-Trigger:

CREATE TRIGGER [dbo].[CreateRMAFiDates] 
   ON  [dbo].[RMA] 
   AFTER INSERT
AS 
BEGIN
    SET NOCOUNT ON;

    UPDATE RMA 
    SET [fiCreationDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.Creation_Date, 112) = tdefDate.Text),
        [fiPopDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.POP_Date, 112) = tdefDate.Text),
        [fiManufactureDate]=(SELECT idDate FROM tdefDate 
        WHERE CONVERT(VARCHAR, INSERTED.Manufacture_Date, 112) = tdefDate.Text)
    FROM INSERTED;
END

Dieser Trigger aktualisiert also die RMA-Tabelle, wodurch der Update-Trigger ausgelöst wird (was ähnlich ist). Bestätigt der Deadlock-Graph meine Annahme? Ich denke, ich werde diese Trigger löschen und einen SP erstellen, der einmal am Tag ausgeführt wird, was vollkommen ausreichend wäre, da diese Spalte nur für einen SSAS-Cube (Molap) bestimmt ist.

Edit : Übrigens gab es keinen Deadlock mehr, seit ich diese Trigger gelöscht habe :)

Wenn das SQLCAT-Team angibt, dass die FK- Validierung mithilfe von Read-Committed-Isolation durchgeführt wird, muss es wissen, wovon es spricht. Schwerpunkt auf Validierung . Die eigentliche Frage ist, warum ein Bericht die FK-Validierung auslösen würde . Die Validierung erfolgt beim Schreiben , und Berichte sollten gelesen werden . Entweder verursachen Ihre Berichte Schreibvorgänge, und in diesem Fall helfen die Snapshot-Isolationsstufen nichts, oder die Ursache des Deadlocks ist unterschiedlich.

Die einzige Möglichkeit, Fortschritte zu erzielen, besteht darin, das Deadlock-Diagramm zu erfassen.

Was die andere Frage betrifft, wie können Sie überprüfen, ob Sie unter Snapshot-Isolation arbeiten: Schauen Sie rein sys.dm_tran_active_snapshot_database_transactions.

Die Fremdschlüsselüberprüfung muss unter (Sperr-) Lesezugriff erfolgen, um die Richtigkeit zu gewährleisten. Siehe Snapshot-Isolation: Eine Bedrohung für die Integrität? von Hugo Kornelis für Details.

Das Deadlock-Diagramm zeigt zwei gleichzeitige Ausführungen der RM2.dbo.RMAUrsache des Deadlocks. Ihren Triggern fehlt eine Join-Bedingung zwischen RMAund inserted.

Es ist wahrscheinlich, dass dies ein Versehen ist und Ihr Trigger versehentlich alle Zeilen in aktualisiert, RMAsodass Deadlocks mit hoher Wahrscheinlichkeit auftreten, wenn mehrere Trigger gleichzeitig ausgeführt werden.