Einsatz und Realisierung von Datenbanken an der TU München

• Beginn einer Befehlsfolge einer Transaktion

• Befehl zur Beendigung der Transaktion
• Alle Änderungen der Datenbasis werden durch diesen Befehl festgeschrieben --> sie werden dauerhaft in die Datenbank eingebaut 

• Befehl zum Selbstabbruch der Transaktion
• Das DB-System muss sicherstellen, dass die Datenbasis wieder in den Zustand zurückgesetzt wird, der vor Beginn der Transaktionsausführung existierte

Für den Abschluss einer Transaktion gibt es zwei Möglichkeiten:

1. Den erfolgreichen Abschluss durch ein commit

2. Den erfolglosen Abschluss durch ein abort

Atomicity (Atomarität) 

• Alles oder nichts 

Consistency 

• Konsistenter Zustand der DB -> k. Zustand 

Isolation

• Jede Transaktion hat die DB „für sich allein“

• Jedem Benutzer wird vorgegaukelt: Du bist alle auf diesem DB-System unterwegs (Mehrbenutzersynchronisation)

Durability (Dauerhaftigkeit)

• Änderungen erfolgreicher Transaktionen dürfen nie verloren gehen
  
  
  
  
  
  

• Vollständige Zurücksetzung der Loser --> undo
• Winner müssen vollständig erhalten bleiben. Wenn sie nicht in persistenter DB drin sind --> redo

• man kann im Programm der App an bestimmten stellen einen commit oder rollback befehlen
  • commit: Ausführung ist nur dann "erfolgreich" und Änderungen werden festgeschrieben, wenn keine Konsistenzverletzung vorliegt
  • rollback: alle Änderungen sollen zurückgesetzt werden
    Anders als bei commit, muss DBMS die "erfolgreiche" Ausführung immer garantieren

1. Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion (committed) Transaktion Wirkung muss zurückgesetzt werden 

• nur eine von vielen tausend Transaktion ist betroffen

  • Bankautomat: Abbruch von Auszahlung

• sollte schnell gehen

• R1 Recovery

2. Fehler mit Hauptspeicherverlust

• Absturz DB-Server (Hammer, Strom, ...)

• Abgeschlossene TAs (Winner) müssen erhalten bleiben (R2-Recovery)

• Noch nicht abgeschlossene TAs (Loser) müssen zurückgesetzt werden (R3-Recovery)

3. Fehler mit Hintergrundspeicherverlust

• physische Kopie der DB ist weg (Platten kaputt)

  • RAID ist keine Garantie

    • RAID 5 sichert nur den Fall ab dass eine Platte kaputt geht, nicht zwei

    • Die Speicherarrays dienen nur dazu die Verfügbarkeit eines Systems zu erhöhen, nicht die Datensicherheit zu garantieren

• R4-Recovery

• begin of transaction (BOT)
• commit
• abort