Startseite   |  Site map   |  A-Z artikel   |  Artikel einreichen   |   Kontakt   |  
   

informatik artikel (Interpretation und charakterisierung)

Fehler

Mp3

Lösungen zu den datenbankproblemen:


1. Java
2. Viren



1.1. Datenspeicher ist defekt:r / r /> 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 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.


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


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




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

 
 





Datenschutz
Top Themen / Analyse
Die Anwendungsschicht (Application Layer)
Texturen:
Löschen einzelner Seiten im Cache
Linker?
Das Internet-Protokoll (IP)
Wichtige Sprachkonzepte
Multiport Repeater (Hubs)
Pentium II - Celeron
Array in Delphi
Speichermedien - Cd-rom






Datenschutz
Zum selben thema
Netzwerk
Software
Entwicklung
Windows
Programm
Unix
Games
Sicherheit
Disk
Technologie
Bildung
Mp3
Cd
Suche
Grafik
Zahlung
Html
Internet
Hardware
Cpu
Firewall
Speicher
Mail
Banking
Video
Hacker
Design
Sprache
Dvd
Drucker
Elektronisches
Geschichte
Fehler
Website
Linux
Computer
A-Z informatik artikel:
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z #

Copyright © 2008 - : ARTIKEL32 | Alle rechte vorbehalten.
Vervielfältigung im Ganzen oder teilweise das Material auf dieser Website gegen das Urheberrecht und wird bestraft, nach dem Gesetz.