|
. Datenspeicher ist defekt (zB: Headcrash)
. Applikation ist abgestürzt (zB: Zero Divide)
. Datenbanksystem oder Betriebssystem ist abgestürzt
. Programmfehler (zB: Rundungsfehler)
. Concurrency Problem
1.1. Das Concurrency-Problem:
Das Concurrency-Problem tritt nur bei Multiusersystemen auf, da mehrere Benutzer bzw. Programme gleichzeitig (concurrent) Operationen auf der Datenbank ausführen. Durch den gleichzeitigen Zugriff und den damit verbundenen Operationen (zB: Ändern, Einfügen und Löschen von Daten) ergeben sich einige Nachteile. Es muß daher einen Kontrollmechanismus geben, der gleichzeitige Operationen auf die Datenbank regelt.
Es kann zwischen 3 Concurrency-Problemen unterschieden werden:
1. lost update Problem
2. uncommitted dependency Problem
3. inconsistent analysis Problem
1.1.1. Das lost update Problem:
Hierbei gehen Daten durch zeitlich verschobenen Operationen auf ein und denselben Datensatz die "älteren" Änderungen verloren.
Transaktion A Zeit Transaktion B
- -
lies Satz R t1 -
- -
- t2 lies Satz R
ändere Satz R t3 -
schreib Satz R -
- -
- t4 ändere Satz R
- t5 schreib Satz R
- -
Programm A liest zum Zeitpunkt t1 den Satz R ein. Zum Zeitpunkt t2 liest Programm B den Satz R ein. Programm A ändert Satz R, basierend auf den gelesenen Werten von t1, zum Zeitpunkt t3 und schreibt diesen zum Zeitpunkt t4. Zum Zeitpunkt t4 ändert Programm B ebenfalls den Satz R, basieren auf den gelesenen Werten von t2 (entspricht den Werten von t1) und schreibt ebenfalls. Dadurch gehen die Datenänderung von Programm A verloren (werden von B überschrieben), da das Programm B nach dem Programm A abspeichert.
1.1.2. Das uncommitted dependency Problem:
Bei diesem Problem werden Daten zunächst geändert aber kurze Zeit später wieder zurückgenommen (zB: Programmfehler, Benutzer ändert seine Meinung). Inzwischen wurden aber die modifizierten Daten von einem anderen Programm weiterverarbeitet:
Transaktion A Zeit Transaktion B
-
- t1 ändere Satz R
- -
lies Satz R t2 -
- -
- t3 Rollback
- -
In diesem Beispiel erhält das Programm A falsche Ergebnisse, da die von Programm B zum Zeitpunkt t1 gemachten Änderungen zum Zeitpunkt t3 wieder zurückgenommen werden.
Transaktion A Zeit Transaktion B
-
- t1 ändere Satz R
- -
ändere alle Sätze t2 -
- -
- t3 Rollback
- -
In diesem Beispiel gehen alle Veränderungen von Programm A verloren, da zum Zeitpunkt t3 die gesamte Datenbank zum Zeitpunkt t1 wieder hergestellt wird. (Neben dem uncommitted dependency Problem tritt hier auch das lost update Problem auf)
1.1.3. Das inconsistent analysis Problem:
Hier arbeitet ein Programm mit Daten, die aus einer kurzfristig inkonsistenten Datenbank kommen.
Konto 1 = 40 Konto 2 = 50 = 90
Transaktion A Zeit Transaktion B
- -
lies Konto 1 (Kontostand = 40) t1 -
addiere Kontostand zu Summe (=40) -
- -
- t2 lies Konto 2 (Kontostand = 50)
- addiere 30 dazu (=80)
- -
- t3 lies Konto 1 (Kontostand = 40)
- ziehe 30 ab (=10)
- -
lies Konto 2 (Kontostand = 80) t4 -
addiere Kontostand zu Summe (=120) -
Konto 1 = 10 Konto 2 = 80 = 90
Hier wird während Programm A die Summe aller Konten ermittelt, Umbuchen durch Programm B getätigt. Durch die Verschiebung des Betrages ändert sich am Gesamtsaldo nichts, dennoch stimmt die von Programm A gelieferte Summe nicht.
|
