Sperrmodi
Aktualisiert: 05. Dezember 2005
Das Microsoft SQL Server-Datenbankmodul sperrt Ressourcen mithilfe unterschiedlicher Sperrmodi, die bestimmen, wie gleichzeitige Transaktionen auf Ressourcen zugreifen können.
Die folgende Tabelle zeigt die Ressourcen-Sperrmodi, die das Datenbankmodul verwendet.
| Sperrmodus | Beschreibung |
|---|---|
S (Shared) |
Wird für Lesevorgänge verwendet, die Daten nicht ändern oder aktualisieren, wie z. B. SELECT-Anweisungen. |
U (Update) |
Wird für Ressourcen verwendet, die aktualisiert werden können. Verhindert eine gängige Form des Deadlocks, die auftritt, wenn mehrere Sitzungen Ressourcen lesen, sperren und anschließend möglicherweise aktualisieren. |
X (Exclusive) |
Wird bei Datenänderungen wie INSERT-, UPDATE- oder DELETE-Vorgängen verwendet. Stellt sicher, dass nicht mehrere Aktualisierungen an derselben Ressource gleichzeitig vorgenommen werden können. |
Intent |
Wird verwendet, um eine Sperrhierarchie zu erstellen. Es gibt folgende Typen von beabsichtigten Sperren: beabsichtigte gemeinsame Sperre (Intent Shared, IS), beabsichtigte exklusive Sperre (Intent Exclusive, IX) und gemeinsame Sperre mit beabsichtigter exklusiver Sperre (Shared With Intent Exclusive, SIX). |
Schema |
Wird beim Ausführen von Vorgängen verwendet, die vom Schema einer Tabelle abhängen. Es gibt folgende Typen von Schemasperren: Schemaänderungssperre (Sch-M) und Schemastabilitätssperre (Sch-S). |
BU (Bulk Update) |
Wird beim Massenkopieren von Daten in eine Tabelle verwendet, wenn der TABLOCK-Hinweis angegeben ist. |
Schlüsselbereich |
Schützt den von einer Abfrage gelesenen Zeilenbereich, wenn die serialisierbare Transaktionsisolationsstufe verwendet wird. Stellt sicher, dass keine anderen Transaktionen Zeilen einfügen können, die von den Abfragen der serialisierbaren Transaktion berücksichtigt werden können, falls diese erneut ausgeführt würden. |
Gemeinsame Sperren
Gemeinsame Sperren (S) ermöglichen, dass Transaktionen eine Ressource gleichzeitig lesen können (SELECT), wenn die Steuerung durch eingeschränkte Parallelität aktiviert ist. Weitere Informationen finden Sie unter Parallelitätskontrolltypen. Andere Transaktionen können die Daten nicht ändern, während gemeinsame Sperren (S) für die Ressource eingerichtet sind. Gemeinsame Sperren (S) einer Ressource werden aufgehoben, sobald der Lesevorgang abgeschlossen ist, es sei denn, die Isolationsstufe der Transaktion wird auf REPEATABLE READ oder höher festgelegt oder ein Sperrhinweis wird verwendet, um gemeinsame Sperren (S) für die Dauer der Transaktion beizubehalten.
Aktualisierungssperren
Aktualisierungssperren (Update, U) verhindern eine häufige Form von Deadlocks. Bei REPEATABLE READ- oder SERIALIZABLE-Transaktionen liest die Transaktion Daten, wozu sie eine gemeinsame Sperre (S) für die Ressource (Seite oder Zeile) einrichtet, und ändert anschließend die Daten, was eine Konvertierung der Sperre in eine exklusive Sperre (X) erfordert. Wenn zwei Transaktionen eine gemeinsame Sperre für eine Ressource einrichten und anschließend versuchen, Daten gleichzeitig zu aktualisieren, versucht die erste Transaktion, die Sperre zu einer exklusiven Sperre (X) zu konvertieren. Diese Konvertierung muss aufgeschoben werden, da der Modus der exklusiven Sperre der einen Transaktion nicht kompatibel mit dem Modus der gemeinsamen Sperre der anderen Transaktion ist. Es ergibt sich ein Sperrenwartevorgang. Die zweite Transaktion versucht nun ebenfalls, eine exklusive Sperre (X) für die Aktualisierung einzurichten. Da beide Transaktionen das Konvertieren in eine exklusive Sperre (X) versuchen und darauf warten, dass die andere Transaktion die gemeinsame Sperre aufhebt, kommt es zu einem Deadlock.
Um dieses potenzielle Deadlockproblem zu vermeiden, werden Aktualisierungssperren (U) verwendet. Es kann jeweils nur eine Transaktion eine Aktualisierungssperre (U) für eine Ressource einrichten. Wenn eine Transaktion eine Ressource ändert, wird die Aktualisierungssperre (U) in eine exklusive Sperre (X) konvertiert.
Exklusive Sperren
Exklusive Sperren (X) verhindern, dass Transaktionen gleichzeitig auf eine Ressource zugreifen. Eine exklusive Sperre (X) bewirkt, dass keine andere Transaktion Daten ändern kann. Lesevorgänge können nur mithilfe des NOLOCK-Hinweises oder der READ UNCOMMITTED-Isolationsstufe ausgeführt werden.
Datenänderungsanweisungen wie INSERT, UPDATE und DELETE setzen sowohl Änderungs- als auch Lesevorgänge voraus. Die Anweisung führt zunächst Lesevorgänge aus, um die Daten einzulesen, und anschließend die erforderlichen Änderungsvorgänge. Daher machen Datenänderungsanweisungen normalerweise sowohl gemeinsame als auch exklusive Sperren erforderlich. Eine UPDATE-Anweisung kann beispielsweise Zeilen einer Tabelle ändern, die auf einer Verknüpfung mit einer anderen Tabelle basieren. In diesem Fall fordert die UPDATE-Anweisung gemeinsame Sperren für die Zeilen in der verknüpften Tabelle an, sowie exklusive Sperren für die zu aktualisierenden Zeilen.
Beabsichtigte Sperren
Das Datenbankmodul verwendet beabsichtigte Sperren, um das Platzieren einer gemeinsamen (S) oder exklusiven Sperre (X) auf eine Ressource zu schützen, die sich weiter unten in der Sperrhierarchie befinden. Die Bezeichnung 'beabsichtige Sperre' bedeutet, dass beabsichtigte Sperren vor Sperren auf untergeordneten Ebenen eingerichtet werden, und damit die Absicht ausdrücken, Sperren auf untergeordneten Ebenen zu platzieren.
Beabsichtigte Sperren werden aus zwei Gründen verwendet:
- Um zu verhindern, dass andere Transaktionen Ressourcen übergeordneter Ebenen ändern und damit die Sperren untergeordneter Ebenen ungültig werden.
- Um die Effizienz des Datenbankmodul beim Erkennen von Sperrkonflikten auf einer höheren Granularitätsebene zu steigern.
Eine beabsichtigte gemeinsame Sperre auf Tabellenebene wird also beispielsweise angefordert, bevor gemeinsame Sperren (S) für Seiten oder Zeilen in dieser Tabelle angefordert werden. Durch Festlegen einer beabsichtigten Sperre auf Tabellenebene wird verhindert, dass andere Transaktionen anschließend eine exklusive Sperre (X) für die Tabelle einrichten können, die diese Seite enthält. Beabsichtigte Sperren tragen zur Leistungsverbesserung bei, da das Datenbankmodul beabsichtige Sperren nur auf Tabellenebene überprüft, um zu bestimmen, ob eine Transaktion für diese Tabelle problemlos eine Sperre einrichten kann. Dadurch ist es nicht mehr erforderlich, jede Zeilen- oder Seitensperre in der Tabelle zu überprüfen, um zu ermitteln, ob eine Transaktion die gesamte Tabelle sperren kann.
Beabsichtigte Sperren umfassen beabsichtigte gemeinsame (Intent Shared, IS), beabsichtigte exklusive (Intent Exclusive, IX) und gemeinsame mit beabsichtigten exklusiven (Shared With Intent Exclusive, SIX) Sperren.
| Sperrmodus | Beschreibung |
|---|---|
Beabsichtigte gemeinsame Sperre (IS) |
Schützt angeforderte oder eingerichtete gemeinsame Sperren bestimmter (aber nicht aller) Ressourcen untergeordneter Ebenen in der Hierarchie. |
Beabsichtigte exklusive Sperre (IX) |
Schützt angeforderte oder eingerichtete exklusive Sperren bestimmter (aber nicht aller) Ressourcen untergeordneter Ebenen in der Hierarchie. IX ist eine Obermenge von IS und schützt auch vor Anforderung gemeinsamer Sperren auf Ressourcen untergeordneter Ebenen in der Hierarchie. |
Gemeinsame Sperre mit beabsichtigter exklusiver Sperre (SIX) |
Schützt angeforderte oder eingerichtete gemeinsame Sperren aller Ressourcen untergeordneter Ebenen in der Hierarchie sowie beabsichtigte exklusive Sperren bestimmter (aber nicht aller) Ressourcen untergeordneter Ebenen in der Hierarchie. Gleichzeitige Sperren des Typs IS auf der Ressource der obersten Ebene sind zugelassen. So werden beispielsweise bei einer Sperre des Typs SIX für eine Tabelle auch beabsichtigte exklusive Sperren für die zu ändernden Seiten sowie exklusive Sperren für die zu ändernden Zeilen eingerichtet. Es kann jeweils nur eine Sperre des Typs SIX pro Ressource eingerichtet werden, durch die Aktualisierungen an der Ressource durch andere Transaktionen verhindert werden. Dennoch können andere Transaktionen Ressourcen, die sich weiter unten in der Hierarchie befinden, lesen, indem sie Sperren des Typs IS auf Tabellenebene einrichten. |
Beabsichtigte Aktualisierungssperre (Intent Update, IU) |
Schützt angeforderte oder eingerichtete Aktualisierungssperren aller Ressourcen untergeordneter Ebenen in der Hierarchie. IU-Sperren werden nur mit Seitenressourcen verwendet. IU-Sperren werden zu IX-Sperren konvertiert, wenn ein Aktualisierungsvorgang ausgeführt wird. |
Gemeinsame beabsichtigte Aktualisierungssperre (Shared Intent Update, SIU) |
Eine Kombination der Sperren vom Typ S und IU, die sich aus der separaten Einrichtung dieser Sperren und dem gleichzeitigen Beibehalten beider Sperren ergibt. Nehmen Sie beispielsweise an, eine Transaktion führt eine Abfrage mit dem PAGLOCK-Hinweis und anschließend einen Aktualisierungsvorgang aus. Die Abfrage mit dem PAGLOCK-Hinweis richtet also die S-Sperre ein, wohingegen der Aktualisierungsvorgang die IU-Sperre einrichtet. |
Exklusive beabsichtigte Aktualisierungssperre (Update intent exclusive, UIX) |
Eine Kombination der Sperren vom Typ U und IX, die sich aus dem separaten Einrichten dieser Sperren und dem gleichzeitigen Beibehalten beider Sperren ergibt. |
Schemasperren
Sperren des Typs Sch-M (Schema Modification, Schemaänderung) werden von Datenbankmodul verwendet, wenn für eine Tabelle ein DDL-Vorgang (Data Definition Language, Datendefinitionssprache) ausgeführt wird, wie etwa das Hinzufügen einer Spalte oder Löschen einer Tabelle. Während die Sch-M-Sperre besteht, werden gleichzeitige Zugriffe auf die Tabelle verhindert. Dies bedeutet, dass die Sch-M-Sperre alle externen Vorgänge blockiert, bis die Sperre aufgehoben wird.
Einige DML-Vorgänge (Data Manipulation Language), z. B. das Abschneiden von Tabellen, verhindern mithilfe von Sch-M-Sperren, dass gleichzeitige Vorgänge auf die betroffenen Tabellen zugreifen.
Datenbankmodul verwendet Sperren des Typs Sch-S (Schemastabilität) beim Kompilieren und Ausführen von Abfragen. Sch-S-Sperren blockieren keine Transaktionssperren, auch keine exklusive Sperren (X). Daher können während der Kompilierung einer Abfrage andere Transaktionen, einschließlich Transaktionen mit exklusiven Sperren (X) auf Tabellenebene, weiterhin ausgeführt werden. Gleichzeitige DDL-Vorgänge und gleichzeitige DML-Vorgänge, die Sch-M-Sperren abrufen, können für die Tabelle jedoch nicht ausgeführt werden.
Massenaktualisierungssperren
Massenaktualisierungssperren (Bulk Update, BU) werden von Datenbankmodul verwendet, wenn Daten in eine Tabelle massenkopiert werden und entweder der TABLOCK-Hinweis angegeben oder die table lock on bulk load-Tabellenoption mithilfe der gespeicherten Prozedur sp_tableoption festgelegt ist. Massenaktualisierungssperren (BU) werden verwendet, damit mehrere Threads gleichzeitig Daten in dieselbe Tabelle laden können, während sie zugleich anderen Prozessen, die keine Daten massenkopieren, keinen Zugriff auf die Tabelle gewähren.
Schlüsselbereichssperren
Beim Verwenden der SERIALIZABLE-Transaktionsisolationsstufe schützen Schlüsselbereichssperren Zeilenbereiche, die implizit in ein Recordset eingeschlossen sind und von einer Transact-SQL-Anweisung gelesen werden. Das Sperren von Schlüsselbereichen verhindert Phantomlesezugriffe. Indem die Schlüsselbereiche zwischen Zeilen geschützt werden, wird auch verhindert, dass beim Zugreifen von Transaktionen auf Recordsets Phantomeinfügungen oder -löschungen erfolgen.
Siehe auch
Konzepte
Sperrengranularität und -hierarchien
Kompatibilität von Sperren (Datenbankmodul)
Deadlocks
Cursorsperren
Schlüsselbereichssperren
Sperrhinweise
Hilfe und Informationen
Informationsquellen für SQL Server 2005
Änderungsverlauf
Version
Verlauf
05. Dezember 2005
Begriff
Definition
**Geänderter Inhalt:**Informationen zu Schemasperren wurden aktualisiert.