Vorlesung mit Übung Datenbanksysteme 2

Transkript

1 Vorlesung mit Übung Datenbanksysteme 2 Sommersemester 2012 Institut für Informatik Lehrstuhl für Datenbanken und Informationssysteme Prof. Dr. Klaus Küspert (Vorlesung) Dipl.-Inf. Katharina Büchse, Martin Thrum (Übung) Datenbanksysteme

2 Organisatorisches 1 Veranstaltung V3+Ü1 im aktuellen Sommersemester Termine/Räume: - Vorlesung/Übung Di SR 221 CZ3 Küspert/Büchse/Thrum - Vorlesung Do SR 222 CZ3 Küspert Klarer ausgedrückt: 19 Vorlesungstermine geplant: 17.4., 19.4., 24.4., 26.4., 3.5., 8.5., 10.5., 22.5., 24.5., 31.5., 5.6., 7.6., 19.6., 21.6., 28.6., 3.7., 5.7., 12.7., Übungstermine geplant: 15.5., 29.5., 12.6., 26.6., 10.7., ca. 4 der Vorlesungstermine werden von externen Referenten gehalten (IBM, SAP..) Andere Termine sind leider, leider, leider belegt durch Feiertage etc. Datenbanksysteme

3 Organisatorisches 2 Leistungsnachweis: Durch Bestehen der Klausur am , Uhr, HS2 CZ3 In all diesen Fällen werden wieder schöne Scheine (d.h. informativ, inhaltsreich..) ausgegeben ( Zertifikate ) Folien und mehr : Jeweils im Web (sukzessive)! Regelmäßiger Besuch von Vorlesung und Übung wird angeraten (einige Vorlesungsinhalte wird es bekanntlich zusätzlich geben nur in Vorlesung / an Tafel, also nicht auf den Folien). Übung wird ebenfalls die Vorlesung teils stofflich ergänzen Datenbanksysteme

4 Organisatorisches 3 Art der Übungsdurchführung: - Ausgabe von Übungsblättern (jeweils Woche x) - keine Abgabe von Lösungen - Besprechung/Vorrechnung jeweils Woche x+1 i.w. Die Übungsblätter werden wie bei DBS1 jeweils ins Web gestellt. Lehrveranstaltungen unter Neben Folien, Übungsblättern... werden gelegentlich noch weitere Materialien bereitgestellt, etwa Kopien von Veröffentlichungen ( Milestone-Papieren im Datenbankbereich) etc. Regelmäßige, aktive Teilnahme an Vorlesung und Übung sehr angeraten!! Datenbanksysteme

5 Literatur Vorlesungsfolien sukzessive im Web Weitere Veröffentlichungen/Kopien i.d.r. per Link im Web bereitgestellt Die bereits im WiSem genannten Datenbank-Lehrbücher, à la Heuer/Saake, Lang/Lockemann, Vossen Speziell für Datenbankimplementierungsaspekte (nur) zwei SEHR GUTE! deutschsprachige Lehrbücher: Theo Härder, Erhard Rahm: Datenbanksysteme. Konzepte und Techniken der Implementierung. Springer-Verlag, Berlin Heidelberg, 2. Aufl Gunter Saake, Andreas Heuer, Kai-Uwe Sattler: Datenbanken: Implementierungstechniken. mitp-verlag, Bonn, 2. Aufl Datenbanksysteme

6 Gliederung Datenbanksysteme 2 (in Fortsetzung/Überarbeitung der DBS1-Gliederung vom Okt. 10) 6. Transaktionen / Fehlerbehandlung 7. Synchronisation im Mehrbenutzerbetrieb 8. Embedded SQL / API 9. Normalformen / Erweiterungen 10. DBMS-Architektur (open end...) Datenbanksysteme

7 6. Einführung zum Thema Transaktionsverwaltung / Fehlerbehandlung (/ Synchronisation in Datenbanksystemen) 6.1 Was ist eine Transaktion und wozu braucht man sie? Transaktion = Folge zusammengehöriger Operationen (bei relationalen Datenbanksystemen: SQL-Anweisungen) auf der Datenbank wobei es sich um Lese- und Schreiboperationen handeln kann für die bestimmte Eigenschaften gelten sollen (s.u.) M.a.W.: Eine Art Klammerung von Operationen, wobei die öffnende (Begin of Transaction) und schließende (End of Transaction, Commit Transaction, Abort Transaction ) Klammer vom Benutzer bzw. der Anwendung ROLLBACK bei eingebettetem SQL gesetzt wird. OP1 OP2 OP3 OP4 OP5 OP6 OP7 OP8 OP9 t BOT EOT Die Operationen (SQL-Anweisungen) bilden eine Transaktion Datenbanksysteme

