Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

Verwalten Sie die Transaktionsparallelität mithilfe von Sperren in SQL Server

In einer Umgebung mit mehreren Benutzern ist es wichtig, die Kürzungsparallelität aufrechtzuerhalten. Diese Sperren sind speicherinterne Strukturen mit einer Größe von 96 Bytes. Ihre Rolle besteht darin, die Datenintegrität, Konsistenz und Gleichzeitigkeitskontrolle für jede Transaktion aufrechtzuerhalten. SQL Server folgt dem ACID-Test für jede Transaktion.

  • A Tomizität:Diese Eigenschaft stellt sicher, dass eine Transaktion, an der zwei oder mehr Prozesse beteiligt sind, vollständig festgeschrieben wird oder keiner der Prozesse festgeschrieben wird.
  • C Konsistenz:Es gibt Ihnen eine Garantie über den Zustand der zugesicherten Transaktion. Eine Transaktion sollte entweder einen neuen Datenzustand erzeugen oder zum bestehenden Zustand (vor der Transaktion) zurückkehren.
  • Ich Isolation:Zeigt an, dass Transaktionen voneinander isoliert sind. Wenn eine Transaktion ausgeführt wird und keine Daten festgeschrieben hat, ist sie von anderen Transaktionen isoliert.
  • D Haltbarkeit:Die Haltbarkeit stellt sicher, dass Ihre festgeschriebenen Daten niemals verloren gehen. Es verhindert Strom- und Betriebssystemausfälle oder andere softwarebedingte Fehler.

Um die ACID-Eigenschaften sicherzustellen, verhängt SQL Server verschiedene Arten von Sperren für die Objekte. In diesem Fall müssen andere Transaktionen warten, bis die Sperre aufgehoben wird.

Sperrmodi

SQL Server verwendet die folgenden Sperrmodi für jede Transaktion.

  • Gemeinsam genutzte Sperren:
    • In dieser Sperre ermöglicht SQL Server anderen Sitzungen, die ausgewählten Operationen zum Lesen von Daten auszuführen. Es verhindert jedoch Updates, bis die Sperre aktiv ist.
    • Mehrere Transaktionen können einer Zeile oder Seite gleichzeitig eine gemeinsame Sperre auferlegen.
    • Es ist eine allgemeine Sperre, die Sie auf Ihren Datenbankobjekten sehen.

Im folgenden T-SQL rufen wir den Kundendatensatz für eine bestimmte Kunden-ID ab. Außerdem verwenden wir die dynamische Verwaltungsansicht sys.dm_tran_locks, um die vorhandenen Sperren zu überprüfen.

BEGIN TRAN
SELECT * FROM [SalesLT].[Customer] WITH (HOLDLOCK)
WHERE CustomerID=1
    
SELECT resource_type, request_mode, resource_description
FROM   sys.dm_tran_locks
WHERE  resource_type <> 'DATABASE'

ROLLBACK

Wie unten gezeigt, hat es eine gemeinsame Sperre für die angegebene Ressourcen-ID (8194443284a0):

  • Exklusive (X) Sperren:
    • SQL Server verwendet die exklusive Sperre (X) für DML-Vorgänge (Löschen, Einfügen oder Aktualisieren), die das Ändern von Zeilen- oder Seitendaten erfordern.
    • Es verhindert, dass andere Benutzer auf die Ressource zugreifen, bis eine Sperre gesetzt wird.
    • SQL Server kann nur eine exklusive Sperre auf einer Seite oder Zeile für eine Transaktion haben.

In diesem Beispiel möchten wir Datensätze für die Kunden-ID 1 aktualisieren. Daher erfordert SQL Server eine exklusive Sperre für die Ressource. Keine andere Transaktion kann die exklusive Sperre für diese Ressource erwerben, bis die Transaktion abgeschlossen ist.

BEGIN TRAN
UPDATE [SalesLT].[Customer] 
SET Suffix='Mr.'  
WHERE CustomerID=1
    
SELECT resource_type, request_mode, resource_description
FROM   sys.dm_tran_locks
WHERE  resource_type <> 'DATABASE'

ROLLBACK
  • Aktualisiere (U)-Sperren:
    • Die Aktualisierungssperre ähnelt einer exklusiven Sperre. Es kann auf einem Datensatz platziert werden, der eine gemeinsame Sperre hat.
    • Die Aktualisierungssperre setzt eine weitere gemeinsame Sperre auf eine bestimmte Zeile. Sobald die Datensätze geändert werden können, wandelt SQL Server die Update-Sperre in eine exklusive Sperre um.
    • SQL Server kann eine Ressource mit einer Update-Sperre nicht gemeinsam sperren.
    • Sie können auch WITH UPDLOCK verwenden, um eine Update-Sperre zu erzwingen.

Das folgende Beispiel zeigt eine Aktualisierungssperre für die Ressourcen-ID (8194443284a0):

BEGIN TRAN
SELECT * FROM [SalesLT].[Customer] WITH (UPDLOCK)
WHERE CustomerID=1
    
SELECT resource_type, request_mode, resource_description
FROM   sys.dm_tran_locks
WHERE  resource_type <> 'DATABASE'

