Tdo-:
Referat:
Concurrency-Problem
(Fortsetzung von DB-Problemen)
Lösungen zu DB-Problemen
(außer Lösungen zu den Concurrency-Problemen)
Kat. Nr.:
Name:
05
Hohenegger
Christian
Inhaltsverzeichnis:
1. FEHLERMÖGLICHKEITEN (WH): 3
1.1. Das Concurrency-Problem: 3
1.
1.1. Das lost update Problem: 3
1.1.2. Das uncommitted dependency Problem: 4
1.
1.3. Das inconsistent analysis Problem: 4
2. LÖSUNGEN ZU DEN DATENBANKPROBLEMEN: 5
2.1. Datenspeicher ist defekt: 5
2.
2. Applikation ist abgestürzt: 6
2.3. Datenbanksystem oder Betriebssystem ist abgestürzt: 6
2.4. Programmfehler (kein Absturz): 7
Dieses TDO-Referat beinhaltet:
- Fortsetzung der Fehlermöglichkeiten (speziell die Concurrency Probleme)
- Lösungen zu den behandelten Fehlern (außer die der Concurrency-Probleme)
Fehlermöglichkeiten (WH):
· Datenspeicher ist defekt (zB: Headcrash)
· Applikation ist abgestürzt (zB: Zero Divide)
· Datenbanksystem oder Betriebssystem ist abgestürzt
· Programmfehler (zB: Rundungsfehler)
· Concurrency Problem
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
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.
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)
Das inconsistent analysis Problem:
Hier arbeitet ein Programm mit Daten, die aus einer kurzfristig inkonsistenten Datenbank kommen.
Konto 1 = 40 Konto 2 = 50 S = 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 S = 90Hier 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.
Lösungen zu den Datenbankproblemen:
Datenspeicher ist defekt:
Die Daten auf einem defekten Datenspeicher sind verloren. Gegen diesen Verlust schützt das regelmäßige Sichern der Datenbestände auf einen externen Datenträger (zB: Streamer). Es muß beachtet werden, daß die Datenbank während der Sicherung geschlossen ist (sonst erhält man eine inkonsistente Datenbanksicherung). Da eine komplette Sicherung zeit- und platzaufwendig ist und andererseits die Daten seit der letzten Sicherung verloren wären, verwendet man Logfiles.
Das Logfile ist vergleichbar mit einem Journal, in welchem laufend mitprotokolliert wird, wer, was, wann, wo in welcher Datei verändert hat. Bei Datenverlust wird zunächst die letzte Sicherung wiederhergestellt und anschließend können alle Veränderungen seit der letzten Sicherung gemäß den Einträgen im Logfile nachvollzogen werden (= Forward-Recovery)
Folgende Regeln sollten für Logfiles beachtet werden:
· Logfiles und Datenbestand, der durch das Logfile aufgezeichnet wird, niemals auf dem gleichen
Datenträger sichern.
Im Fehlerfall wären der Datenbestand und das Logfile defekt.
· Logfiles möglichst doppelt (auf zwei getrennten Platten= führen (= Dual Logging)
· Logfiles werden wie andere Daten gesichert.
Wenn ein Datensatz geändert wird, so werden im Logfile folgende Informationen gespeichert:
- Before Image:
Zustand des Datensatzes vor der Änderung (für Rollback benötigt um alten Zustand wiederherstellen zu können)
- After Image:
Zustand des neuen Datensatzes nach der Änderung (wird für Forward Recovery benötigt)
- Userprozessdaten:
Um später die Änderungen zuordnen zu können, werden noch Datum, Uhrzeit, User-ID und Prozess- ID gespeichert.
Kriterien, wie häufig gesichert werden soll:
· Größe der Datenbank
· Häufigkeit des Änderns
Generell kann man sagen, daß man jenen Teil öfters sichert, der kleiner ist; d.h. ist die Datenbank sehr groß und es wird kaum etwas geändert, so empfiehlt es sich die Logfiles in kürzeren Zeitabständen als die gesamte Datenbank zu sichern.
Ist es genau umgekehrt, so soll die Datenbank häufiger gesichert werden als die Logfiles. Wie oft Datenbestände und Logfiles zu sichern sind, hängt auch von der geforderten Wiederherstellungszeit ab.
Theoretisch könnte man mit dem Logfile alles Userprozesse genau in den Zustand versetzen, den sie vor dem Absturz hatten. Leider können meist die laufenden Programme ebenfalls an die Absturzstelle gesetzt werden.
Index-Recovery:
Gelegentlich können Fehler in den Verkettungen der Indizes auftreten. In solchen Fällen wird der Index gelöscht und neu angelegt (zusätzlich bewirkt dies eine Reorganisation).
Dieses Vorgehen ist möglich, da der Index eine redundante Speicherung der Schlüsseldaten darstellt.
Beispiel für Sicherung:
Es wurden jeweils am Beginn des Monats Sicherungsbänder angelegt. Erfolgt nun ein Absturz am 25.5.96, so muß die Datenbank wiederhergestellt werden:
b1 a1a2 (b3)
SB 1 SB 2 SB 3
b2
Zeit
1.3.
96 1.4.96 1.5.96
26.5.
96 Absturz
1. Einspielen des Sicherungsbandes 3 vom 1.5.96 (a1)
2. Einspielen des aktuellen Logfiles zur Rekonstruktion der Datenbank bis zum Zeitpunkt des Absturzes (a2)
Wenn das Sicherungsband 3 defekt ist, so ist folgendes zu tun:
1. Einspielen des Sicherungsbandes 2 vom 1.
4.96 (b1)
2. Einspielen des Logfiles vom 1.4.92 bis 1.5.
96 um dem Zustand der Datenbank am 1.5.96 wiederher stellen zu können (b2)
3. Einspielen des aktuellen Logfiles bis zum Zeitpunkt des Absturzes (b3 = a2)
Wenn das aktuelle Logfile (vom 1.5.96 bis zum 26.
5.96) defekt ist, so kann man nur noch den Zustand vom 1.5.96 wiederherstellen. Alle Änderungen vom 26.5.
96 wären somit verloren.
Applikation ist abgestürzt:
Bei diesem Problem ist der Datenspeicher physisch in Ordnung, doch er kann logisch beschädigt sein. Der Schaden besteht aus durchgeführten Änderungen, die möglicherweise nicht abgeschlossen wurden. Der User kann die Änderungen nicht mehr zurücknehmen, da seine Applikation abgestürzt ist.
In einem einfachen System wird der Operator verständigt, der durch entsprechende Befehle die Änderungen des jeweiligen Prozesses zurücknimmt. Das System liest dann im Logfile nach, welche Änderungen seit dem letzten Synchpoint (Momentaufnahme des Systems) durch den User verursacht wurden und macht diese Änderungen rückgängig (= Backward-Recovery)
In größeren Systemen überprüft das Datenbanksystem in regelmäßigen Abständen, ob noch eine Verbindung zu den Usern besteht.
Falls nicht, so wird automatisch der Recovery-Vorgang eingeleitet.
Datenbanksystem oder Betriebssystem ist abgestürzt:
Bei einem Systemabsturz, Stromausfall, ... gehen keine Daten verloren, da der Datenträger nicht beschädigt werden. Die Datenbank befindet sich somit in einem inkonsistentem Zustand, da offene Transaktionen nicht abgeschlossen wurden.
Da beim ordnungsgemäßen Öffnen und Schließen Einträge im Logfile gemacht werden, erkennt das System einen Systemabsturz,... und beginnt mit dem Recovery. Dabei wird im Logband überprüft welche Transaktionen offen waren, d.h.
für welche kein Commit vorgefunden wurde. Für diese Transaktionen wird ein Backward-Recovery durchgeführt.
Programmfehler (kein Absturz):
Programmfehler sind nur sehr schwer erkennbar (zB: Rundungsfehler). Das Suchen eines solchen Fehlers ist sehr aufwendig, da der Programmfehler bis zu seinem ersten Auftreten rückverfolgt werden muß. Ist der Programmfehler eliminiert muß die Datenbank rekonstruiert werden.
Dazu kann unter Umständen das Logfile verwendet werden, welches anzeigt, welche Daten von dem fehlerhaften Programm bearbeitet wurden.
Sicherung zurückspielen, Logfile bis zum 1. Auftreten, danach eventuell korrigiertes Logfile einspielen. Probleme liegen in der Fehlerfortpflanzung, da die fehlerhaften Daten inzwischen von anderen Programmen weiterverarbeitet wurden.
| Anmerkungen: |
| impressum | datenschutz
© Copyright Artikelpedia.com