8 Operationen auf Datenbanken finden ausschließlich im Rahmen von Transaktionen statt, d.h. es gibt keine Operationen außerhalb von TAen! (Im Extremfall bildet jede Operation für sich eine Transaktion.) implizite Op-Klammerung als Transaktion, DBMS veranlasst OP1 OP2 OP3 OP4 OP5 OP6 OP7 eine eigene Transaktion pro Operation (der nicht so interessante Fall...) Transaktionseigenschaften (ACID-Eigenschaften (Härder/Reuter 1983)) A = Atomarität (atomicity) Eine Transaktion wird entweder komplett oder gar nicht ausgeführt: all or nothing Prinzip M.a.W.: Es darf nicht passieren, dass eine Transaktion im halbfertigen Zustand verbleibt (durch Abbruch, Absturz o.ä.), d.h. einige Änderungen auf der Datenbank ausgeführt wurden, andere hingegen nicht t Datenbanksysteme

9 C = Konsistenz (consistency) Eine Transaktion überführt die Datenbank per Definition von einem logisch konsistenten Zustand (alle Integritätsregeln gelten) in einen logisch konsistenten Zustand (alle Integritätsregeln gelten), bildlich: OP1 mindestens 2 OPi ändern (sonst langweilig) OP2 OP3 OP4 OP5 OP6 t BOT EOT Datenbank logisch konsistent (integer) Datenbank hier möglicherweise inkonsistent (nicht alle Integritätsregeln erfüllt) Bsp.: Umbuchung von einem Konto auf ein anderes Datenbank logisch konsistent (integer) I = Isolation Im Mehrbenutzerbetrieb Das, was innerhalb einer Transaktion geschieht (d.h. die durchgeführten Datenbankänderungen), wird erst bei EOT nach außen hin sichtbar (d.h. für andere, parallel ablaufende Transaktionen im Mehrbenutzerbetrieb) Datenbanksysteme

10 Bsp.: a) Transaktion T1 macht Umbuchung von einem Konto auf ein anderes, T2 läuft parallel T1 T2 OP1 ohne Isolation würde T2 hier inkonsistente Datenbank sehen!! b) Gleiches Szenarium wie bei a), aber Transaktion T1 wird nach OP2 abgebrochen (Abort) T1 T2 Isolation ermöglicht u.a. das isolierte Zurücksetzen einer Transaktion im Fehlerfall!! OP1 OP1 OP2 OP2 OP1... Abort... ändert ändert liest liest ohne Isolation würde T2 hier Datenbankzustand sehen, der von T1 anschließend (durch Abort) wieder zurückgenommen wurde, also so nicht für die Außenwelt bestimmt war T2 wäre u.u. ebenfalls zum Abort (Transaktionsabbruch) gezwungen!! t t Datenbanksysteme

11 D = Dauerhaftigkeit (durability) Wenn eine Transaktion erfolgreich zum Ende gekommen ist, d.h. mit commit transaction abgeschlossen hat, dann müssen die von ihr durchgeführten Änderungen auch im evtl. nachfolgenden Fehlerfall ( Systemabsturz, Platten-Crash) überleben* OP1 OP2 OP3 OP4 OP5 erfolgreiche Ende t BOT Commit *bzw. vom DBVS automatisch rekonstruierbar sein M.a.W.: Benutzer muss sich darauf verlassen können, dass seine durchgeführten und mit Commit freigegebenen / festgeschriebenen Änderungen auch wirklich Bestand haben ACID-Eigenschaften von Transaktionen erstmals formuliert von Härder/Reuter 1983 (ACM Computing Surveys) Jim Gray = Erfinder des Transaktionskonzept bzw. erste wissenschaftliche Veröffentlichungen dazu in den 1970ern Datenbanksysteme

12 6.2 Fehlerszenarien zunehmende Disaster Transaktionsversagen a) Systemversagen b) Externspeicherversagen c) a) Transaktionsversagen (TA-Abbruch, Transaction Failure) Eine einzelne Transaktion erreicht nicht ihr normales Ende, sondern bricht ab (Abort Transaction durch Benutzer/Anwendung oder durch DBVS) häufig hoffentlich nicht so häufig Gründe: - Benutzer hat sich s anders überlegt, hat Fehler bemerkt o.ä. - Absturz eines Anwendungsprogramms (mit eingebettetem SQL) - Inkorrekte Eingabedaten Benutzer/Anwendung beschließt daraufhin Abbruch - Anwendungsprogramm meldet sich nicht mehr - Deadlock (Verklemmung) o.ä Datenbanksysteme

