Erklären Sie das relevante Wissen über Update-Sperre (U) und exklusive Sperre (X).

Ich habe die Sperre des UPDATE-Vorgangs nie wirklich verstanden. Ich habe kürzlich einen im MSDN-Forum gesehen Frage zum Deadlock-Problem bei der Aktualisierung der Heap-Tabelle. Es gibt ähnliche Tabellen und Daten:

CREATE TABLE dbo.tb(
     c1 int,
     c2 char(10),
     c3 varchar(10)
);
GO
DECLARE @id int;
SET @id = 0;
WHILE @id <5
BEGIN;
     SET @id = @id + 1;
     INSERT dbo.tb VALUES( @id, &#39;b&#39; + RIGHT(10000 + @id, 4), &#39;c&#39; + RIGHT(100000 + @id, 4) );
END;

Aktualisierungsvorgang in Abfrage eins durchführen:

BEGIN TRAN
UPDATE dbo.tb SET c2 = 'xx' WHERE c1 = 2;
WAITFOR DELAY '00:00:30';
UPDATE dbo.tb SET c2 = 'xx' WHERE c1 = 5;
ROLLBACK;

Nachher Die Ausführung von Abfrage eins beginnt. Führen Sie sofort die folgenden Vorgänge in Abfrage zwei aus

BEGIN TRAN
UPDATE dbo.tb SET c2 = 'xx' WHERE c1 = 1;
ROLLBACK;

Warum tritt ein Deadlock auf? Wenn die Bedingung auf c1 = 4 geändert wird, kommt es zu keinem Deadlock.

Am Anfang dachte ich, dass die Leistung eines Deadlocks darin besteht, eine Warteschleife zu bilden (für zwei Abfragen kann man sich das einfach vorstellen). (als würden wir aufeinander warten) Die Freigabe der gesperrten Ressourcen der anderen Partei).

In diesem Beispiel wird die erste Abfrage zweimal aktualisiert. Zuerst wird ein Datensatz aktualisiert und gesperrt, und dann wird auf die zweite Aktualisierung gewartet Die Abfrage aktualisiert nur einen Datensatz und kann die Sperre nicht erhalten. Zu diesem Zeitpunkt kann keine Sperre erstellt und die Aktualisierung abgeschlossen werden . Es scheint, dass ein Deadlock nicht auftreten sollte. Könnte der Deadlock andere Gründe haben?

Ich habe es einfach auf meinem Computer getestet und es scheint, dass es tatsächlich keinen Deadlock gibt.

Aber später habe ich durch die Profilverfolgung der Sperrsituation des Update-Vorgangs herausgefunden, dass meine Analyse völlig falsch war. Der Hauptgrund liegt darin, dass es kein korrektes Verständnis darüber gibt, wie Sperren bei Aktualisierungsvorgängen verwendet werden.

Auf der Online-Hilfe "Sperrmodus" Es gibt Anweisungen zu aktualisiertem U (Update-Sperre) und /library/ms175519(v=sql.105).aspx

Aber es ist wirklich vage S-Sperre, von der ich immer dachte, dass sie es ist. Die S-Sperre wird beim Abfragen von Daten verwendet (dasselbe wie SELECT). Nachdem die Datensätze gefunden wurden, die die Bedingungen erfüllen, wird die U-Sperre verwendet und dann in die X-Sperre umgewandelt zum Aktualisieren.

Profil (Profiler) Tracking-Ergebnisse lassen mich wissen, dass dies ein falsches Verständnis ist. Erstellen Sie ein neues Tracking im Profil und wählen Sie Sperre:Erworben(Sperre), Sperre:Erworben (Sperre aufheben ) Lösen Sie die beiden Ereignisse und stellen Sie im Filter ein, dass nur der Spid verfolgt wird, der dem Abfragefenster zum Testen entspricht (Sie können PRINT @@SPID erhalten) und führen Sie dann eine Aktualisierungsanweisung aus, z. B. UPDATE dbo.tb SET c2 = 'xx' WHERE c1 = 3

Wie Sie im Profil sehen können, wird U zu jedem Datensatz hinzugefügt Durch den Sperrvorgang werden U-Sperren für Datensätze, die die Bedingungen nicht erfüllen, sofort freigegeben. Für Datensätze, die die Bedingungen erfüllen, werden sie schließlich in X-Sperren umgewandelt. Wie unten gezeigt.

Beachten Sie, dass in diesem Tracking-Ergebnis Inside , es gibt keine S-Sperre.

Zusätzlich habe ich einige Tests gemacht:

1. Wenn Sie die Anzahl der Datensätze für Update-Tests erhöhen, werden Sie feststellen, dass die am Datenscan beteiligten Datensätze über Bügelsperren verfügen und nicht auf die Seite beschränkt sind, auf der sich der Update-Datensatz befindet. Dies zeigt aus einer anderen Perspektive, dass Scan bei großen Uhren schrecklich ist.

