Erste Seite Zurück Weiter Letzte Seite Übersicht Grafik

Sperren


Notizen:

Sperren
Die unterschiedlichen Isolationsstufen werden implementiert durch unterschiedliches Sperrverhalten ("Locking") der DB.
Read uncommitted: Sperren werden – soweit möglich – gar nicht beachtet
Read committed: Es wird mit dem Lesen gewartet, bis die andere Transaktion committed hat, d.h. deren Sperren wieder aufgehoben sind.
Repeatable Read: Es wird mit dem Lesen gewartet, bis die andere Transaktion committed hat, dann wird selbst gesperrt (auch nur zum Lesen!), bis die eigene Transaktion fertig ist, d.h. auch gelesene Ressourcen werden gesperrt.
Serializable: Keinerlei gleichzeitige Zugriffe zweier Transaktionen auf dieselben Resourcen (Datenseiten, Datensätze o.ä.) werden zugelassen: Gelesene Ressourcen werden genauso wie geänderte gesperrt, dabei werden Einfügungen in die betroffenen Tabellen ebenfalls verhindert.
Durch Sperren (notwendig zur Durchsetzung der Isolationsstufen) können "Locking-Situationen" auftreten: Ein Prozess wird verzögert und muss warten, bis ein anderer Prozess Sperren wieder aufhebt (eine Ressource wieder freigibt).
Sperren können dabei 1 einzelnen Datensatz, eine "Page" der Tabelle, die ganze Tabelle, die ganze Datenbank oder das "Schema" (DB-Struktur) betreffen (Schema nur zum Anlegen/Ändern/Löschen von DB-Objekten, im Normalbetrieb nicht benötigt, außer für Temporärtabellen)
Granularität
Sperren können dabei
1 einzelnen Datensatz (sofern das DBMS das unterstützt),
1 "Page" der Tabelle (gleich großer Bereich der Festplatte, der immer als ganzes gelesen oder geschrieben wird. MS SQL Server: 8kB, postgreSQL: kompilierbar),
eine Anzahl von aufeinanderfolgenden Pages (MS SQL Server, „Extent“: 8 pages)
die ganze Tabelle,
ein „Schema“ (Teil der DB-Struktur, das einem Benutzer gehört) oder
die ganze Datenbank
betreffen
(Anm.: Sperren auf Schema-Ebene werden nur zum Anlegen/Ändern/Löschen von DB-Objekten, im Normalbetrieb nicht benötigt, außer ev. für Temporärtabellen)