13 b) Systemversagen (Systemausfall, System Failure (Crash)) Das DBVS stürzt ab, d.h. die gesamte DB-Verarbeitung wird abrupt unterbrochen (alle lfd. Transaktionen (und mehr ) betroffen, ggf. auch bereits abgeschlossene TA betroffen) Gründe: - DBVS-Fehler - BS-Fehler - Hardware-Versagen (Defekt, Stromausfall...) Konsequenz: Hauptspeicherinhalt geht verloren (Systempuffer, Sperrtabellen...), Platteninhalte bleiben jedoch erhalten + intakt (Annahme) c) Externspeicherversagen (Media Failure) Datenverlust auf Externspeicher; Datenbank ganz oder teilweise zerstört Gründe: - Head Crash, magnetische Alterung, alle möglichen Ursachen für Plattendefekt Frage nun: Wie lassen sich ACID-Eigenschaften trotzdem garantieren (vor allem A und D ) Fehlerbehandlungsmaßnahmen Datenbank-Recovery Datenbanksysteme

14 6.3 Klassifikation von Fehlerbehandlungsmaßnahmen Datenbank-Recovery a) Fehlerbehandlung für Transaktionsversagen DBVS setzt betroffene TA auf ihren Anfangszustand zurück, d.h. alle Änderungen am DB-Zustand, die von der TA bereits vorgenommen wurden, werden rückgängig gemacht (Transaction Rollback) Warum?: Garantieren von A tomarität Wie?: DBVS protokolliert i.d.r. die Änderungen am Datenbankzustand (z.b. Tupelmodifikation) in Form von before images (Tupel vor der Modifikation) und after images (Tupel nach der Modifikation) sog. Protokoll(datei) (Log[File]) auf Platte before images aus Protokoll(datei) können zum Rücksetzen der Änderungen (Rollback) benutzt werden: automatisch durchs DBVS!!! Datenbankfehlerbehandlung erfordert Redundanz (natürlich!) Datenbanksysteme

15 b) Fehlerbehandlung für Systemversagen Szenarium: (Bsp.) T1 T2 T3 T4 CP D CP-Int. CP Nachgefahren D! Crash DBVS führt (automatisch oder vom DBA veranlasst) Wiederanlauf (Restart, Warmstart ) durch verbunden mit Crash Recovery Was ist zu tun? - T3 und T4 müssen zurückgesetzt werden wg. A tomarität mit Hilfe der before images in der Protokolldatei - T1 und T2 müssen (u.u.) nachgefahren (REDO) werden, d.h. die von ihnen vorgenommenen Änderungen am DB-Zustand müssen persistent gemacht, d.h. auf Platte geschrieben werden (sie können! nämlich trotz Commit ggf. noch im Systempuffer stehen und (noch) nicht auf Platte geschrieben worden sein) Nachfahren (wg. D auerhaftigkeit) mit Hilfe der after images in der Protokolldatei t Datenbanksysteme

16 Problem hinsichtlich des Nachfahrens : Wie weit in der Vergangenheit muss begonnen werden? Ab Zeitpunkt des DBVS-Starts? sehr aufwendig! Lösung: Sog. Checkpoints (Sicherungspunkte) in regelmäßigen Zeitabständen (z.b. alle 10 Minuten... (sog. Checkpoint-Intervall)) Pufferinhalt wird komplett in die Datenbank geschrieben ( flush buffer ) Nachfahren braucht nicht über den aktuellsten alle Checkpoint hinaus in die Vergangenheit gehen (z.b. Änderungen von T1 in obigem Bild bereits auf Platte) R2-Aufwandsbegrenzung. c) Fehlerbehandlung für Externspeicherversagen Ausgangspunkt für Fehlerbehandlung: - Gelegentliches Erstellen von Datenbankkopien (sog. Archivkopien ) Backup-Durchführung - Protokollieren der Änderungen aller (zumindest aller abgeschlossenen) Transaktionen in Form von after images in Protokolldatei Datenbanksysteme

