Sie sind auf Seite 1von 25

Oracle

Sperrkonzept

H.-G. Hopf

Georg-Simon-Ohm Fachhochschule Nürnberg

Datenbank Sperrkonzept / 1 ©Η.− G.Hopf / 11.02.2001


Probleme beim Ressourcen-Zugriff

z Lost-Update Problem
z Inconsistent Analysis (dirty read)
Problem

Datenbank Sperrkonzept / 2 ©Η.− G.Hopf / 11.02.2001


Probleme beim Ressourcen-Zugriff

z Lost-Update Problem
Zwei Benutzer greifen mit zwei
Transaktionen unabhängig lesend
auf einen Tabellenwert zurück.Die
eine Transaktion ändert den Wert
auf W1, die andere Transaktion
ändert den Wert gerade
modifizierten Wert auf w2, ohne
die Modifikation der ersten
Transaktion zu berücksichtigen.
Damit ist der Wert w1 verloren.

Datenbank Sperrkonzept / 3 ©Η.− G.Hopf / 11.02.2001


Probleme beim Ressourcen-Zugriff
z Inconsistent Analysis (dirty read)
Problem
Eine Transaktion greift lesend eine
andere Transaktion greift
schreibend auf eine Tabelle zu.
Die lesende Transaktion kann jetzt
Datensätze lesen,
» Die durch die 2. Transaktion
ungeändert bleiben
» Die nach dem Lesen durch die
Transaktion 2 geändert werden,
» Die vor dem Lesen schon durch die
zweite Transaktion geändert wurden.
z Damit ist das Leseergebnis
inkonsistent
Datenbank Sperrkonzept / 4 ©Η.− G.Hopf / 11.02.2001
Sperrkonzept

z Um das Entstehen eines


inkonsistenten Datenbank-
Zustandes durch gleichzeitigen
Zugriff mehrere User zu
verhindern, muss ein DBS
geeignete Sperrmechanismen und
Sperrverfahren anbieten.

Datenbank Sperrkonzept / 5 ©Η.− G.Hopf / 11.02.2001


Sperrkonzept

z Sperrgranularität
» Tabellen Sperren
die gesamte Tabelle, in der sich die
zu modifizierenden Datensätze
befinden, wird gesperrt.
» DB-Block-Sperren
alle DB-Blöcke, in denen sich zu
modifizierende Datensätze befinden,
werden gesperrt
» Datensatz-Sperren
nur von Änderungen betroffene
Datensätze werden gesperrt
Datenbank Sperrkonzept / 6 ©Η.− G.Hopf / 11.02.2001
Sperrkonzept

z LOCK TABLE Syntax

» LOCK TABLE Tabellenname


IN Modus [NOWAIT]

Datenbank Sperrkonzept / 7 ©Η.− G.Hopf / 11.02.2001


Sperrkonzept

z Sperr-Modi:
» EXCLUSIV Mode (X):
Die Tabelle wird exklusiv gesperrt.
– Tabelleninhalte können nur vom
sperrenden Prozess modifiziert werden;
– Die Tabelle kann von anderen Prozessen
abgefragt werden, andere Aktivitäten
(z.B. Modifizieren, Sperren) sind nicht
gestattet.

Datenbank Sperrkonzept / 8 ©Η.− G.Hopf / 11.02.2001


Sperrkonzept

z Sperr-Modi:
» SHARE Mode (S):
Die Tabelle ist im READ ONLY-Modus
gesperrt
– es kann konkurrierend gelesen werden;
– eine Änderung der Tabelleninhalte ist
nicht möglich.

Datenbank Sperrkonzept / 9 ©Η.− G.Hopf / 11.02.2001


Sperrkonzept

z Sperr-Modi:
» ROW EXCLUSIVE Mode (RX):
Beliebige Prozesse können
gleichzeitig voneinander
unterschiedliche Datensätze mit DML-
Kommandos bearbeiten.
– Die Sperre erfolgt auf Datensatzebene.
– Es kann jeweils ein Datensatz von einem
Prozess exklusiv gesperrt werden.

