Referat:

Concurrency-Problem

(Fortsetzung von DB-Problemen)

Lösungen zu DB-Problemen

(außer Lösungen zu den Concurrency-Problemen)

Inhaltsverzeichnis

1. Fehlermöglichkeiten (WH):

1.1. Das Concurrency-Problem:

1.1.1. Das lost update Problem:

1.1.2. Das uncommitted dependency Problem:

1.1.3. Das inconsistent analysis Problem:

2. Lösungen zu den Datenbankproblemen:

2.1. Datenspeicher ist defekt:                  

2.2. Applikation ist abgestürzt:              

2.3. Datenbanksystem oder Betriebssystem ist abgestürzt:     

2.4. Programmfehler (kein Absturz):   

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: Andern, 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" Anderungen verloren.

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:

In diesem Beispiel erhält das Programm A falsche Ergebnisse, da die von Programm B zum Zeitpunkt t1 gemachten Anderungen zum Zeitpunkt t3 wieder zurückgenommen werden.

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

Konto 1 = 10 Konto 2 = 80 S = 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.

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 Anderung (für Rollback benötigt um alten Zustand wiederherstellen zu können)

- After Image:

Zustand des neuen Datensatzes nach der Anderung (wird für Forward Recovery benötigt)

- Userprozessdaten:

Um später die Anderungen 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 Anderns

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 a1

a2 (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 Anderungen 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 Anderungen, die möglicherweise nicht abgeschlossen wurden. Der User kann die Anderungen nicht mehr zurücknehmen, da seine Applikation abgestürzt ist.

In einem einfachen System wird der Operator verständigt, der durch entsprechende Befehle die Anderungen des jeweiligen Prozesses zurücknimmt. Das System liest dann im Logfile nach, welche Anderungen seit dem letzten Synchpoint (Momentaufnahme des Systems) durch den User verursacht wurden und macht diese Anderungen 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.