Dr. Heidrun BethgeDatenbanken II1 Transaktionen. Dr. Heidrun BethgeDatenbanken II2 Bsp. für...
-
Upload
berlin-rasch -
Category
Documents
-
view
113 -
download
1
Transcript of Dr. Heidrun BethgeDatenbanken II1 Transaktionen. Dr. Heidrun BethgeDatenbanken II2 Bsp. für...
Dr. Heidrun Bethge Datenbanken II 1
Transaktionen
Dr. Heidrun Bethge Datenbanken II 2
Bsp. für Notwendigkeit von Transaktionen
INSERT INTO auftrag (aufnr, kundennr) VALUES (111,333);
INSERT INTO auftragdetails (aufnr, artikelnr, anzahl) VALUES (111,3456,4);
UPDATE artikel SET anzahl_auf_lager=234 WHERE artikelnr=3456;
Dr. Heidrun Bethge Datenbanken II 3
Was ist eine Transaktion?
• Eine Transaktion ist eine ununterbrechbare Folge von DML-Befehlen, welche die Datenbank von einem logisch konsistenten Zustand in einen neuen logisch konsistenten Zustand überführt.
• Die Datenbank braucht nur vor und nach einer Transaktion in einem zulässigen Zustand zu sein.
Dr. Heidrun Bethge Datenbanken II 4
ACID-Prinzip• Atomicity: Atomarität. Eine Transaktion wird
entweder ganz oder gar nicht ausgeführt.• Consistency: Konsistenz. Transaktionen sind die
Einheiten der Integritätsüberwachung. Nach einer Transaktion müssen alle Integritätsbedingungen erfüllt sein.
• Isolation: Parallel laufende Transaktionen sind isoliert und können sich nicht gegenseitig be-einflussen. Ein Nutzer sollte immer den Eindruck haben, dass er allein mit der DB arbeitet.
• Durability: Dauerhaftigkeit. Sobald eine Transaktion ihre Änderungen freigegeben hat, muss das System das Überleben dieser Änderungen trotz beliebiger (erwarteter) Fehler garantieren (Persistenz).
Dr. Heidrun Bethge Datenbanken II 5
Transaktionsbefehle• BEGIN / BOT (Begin of Transaction):
Beginn einer Transaktion. Wird von einigen DBMS implizit gesetzt.
• COMMIT / EOT (End of Transaction):Die Transaktion soll erfolgreich beendet werden.
• ROLLBACK / ABORT: Die Transaktion wird abgebrochen. Alle bereits in ihr durchgeführten Aktionen werden rückgängig gemacht.
Ende der Transaktion
Für das Ende einer Transaktion gibt es nur zwei Möglichkeiten:
• COMMIT; Erfolgreich beendet.
• ROLLBACK;Nicht erfolgreich beendet.
Dr. Heidrun Bethge Datenbanken II 6
Dr. Heidrun Bethge Datenbanken II 7
Abschluss von Transaktionen• Der User setzt ein COMMIT oder ROLLBACK selbst
ab.• Vor und nach jedem DDL-Befehl wie z.B. CREATE,
ALTER, DROP, RENAME wird vom DBMS ein implizites COMMIT abgesetzt.
• Hardware- oder Laufzeitfehler können zu einem Rollback führen.
• Das DBMS kann Transaktionen zurückrollen, wenn sie z.B. bei Beendigung Konsistenzbedingungen verletzen oder in ein Deadlock laufen.
• wird eine neue Transaktion eingeleitet, während eine andere noch offen ist, so wird die offene Transaktion automatisch durch COMMIT abgeschlossen.
Dr. Heidrun Bethge Datenbanken II 8
Automatische Sperren bei Transaktionen
• Ist eine Transaktion aktiv, kann eine andere Transaktion keine Operationen durchführen, die Datensätze der aktiven Transaktion betreffen. Dies gilt, sofern auf diesen Datensätzen von der offenen Transaktion bereits geschrieben wurde. Diese Kommandos werden blockiert.
• Jedoch: Standard-Sperrlevel von DBMS erfüllen NICHT vollständig das ACID-Prinzip! → Sperren von Hand setzen.
Dr. Heidrun Bethge Datenbanken II 9
Transaktion 1 Transaktion 2select * from testdaten;
update testdaten set wert=11
where id=1;
select * from testdaten; select * from testdaten;
update testdaten set wert = 22 where id=1;
commit;
select * from testdaten; select * from testdaten;
rollback;
select * from testdaten; select * from testdaten;
Beispiel Transaktion
Dr. Heidrun Bethge Datenbanken II 10
Transaktionen im Mehrbenutzerbetrieb
• Fehler durch gleichzeitigen Zugriff mehrerer Benutzer auf dieselben Daten
• mehrere Transaktionen laufen parallel und behindern sich ggf. gegenseitig
• → nebenläufige konkurrierende Prozesse
Dr. Heidrun Bethge Datenbanken II 11
Inkonsistentes Lesen: Nonrepeatable Read
• X = A + B +C am Ende der Transaktion T1• Integritätsbedingung A + B + C = 0
Lesen inkonsistenter ZuständeIntegritätsbedingung X + Y = 0
Dr. Heidrun Bethge Datenbanken II 12
T1 T2
read(X,x);
read(Y,y);
x=x+1;
write(X,x);
y=y-1;
read(X);
read(Y);
write(Y,y);
commit;
Dr. Heidrun Bethge Datenbanken II 13
Dirty Read
• Lesen nicht freigegebener, ungültiger Daten
Dr. Heidrun Bethge Datenbanken II 14
Verlorengegangenes Ändern: Lost Update
Dr. Heidrun Bethge Datenbanken II 15
Mehrbenutzer-Anomalie• Integritätsbedingung A = B
Dr. Heidrun Bethge Datenbanken II 16
Das Phantom-Problem
Dr. Heidrun Bethge Datenbanken II 17
Probleme bei Cursor-Referenzen
Transaktions-Sperrlevel in SQLSperrlevel der nächsten Transaktion:
set transaction
[read only, |read write,]
[isolation level
read uncommitted, |
read committed, |
repeatable read, |
serializable]
Sperrlevel innerhalb dieser Session:
alter session set isolation_level serializable;
Sperrlevel• read uncommitted
Erlaubt Lesen nicht committeter Daten.Read only.
• read committedErlaubt nur Lesen von committeten Daten. Non Repeatable Read-Problem besteht.
• repeatable readNon Repeatable Read-Problem behoben, jedoch Phantom-Problem nicht.
• serializableStärkste Stufe, garantiert Serialisierbarkeit.ACID-Prinzip wird erfüllt.
Dr. Heidrun Bethge Datenbanken II 19
Auswirkungen der Isolationsstufen
Level dirty read non repeatable read / lost update
Phantomproblem
read uncommitted
ist möglich
ist möglich ist möglich
read committed
nein ist möglich ist möglich
repeatable read
nein nein ist möglich
serializable nein nein nein
Dr. Heidrun Bethge Datenbanken II 21
Sperren• shared lock: read lock (S)• exclusive lock: write lock (X)
Kompatibilitätsmatrix
X S -
X N N J
S N J J
- J J J
von T1 gehaltene Sperre
von
T2
gepl
ante
S
perr
e
Dr. Heidrun Bethge Datenbanken II 22
Regeln für Sperren• Eine Transaktion, welche einen Datensatz lesen will,
muss diesen zunächst mit einem S- oder X-Lock versehen.
• Eine Transaktion, welche einen Datensatz ändern will, muss diesen zunächst mit einem X-Lock versehen.
• Ein S-Lock kann durch die gleiche Transaktion durch ein X-Lock erweitert werden.
• Liegt auf einem Objekt ein X-Lock, kann durch die gleiche Transaktion kein S-Lock auf dieses Objekt gesetzt werden.
• Wird einer Transaktion A eine Sperre verweigert, da bereits anderweitig eine Sperre besteht, so geht A in Wartestellung (Wartezeit ist begrenzt).
• Sperren werden in der Regel bis zum Ende der Transaktion gehalten. COMMIT löst alle bestehenden Sperren.
Dr. Heidrun Bethge Datenbanken II 23
Sperren in DBMS• X-Lock wird vom DBMS automatisch beim Schreiben
auf die zu ändernden Datensätze gesetzt.• SELECT setzt keine Sperren.• SELECT ... FOR UPDATE
versieht die Ergebnisdatensätze mit einem X-Lock und den Rest der Tabelle mit einem S-Lock.
• Lesezugriffe sind auch dann möglich wenn auf den Daten ein S- oder X-Lock liegt.
• LOCK TABLE tabelle IN SHARE MODE• LOCK TABLE tabelle IN EXCLUSIVE MODE• Datenbanksysteme unterscheiden in der Praxis noch
weitere Sperrtypen.
Dr. Heidrun Bethge Datenbanken II 24
Beispiel Sperren IT1 T2
write(A)
read(A)
rollback
T1 T2
X-Lock Awrite(A)
Anfrage: S-Lock A(read(A))
wait rollback(löst X-Lock(A))
resume: S-Lock(A)read(A)
Dirty Read
Dr. Heidrun Bethge Datenbanken II 25
Beispiel Sperren II
T1 T2
read(A)
read(B)
write(B)
write(A)
T1 T2
S-Lock(A)read(A)
S-Lock(B)read(B)
X-Lock(B)(write(B))
wait X-Lock(A)(write(A))
wait wait
vorher: lost updatenachher: deadlock-> eine der beiden Transaktionen bekommt rollback„deadlock victim“
Dr. Heidrun Bethge Datenbanken II 26
DEADLOCKS• Deadlocks sind Fälle, in denen sich zwei
oder mehr Prozesse gegenseitig blockieren und jeder auf das Ende der Transaktion eines anderen Prozesses wartet.
• Das DBMS erkennt automatisch Deadlock-Situationen und führt bei dem Prozess, der den Deadlock ausgelöst hat, ein ROLLBACK aus. (Oracle: nur der letzte Transaktionsschritt wird rückgängig gemacht)
Dr. Heidrun Bethge Datenbanken II 27
Beispiel DEADLOCKTransaktion 1 Transaktion2
sperrt A sperrt B
versucht B zu sperren versucht A zu sperren
begin; begin;
select * from testdaten select * from testdaten
where id=1 where id=2
for update of wert; for update of wert;
update testdaten update testdaten
set wert=100 set wert=50
where id=2; where id=1;