Antwort.

Geschichte der Frage

Mit dem Aufkommen von Mehrbenutzerdatenbanken entstand die Notwendigkeit, gleichzeitige Änderungen an denselben Daten zu beschränken. Dies führte zur Entwicklung verschiedener Sperrmechanismen (Lock-Management), die parallele Änderungen verhindern und die Integrität der Daten unterstützen.

Problem

Ohne Zugangskontrolle können gleichzeitige Vorgänge zu Beschädigungen oder Verlusten von Daten führen: Zum Beispiel, wenn zwei Transaktionen gleichzeitig eine Zeile aktualisieren und die Änderungen einer Transaktion verloren gehen. Unzureichend strenge Sperren führen zu Wettbewerbsproblemen (Race Conditions), während übermäßige Sperren zu Leistungseinbußen (Deadlocks, Contention) führen.

Lösung

In modernen DBMS gibt es Sperrlevel (Zeilenebene, Seitenebene, Tabellenebene) und verschiedene Modi (shared, exclusive, update). Der Programmierer kann dies über Transaktionsisolationseinstellungen und explizite Sperrbefehle (z. B. SELECT ... FOR UPDATE) steuern.

Beispielcode:

-- Sperre der Zeile bis zum Abschluss der Transaktion
BEGIN TRANSACTION;
SELECT * FROM users WHERE id = 1 FOR UPDATE;
UPDATE users SET name = 'Neuer Name' WHERE id = 1;
COMMIT;

Wichtige Merkmale:

Granularität der Sperre (Zeile, Seite, Tabelle)
Explizite und implizite Sperren (durch Transaktionen und spezielle Anweisungen)
Einfluss des Isolationslevels auf das Sperrschema

Fangfragen.

Was ist der Unterschied zwischen einer Lesesperre (shared lock) und einer Schreibsperre (exclusive lock)?

Eine Shared Lock erlaubt mehreren Transaktionen, die Daten gleichzeitig zu lesen, erlaubt jedoch keine Änderungen. Eine Exclusive Lock erlaubt nur einer Transaktion, die Daten zu ändern, während allen anderen der Zugriff verwehrt ist.

Kann ein SELECT-Befehl eine Sperre verursachen?

Normalerweise verursacht SELECT keine Sperren, aber wenn SELECT ... FOR UPDATE oder bei hohem Isolationslevel (z. B. SERIALIZABLE) verwendet wird, kann das DBMS Zeilen sperren.

Beispielcode:

SELECT * FROM products WHERE id = 10 FOR UPDATE;

Schützen Sperren immer vor "verlorenen Updates"?

Nein, wenn das Sperr- oder Isolationslevel falsch gewählt wird, kann ein "lost update" auftreten – bei dem die Änderungen einer Transaktion aufgrund einer anderen verloren gehen. Es ist wichtig, die Mechanismen zur Verwaltung der Konkurrenz sorgfältig auszuwählen.

Typische Fehler und Anti-Muster

Falsche Wahl des Isolationslevels (zu niedrig oder zu hoch)
Unzureichend explizite Sperren bei kritischen Abfragen
Missbrauch globaler (Tabellenebene) Sperren, was zu Leistungsverlusten führt
Nichtfreigabe von Sperren aufgrund unerledigter Transaktionen

Beispiel aus dem Leben

Negativer Fall

In der Analytik aktualisieren zwei Programme gleichzeitig die Bestellstatus. Um die Geschwindigkeit zu erhöhen, wurde absichtlich das Isolationslevel READ UNCOMMITTED gewählt, um Zeilen nicht zu sperren. Dies führte zu Konflikten und "verlorenen" Updates, einige Daten wurden beschädigt.

Vorteile:

Gute Geschwindigkeit zu Beginn

Nachteile:

Verlust/Beschädigung von Schlüssel- daten
Schwierigkeiten bei der Wiederherstellung

Positiver Fall

Im Vertrieb wurden kritische Stellen in TRANSACTION + SELECT ... FOR UPDATE eingekapselt. Die Lese- und Aktualisierungsoperationen wurden auf Zeilenebene getrennt.