ROLLBACK
  • Absichtssperren:
    • Sein Zweck ist es, eine Transaktion über ihre Absicht zu informieren, eine Sperre zu erwerben. Es tritt auf, wenn eine Transaktion eine gemeinsame oder exklusive Sperre für die Ressourcen niedriger in der Hierarchie erfordert.
    • Die Transaktion lässt nicht zu, dass andere Transaktionen eine exklusive Sperre für die Tabelle mithilfe einer beabsichtigten Sperre erhalten.
    • Arten von Absichtssperren sind unten aufgeführt.
      • Intent Shared (IS) lock:Zeigt die Absicht von SQL Server an, Ressourcen niedrigerer Hierarchien zu lesen, indem eine gemeinsame Sperre einzeln für diese Ressourcen niedrigerer Hierarchien erworben wird.
      • Intent Exclusive (IX) lock:Zeigt die Absicht von SQL Server an, Ressourcen niedrigerer Hierarchien zu ändern, indem eine exklusive Sperre für diese Ressourcen niedrigerer Hierarchien eingerichtet wird.
      • Eine beabsichtigte Update-Sperre (IU):Sie kann auf Seitenebene nur für hierarchisch niedrigere Ressourcen erworben werden und wird nach Abschluss der Aktualisierung in eine IX-Sperre umgewandelt.

Wie unten gezeigt, hat die Transaktion eine exklusive Sperre auf einem Schlüssel und eine exklusive Intent-Sperre auf Seitenebene.

Umwandlungssperren

SQL Server konvertiert Sperrtypen, um mehrere Abfragen in einer Transaktion zu unterstützen. Diese Sperren werden als Konvertierungssperren bezeichnet.

  • SIX – Shared with Intent Exclusive lock:Die SQL Server-Transaktion hält eine gemeinsame Sperre auf mehreren Seiten und hat eine exklusive mehrere Zeilen sperren.
  • SIU – Die SQL Server-Transaktion hält eine gemeinsame Sperre auf mehreren Seiten und hat ein Update mehrere Zeilen sperren.
  • UIX-Update mit Intent Exclusive Lock:Die SQL Server-Transaktion hält auf mehreren Seiten eine Update-Sperre und hat eine Exclusive mehrere Zeilen sperren.

Schemasperren

SQL Server erwirbt zwei Arten von Schemasperren.

  • Schemastabilitätssperre (Sch-S):Diese Sperre wird verwendet, wenn eine schemaabhängige Abfrage kompiliert und ihr Ausführungsplan generiert wird. Das Sch-S-Schloss blockiert keinen Zugriff auf die Objektdaten.
  • Schemamodifikationssperre (Sch-M):Diese Sperre resultiert aus der Ausführung einer DDL-Abfrage (Data Definition Language). SQL Server kann nur eine Schemaänderungssperre für ein Objekt haben. Sie können ein Objekt mit dieser Schemasperre nicht ändern.

Im folgenden Beispiel erhalten wir beim Ändern einer Objektdefinition sowohl Sch-S- als auch Sch-M-Sperren.

BEGIN TRAN
Alter TABLE DemoTable ADD new bit
SELECT resource_type, request_mode, resource_description
FROM   sys.dm_tran_locks
WHERE  resource_type <> 'DATABASE'
ROLLBACK

Sperrkompatibilität

Die Sperrkompatibilität ist hilfreich, um zulässige Sperren im Falle mehrerer Transaktionen in derselben Ressource gleichzeitig zu überprüfen. Wenn eine Transaktion eine Sperre platziert, sollte die neue Sperre, die von einer anderen Transaktion platziert wird, damit kompatibel sein. Daher können Sie die folgende Sperrkompatibilitätsliste durchgehen und unterstützte Sperren während mehrerer Transaktionen finden.

Eskalationen sperren

SQL Server hat eine Sperrenausweitungsfunktion eingeführt, um zu viele Sperren zu verhindern, die zu Speicherengpässen führen könnten. SQL Server berücksichtigt die Anzahl der Sperren, die bei einem bestimmten Scan gehalten werden, und die Anzahl der Sperren, die von der gesamten Transaktion und dem Arbeitsspeicher dynamisch gehalten werden. SQL Server konvertiert bei der Sperrenausweitung Low-Level-Sperren in High-Level-Sperren. Beispielsweise werden Zeilensperren in Sperren auf Seitenebene umgewandelt.

Es verwendet den folgenden Schwellenwert für Sperreneskalationen.

  • Gedächtnisschwelle: Die Sperrspeicherschwelle ist auf 40 Prozent des Sperrspeichers festgelegt.
  • Schwellenwert sperren: Wenn die Anzahl der für die aktuelle Tabelle oder den aktuellen Index erworbenen Sperren größer als 5000 ist, können Sperreneskalationen ausgelöst werden.

Benutzer können Sperreneskalationen mit der Anweisung alter table steuern. Sie können die Sperrenausweitung für diese Tabelle vollständig deaktivieren, indem Sie einen Parameterwert DISABLE.

verwenden 
ALTER TABLE Table_name SET (LOCK_ESCALATION = < TABLE | AUTO | DISABLE > –One of those options) GO

Sie können auf die Microsoft-Dokumentation verweisen zum detaillierten Verständnis von Sperreneskalationen.

Hinweis:Sie sollten die Sperrenausweitung nicht deaktivieren, bis sie gründlich in einer niedrigeren Umgebung getestet wurde, und es wird empfohlen, sie nur von erfahrenen DBAs zu verwenden.

Schlussfolgerung

Dieser Artikel gibt einen detaillierten Überblick über SQL Server-Sperren und DMV zur Überwachung der Sperre und ihres Eskalationsprozesses. Das Sperren ist ein ganz normales Verhalten in SQL Server, und Sie sollten damit vertraut sein, um zu verstehen, wie mehrere Transaktionen funktionieren, simulieren und konsistente Daten bereitstellen.