Concurrency-Problem

Dieses TDO - Referat beinhaltet:
- Fortsetzung der Fehlermöglichkeiten (speziell die Concurrency Probleme)
- Lösungen zu den behandelten Fehlern (außer die der Concurrency - Probleme)

1. 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

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 muss 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.

2. Lösungen zu den Datenbankproblemen

2.1. 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 muss beachtet werden, dass 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, dass 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 muss die Datenbank wiederhergestellt werden:

b1 a1
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.

2.2. 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.

2.3. 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.

2.4. 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 muss. Ist der Programmfehler eliminiert muss 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.

1393 Worte in "deutsch"  als "hilfreich"  bewertet