Datenbank Sperrkonzept / 10 ©Η.− G.Hopf / 11.02.2001


Sperrkonzept

z Sperr-Modi:
» ROW SHARE Mode (RS)
(SHARE UPDATE Mode):
Konkurrierende Zugriffe auf die
Tabelle sind möglich; andere
Prozesse können S, RS und RX
Sperren setzen;

Datenbank Sperrkonzept / 11 ©Η.− G.Hopf / 11.02.2001


Sperrkonzept

z Sperr-Modi:
» SHARE ROW EXCLUSIVE MODE
(SRX):
Der sperrende Prozess kann die
gesamte Tabelle einsehen und
Datensatzweise exklusiv sperren;
– Anderen Prozessen wird nur erlaubt
Zeilen der Tabelle einzusehen (RS).
– Gleichzeitige Sperren auf Tabellenebene
(X, S) sind nicht möglich.

Datenbank Sperrkonzept / 12 ©Η.− G.Hopf / 11.02.2001


Sperrkonzept

z Umgang mit aktiven Sperrungen:


» NOWAIT:
Bei Angabe dieser Option wird im Fall
einer vorliegenden Sperrung nicht auf
die Freigabe gewartet, sondern die
angeforderte Sperrung aufgegeben.
Ohne die Option wird auf das
Freigeben der angeforderten
Ressource gewartet.

Datenbank Sperrkonzept / 13 ©Η.− G.Hopf / 11.02.2001


Sperrkonzept

z Technische Realisierung
» Jede Transaktion wird durch eine
eindeutige Transaktionsnummer
SCN(System Change/Commit
Number) identifiziert.
» Jede aktive Transaktion wird in die
sog. Transaktionstabelle eingetragen.
» Jeder von der Transaktion betroffene
Datensatz wird mit der
Transaktionsnummer SCN markiert.

Datenbank Sperrkonzept / 14 ©Η.− G.Hopf / 11.02.2001


Sperrkonzept
Transaktion Transaktions- 1. Jede Transaktion
tabelle bekommt eindeutige
UPDATE table SCN
SET ... 3999 2. Jede aktive Trans-
4000 aktion wird in Trans-
SCN 4001 aktionstabelle
Transaktion eingetragen
= 3999 3. Jeder von der Trans-
aktion betroffene
3999267839994001 Datensatz wird durch
die SCN gekenn-
zeichnet
4. Ein Datensatz ist
gesperrt, wenn die
Datensatz-SCN mit
Datensatz einer SCN aus der
Transaktionstabelle
DB-Block übereinstimmt.
Datenbank Sperrkonzept / 15 ©Η.− G.Hopf / 11.02.2001
Sperrkonzept

z Technische Realisierung
» Ein Datensatz ist gesperrt, wenn die
dem Datensatz zugeordnete
Transaktionsnummer mit einer
Transaktionsnummer der
Transaktionstabelle übereinstimmt.

Datenbank Sperrkonzept / 16 ©Η.− G.Hopf / 11.02.2001


Multi Version Read Consistency

z Multi Version Read Consistency


Modell
» Voraussetzungen:
Anwendung des
Datensatzsperrverfahrens nach dem
ROW-EXLUSIVE-Mode Sperrkonzept:
– Alle Transaktionen werden fortlaufend
durchnummeriert (Transaktionsnummer).
– Alle aktiven Transaktionen werden in der
sog. Transaktionstabelle geführt.
– Für jeden Datensatz wird die
Transaktionsnummer der letzten
ändernden Transaktion vermerkt.

Datenbank Sperrkonzept / 17 ©Η.− G.Hopf / 11.02.2001


Multi Version Read Consistency

z Multi Version Read Consistency