2. Bei der Verwendung des Index-Scans wird durch die Nachverfolgung auch festgestellt, dass die gescannte Indexressource über eine U-Sperre verfügt. Wenn die Aktualisierung keine Indexänderungen beinhaltet, ist dies der Fall wird nur Der entsprechende Datensatz verfügt über eine U-zu-X-Sperre, und die U-Sperre des Index wird freigegeben. Wenn sie sich auf den Index auswirkt, wird die U-Sperre des Index in eine X-Sperre umgewandelt.

3. Der Löschvorgang ähnelt dem Aktualisierungsvorgang

4. Verwenden Sie UPDATE aSET c2 = 'xx' FROM dbo.tb AS a MIT(NOLOCK) WHERE c1 = 3 Die Sperrsituation von ist dieselbe, und U oder >

   Schauen wir uns zum Schluss noch einmal das Deadlock-Problem im Beispiel an:

Bei der ersten Abfrage werden alle Datensätze in der Tabelle nacheinander gescannt. Fügen Sie für jeden Datensatz eine U-Sperre hinzu, um festzustellen, ob er die Aktualisierungsbedingungen erfüllt Wenn es die Bedingungen erfüllt, wandeln Sie es in ein X-Schloss um. Wenn es die Bedingungen nicht erfüllt, geben Sie das U-Schloss frei. Wenn die erste Aktualisierung abgeschlossen ist, sperrt die Abfrage einen Datensatz (die Sperre bleibt bestehen, da die Transaktion nicht abgeschlossen ist) und wartet dann auf die zweite Aktualisierung

• Bei der zweiten Abfrage wird jeder Datensatz in der Tabelle nacheinander gescannt (wie bei der vorherigen Aktualisierung), bevor der von der ersten Abfrage aktualisierte Datensatz gescannt wird Beim Erreichen des Nullpunkts des X-Sperrdatensatzes der ersten Abfrage kommt es zu Konflikten mit der zweiten Aktualisierung, und jeder Datensatz wird der Reihe nach gescannt. Es entsteht kein Konflikt innerhalb derselben Transaktion, sodass es nicht zu Konflikten mit dem zuvor vorhandenen Datensatz kommt Wenn jedoch der zweite gesperrte Datensatz abgefragt wird, kann er die U-Sperre nicht erhalten und muss auf Abfrage zwei warten, um die Ressource freizugeben. Zu diesem Zeitpunkt wird ein gegenseitiges Warten gebildet, das die Deadlock-Bedingung erfüllt

• Wenn der Datensatz, der in Abfrage zwei aktualisiert werden muss, nach dem ersten aktualisierten Datensatz in liegt Abfrage eins, dann wird es keinen Deadlock geben, da Abfrage zwei aufgrund eines Sperrenkonflikts wartet, wenn sie den ersten aktualisierten Datensatz von Abfrage eins scannt. Zu diesem Zeitpunkt wird keine Sperre für Datensätze gesetzt, die mit dem in Konflikt stehen Betrieb der ersten Abfrage. Dies war der Fall, als ich es selbst ohne Deadlocks getestet habe.

• Beachten Sie, dass die hier genannte Reihenfolge die Reihenfolge ist, in der Daten gelesen werden, die nicht unbedingt mit der Speicherreihenfolge übereinstimmt. Die Reihenfolge der Datensätze auf der Festplatte ist nicht unbedingt dieselbe Dies ist auch der Grund, warum ich nicht unter denselben Bedingungen auf Deadlock getestet habe (in meiner Umgebung unterscheidet sich die Lesereihenfolge zufällig von der Reihenfolge von INSERT)

Notieren Sie beim Aktualisieren die Lesereihenfolge, die über das Profil verfolgt werden kannSperre:Erworben (Sperre)In Bezug auf Ereignisse kommt es bei großen Datenmengen zu gleichzeitigen Lesevorgängen, sofern der Server dies unterstützt. Dies ist auch ein Faktor, der bei der Analyse von Deadlocks berücksichtigt werden muss

Dieser Artikel erklärt Erläutert die relevanten Kenntnisse über Update-Sperre (U) und exklusive Sperre (X), mehr Für verwandte Inhalte achten Sie bitte auf die chinesische PHP-Website.

Verwandte Empfehlungen:

SQL Server 2008-Verbesserungen bei der Handhabung impliziter Datentypkonvertierungen in Ausführungsplänen

So implementieren Sie eine Eltern-Kind-Beziehungsabfrage auf unendlicher Ebene in einem einzigen Satz in MySQL

So greifen Sie mit Fortschritt auf SQL Server FileStream zu



Das obige ist der detaillierte Inhalt vonErklären Sie das relevante Wissen über Update-Sperre (U) und exklusive Sperre (X).. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!