17 T1 T2 T3 T4 D müssen zur R4-Recovery (Behandlung von Externspeicherversagen) nachgefahren werden.... Zeitpunkt des Erstellens einer Archivkopie der Datenbank t Externspeicherversagen DBA lädt Archivkopie (i.d.r. Band Platte) und veranlasst das DBVSseitige Nachfahren aller abgeschlossenen Transaktionen ( R4-Recovery) wg. D auerhaftigkeit DB anschließend wieder in aktuellem konsistentem Zustand (es sind keine Änderungen abgeschlossener TAen verlorengegangen!) Hinweis: Die Fehlerbehandlungsmaßnahmen sind etwas vereinfacht dargestellt worden (z.b. R2- und R3-Recovery bei bestimmten DBVS-Implementierungen nicht erforderlich) SoSe 2006! Datenbanksysteme

18 Bemerkungen zur Transaktionsthematik und deren Implementierung etc. - 1 Blockschreiben in die Datenbank erfolgt natürlich nicht nur beim Checkpoint, sondern auch sonst zu beliebigen, nicht vorplanbaren Zeitpunkten (nämlich wenn im Puffer (Größe << Datenbankgröße) kein Platz mehr vorhanden ist für neuen Block). In Wahrheit wird sogar teils proaktiv geschrieben (DB2 etwa). Sog. STEAL-Strategie: (geänderte, schmutzige ) Daten können sich aus dem Puffer in die Datenbank davonstehlen (vor Transaktionsende). ( Schmutzige Daten werden erst durch Transaktionsende (Commit) sauber.) Datenblöcke, die aus dem Puffer verdrängt werden, enthalten oft schmutzige und saubere Daten gemischt: Mehrere Transaktionen können parallel auf einem Datenblock herumgeändert haben: die eine ist schon fertig (Commit), die andere noch nicht zum Zeitpunkt des Blockschreibens. Wie könnte man s etwa verhindern: Blocksperren (siehe Folgeabschnitt über Synchronisation), die will man aber nicht... Datenbanksysteme

19 DBMS sorgt mittels Write-Ahead Logging (WAL) dafür, dass jeweils vor Schreiben eines Datenblocks in die DB (auf Platte) zugehörige Log-Einträge ebenfalls auf Platte gelangen, also zugehörige Blöcke des Log-Puffers geschrieben werden (wegen Atomaritätseigenschaft, Rücksetzbarkeit der Transaktion). Prinzip Log-Puffer: Tafelbild!! Datenblöcke im Log-Puffer sind nicht immer ganz gefüllt (mit Log-Einträgen) zum Zeitpunkt ihres Schreibens auf Platte: Log-Block muss raus auf Platte (ob voll oder nicht voll), wenn - Commit Transaction erfolgt (wegen Durability-Eigenschaft) wenn man von gewissen (kleinen) erlaubten zeitlichen Verzögerungen ab-sieht, wie sie wegen Group Commit zustande kommen - (wegen WAL-Prinzip) Datenblock rausgeschrieben wird und sich zugehörige Log-Einträge (noch) im Log-Block im Puffer befinden (Atomaritätseigenschaft) Hinweis: Über Teilnahme am Group Commit ( Bündelung der Commits, vor allem des Log-Schreibens) wird zum Commit-Zeitpunkt entschieden, d.h. das System fasst mehrere Commits zusammen, sofern sie zeitlich dicht liegen natürlich nur aus Performance- Gründen, kleine Nachteile können akzeptiert werden. Datenbanksysteme

20 Bemerkungen Volumen der Log-Daten (Protokolldaten) Log (auf der Platte) wächst mit der Zeit beliebig an über alle maßen??... muss natürlich verhindert werden! Wie? 1. UNDO-Log-Daten (BFIM) von abgeschlossenen Transaktionen werden im Prinzip nicht mehr benötigt (für R1-/R3-Recovery)... wir können abgeschlossene Transaktionen nicht mehr zurückrollen (wegen D!) 2. REDO-Log-Daten (AFIM) von Transaktionen, die vor aktuellem Checkpoint erfolgreich beendet worden sind, werden nicht mehr benötigt für R2-Recovery (denn Checkpoints begrenzen ja gerade das Nachfahren nach hinten, deshalb wurden Checkpoints ja eingeführt!) Datenbanksysteme