Modell
» Um konsistente Datensätze zu
erhalten, geht man auf den Zustand
vor dem Beginn der aktiven
Transaktionen zurück.
» Rollback-Segmente enthalten den
Zustand der Tabellendaten, bevor
Änderungen im Rahmen einer
Transaktion durchgeführt wurden.

Datenbank Sperrkonzept / 18 ©Η.− G.Hopf / 11.02.2001


Multi Version Read Consistency
Transaktion1 Transaktion2
UPDATE table SELECT FROM
SET ... table...

SCN
Transaktion1
= 3999 Rollback-
2200 2000 Segment

Bei Änderungen Die lesende


werden die 3300 3000 Transaktion
geänderten Werte greift
im Rollback gegebenenfalls
Segment zwischen- 2200 2000 auf Rollback-
gespeichert. Segment-Werte
zurück

DB-Block
Datenbank Sperrkonzept / 19 ©Η.− G.Hopf / 11.02.2001
Multi Version Read Consistency

z Multi Version Read Consistency


Modell
» Abarbeitung einer Lese-Transaktion:
– Eine lesende Transaktion greift auf Werte
aus den Rollback-Segment zurück, wenn
eine Änderung im Vergleich zum
Konsistenzzeitpunkt festgestellt wird.
– Konsistenzzeitpunkt:
Der Konsistenzzeitpunkt liegt für die
Lese-Transaktion vor dem Beginn aller
zum Startzeitpunkt der Lese-Transaktion
aktiven Transaktionen.

Datenbank Sperrkonzept / 20 ©Η.− G.Hopf / 11.02.2001


Multi Version Read Consistency

z Multi Version Read Consistency


Modell
» Feststellung einer Änderung:
– Ist die dem Datensatz zugeordnete
Transaktionsnummer größer als die
Transaktionsnummer der Lese-
Transaktion, hat sich das Datenelement
seit dem Beginn der Lesetransaktion
verändert.
– Ist die dem Datensatz zugeordnete
Transaktionsnummer in der
Transaktionstabelle der aktiven
Transaktionen enthalten, so sind
möglicherweise Änderungen
vorgenommen worden.
Datenbank Sperrkonzept / 21 ©Η.− G.Hopf / 11.02.2001
Multi Version Read Consistency
Transaktion1 Transaktions- Transaktion2
tabelle
UPDATE table SELECT FROM
SET ... 3999 table...
4000
SCN 4001
Transaktion1
= 3999

3999267839994001 Ein Datensatz hat


Ein Datensatz hat sich seit dem
sich seit Konsistenzzeitpunkt
Lesebeginn 3300 3000 geändert, wenn die
geändert, wenn die 2200 1500 Datensatz-SCN in
Datensatz-SCN der
größer als die
2200 2000 Transaktionstabelle
Lese-Transaktions- 3300 3000 als aktive
SCN ist. Transaktion
DB-Block vermerkt ist
Datenbank Sperrkonzept / 22 ©Η.− G.Hopf / 11.02.2001
Multi Version Read Consistency
Transaktion1 Transaktions- Transaktion2
tabelle
UPDATE table SELECT FROM
SET ... 3999 table...
4000
SCN 4001
Transaktion1
= 3999

3999267839994001

3300 3000
2200 1500
2200 2000
3300 3000

Datenbank Sperrkonzept / 23 ©Η.− G.Hopf / 11.02.2001


Multi Version Read Consistency

z Für mehrere Leseoperationen auf


evtl. mehreren Tabellen

» SET TRANSACTION READ ONLY

Datenbank Sperrkonzept / 24 ©Η.− G.Hopf / 11.02.2001


Multi Version Read Consistency

z Multi Version Read Consistency


Modell
» Rollback-Segmente müssen solange
vorgehalten werden, bis
Änderungstransaktionen beendet sind
und keine Lese-Transaktion mehr
aktiv ist.

Datenbank Sperrkonzept / 25 ©Η.− G.Hopf / 11.02.2001