Speicher
Aufbau des Speichers
| Speicherart | Verfügbarkeit | Dauerhaftigkeit | Zuverlässigkeit | Kosten | Geschwindigkeit | Zugriff |
|---|---|---|---|---|---|---|
| Hauptspeicher | Online | Nicht dauerhaft | Nicht sicher bei Systemabstürzen | Höher als Festplatte | Sehr schnell | Wahlfrei |
| Festplatten | Online | Dauerhaft | Zuverlässiger als Hauptspeicher | Billiger als Hauptspeicher | Langsamer als Hauptspeicher | Wahlfrei |
| Bandspeicher | Offline | Dauerhaft | Zuverlässiger als Festplatte | Erheblich billiger als Festplatte | Sehr langsam | Nur sequenziell |
| Optische Platten | Offline | Dauerhaft | Zuverlässiger als Bandspeicher | Billiger als Festplatte | Schneller als Bandspeicher | Wahlfrei |
- Festplattenspeicher wird als Sekundärspeicher bezeichnet
- Externe Speichermedien als Tertiärspeicher
Stable Memory
- Speicher, der absolut fehlerresistent ist.
- Existiert aber nicht in der Realität.
- Annährung durch geeignete Techniken wie Replikation, Gespiegelte Platten, RAID-Systeme, …
Datenbank-Recovery
DB-Recovery ist der Prozess der Wiederherstellung eines konsistenten Zustandes der DB im Falle eines Fehlers
Mögliche Fehlerfälle
| Fehlerfall | Ursache | Mögliche Folge |
|---|---|---|
| Systemabstürze | Software- oder Hardwarefehler | Verlust von Hauptspeicherinhalten |
| Medienfehler, Headcrash, unlesbares Medium | Mechanische Defekte oder Materialfehler | Teilverlust von Sekundärspeicherinhalten |
| Softwarefehler in Anwendungen | Logische Programmierfehler | Abbruch von Transaktionen |
| Naturkatastrophen (z. B. Flut, Erdbeben) | Umweltkatastrophen | Zerstörung von Speichermedien |
| Unachtsamkeit oder unabsichtliche Fehler durch Benutzer | Bedienfehler | Unbeabsichtigtes Löschen von Daten |
| Sabotage oder absichtliche Zerstörung | Böswillige Absicht | Verlust oder Zerstörung von Daten, Hardware, oder Software |
Transaktionen und Recovery
- Transakition sind Einheit des Recovery.
- Recovery-Manager garantiert ACID-Eigenschaften Atomarität und Dauerhaftigkeit
- Problem: Transaktion wird mit COMMIT beendet, aber Ergebnis hat die Datenbank noch nicht gespeichert.
DBMS für Durchführung von Operationen
Leseoperation
- Seitenadresse auf Platte ermitteln, bei dem der entsprechende Eintrag vorzunommen ist.
- Seite in Hauptspeicher (DB-Puffer) transferieren.
- Betreffenden Wert in lokale Variable kopieren.
Schreiboperation
- Seitenadresse auf Platte ermitteln.
- Seite in die Datenbankpuffer transferieren.
- Betreffenden Wert in lokale Variable kopieren.
- Seite auf Platte schreiben
Fehlerbehandlung
Wenn Fehler zwischen Schreiben in DB-Puffer und Übertragen des Puffers auf Sekundärspeicher auftritt, dann muss Recovery-Manger Status (Transaktion schon committed oder noch nicht) bestimmen, wann der Fehler bei welcher Transaktion aufgetretten ist.
Fall 1: Tranaktion hat ihr COMMIT bereits abgesetzt
- Recovery-Manger muss zur Sicherstellung der Dauerhaftigkeit die Transaktion wiederholen
- globales REDO
- ROLLFORWARD
Fall 2: Transaktion hat ihr COMMIT noch nicht abgesetzt:
- Recovery-Manger muss zur Sicherstellung der Atomarität die Transaktion zurücknehmen
- globals UNDO
- ROLLBACK
DBMS-Konzepte für das Recovery
- Backup-Mechanismus
- Log-Mechanismus
- Checkpoint-Mechanismus
- Recovery-Manager