21 Konsequenz also: BFIM und AFIM können unter Beachtung jener Regeln kontinuierlich weggeworfen werden(?) Jein: 0. Ein Log transaktionsübergreifend 1. BFIM und AFIM stehen üblicherweise gemeinsam in einem Log (Datei), selektives Wegwerfen also nicht möglich 2. REDO-Log-Daten werden nicht nur für R2-, sondern auch für R4- Recovery benötigt also kann nicht ganz sooo schnell weggeworfen werden, wie erhofft Lösung (in DB2) z.b.: Volumen der online (Platte) gehaltenen Log- Daten begrenzen durch (automatisches) Archivieren: Auf schnellem Medium (Platte) werden die Log-Daten nur für R1-/R2-/R3-Recovery gebraucht. Langfristiges Aufheben für R4-Recovery also durch Kopieren des Logs (z.b.) auf langsamen Tertiärspeicher ( Verschieben auf Tertiärspeicher) ermöglicht reuse des Log-Datenplatzes auf dem Sekundärspeicher (Platte), zyklisches Be- oder Überschreiben des Log-Datenplatzes Datenbanksysteme

22 Bemerkungen Logging, Backup, Recovery Probleme im Zusammenhang mit Backup (DB-Sicherung): Kopieren sehr großer Datenmengen (Tera..) Behinderung des lfd. DB-Betriebs Lösungen: Offline- vs. Online-Backup: Normaler DB-Betrieb läuft bei Onlineweiter während des Backup-Vorgangs (Probleme?) Paralleles Backup: Paralleles Datenschreiben von mehreren Datenbank-Devices auf mehrere Sicherungs-Devices (Diplomarbeit Ch. Gollmick 1999 ) (Fragestellungen?) Inkrementelles Backup: Sichern nur des Delta, d.h. der DB- Veränderungen seit letztem Backup (Probleme?) Partielles Backup: Sichern nur von Datenbankteilen, etwa einzelnen Table Spaces, andere dann zu anderen Zeitpunkten Im Prinzip alles orthogonal verwendbar und weitgehend verfügbar in heutigen DBMS-Produkten Datenbanksysteme

23 Bemerkungen Schreibstrategien des DBMS Herausgegriffene Klassifikationsmerkmale (siehe Härder/Reuter-ACID-Papier): Force vs. no-force: Wann werden geänderte Daten (zurück) auf die Platte geschrieben ( gezwungen ): (Spätestens) bei EOT (force) oder ggf. auch irgendwann erst später (no-force)? Reale Produkte bevorzugen no-force (aus diskutiertem Grunde) Steal vs. no-steal: Wann stehlen sich geänderte Daten aus dem Puffer davon (zurück auf Platte): Jederzeit, insb. also auch schon, während die verursachende Transaktion noch läuft (steal) also auch schmutzig oder erst nach Transaktionsende (no-steal, also nur sauber)? Reale Produkte bevorzugen steal (warum?) Atomic vs. not-atomic: Wie wird der Datenbankzustand auf Platte fortgeschrieben: Atomar ( punktuelles Fortschreiben) oder nicht atomar (kontinuierliches Fortschreiben)? Bei atomarem Fortschreiben ist die Datenbank auf Platte bei Crash (Systemversagen, System Failure) immer in einem wohldefinierten Zustand freilich nicht unbedingt transaktionskonsistent -, bei nicht atomarem Fortschreiben ist sie in irgendeinem (indifferenten) Zustand. Reale Produkte bevorzugen not-atomic, es gibt aber in Forschung (sowieso) und Produkten auch atomic (Schattenspeicherkonzept) Datenbanksysteme

24 Zusammenfassung / Hilites zum Trans.-Konzept (Kap. 6) Alle DB-Operationen laufen stets innerhalb von (DB)-Transaktionen TA fassen logisch zusammengehörige DB-Operationen zusammen, klammern sie also (BOT, EOT) Für TA gelten die ACID-Eigenschaften, diese legen die Semantik der Klammerung fest TA enden entweder erfolgreich (TA-Commit) oder erfolglos (TA-Abbruch, Abort, Rollback synonym) Beendet ist eine TA erst dann richtig, wenn das TA-Ende vom DBMS quittiert! wurde (Quittung bestätigt die Dauerhaftigkeit der durchgeführten Änderungen) ACID muss DBMS implementierungstechnisch umgesetzt werden, Mechanismen/Automatismen sind gefordert: - Logging/Recovery für A + D - Synchronisation für I (z.b. Sperren) - Integritätsüberwachung für C ACID kostet etwas in bezug auf DBMS-Implementierungsaufwand und in bezug auf Performance zur Laufzeit und in bezug auf DB-Administration aber es lohnt sich! Kosten (Performance) können durchaus vom Administrator/Benutzer beeinflusst werden Datenbanksysteme