Vorlesung mit Übung Datenbanksysteme 2
Werbung
Vorlesung mit Übung Datenbanksysteme 2 Sommersemester 2015 Institut für Informatik Lehrstuhl für Datenbanken und Informationssysteme http://www.minet.uni-jena.de/dbis/lehre Prof. Dr. Klaus Küspert (Vorlesung) Dipl.-Inf. Bernhard Pietsch (Übung) 21.04.2015 Datenbanksysteme 2 1 Organisatorisches – 1 • Veranstaltung V3+Ü1 im aktuellen Sommersemester • Termine/Räume: - Vorlesung Di 08.15 - 09.45 - Vorlesung/Übung Do 08.15 - 09.45 SR 130 CZ3 Küspert SR 130 CZ3 Küspert / Pietsch Klarer ausgedrückt: 19 Vorlesungstermine geplant: 21.4., 23.4., 28.4., 30.4., 5.5., 12.5., 26.5., 28.5., 2.6., 9.6., 11.6., 16.6., 23.6., 25.6., 30.6., 7.7., 9.7., 14.7. 6 Übungstermine geplant: 7.5., 21.5., 4.6., 18.6., 2.7., 16.7. 4 der Vorlesungstermine werden von externen Referenten gehalten (IBM, etc.) Andere Termine sind leider, leider, leider belegt durch Feiertage etc. Datenbanksysteme 2 2 Organisatorisches – 2 Leistungsnachweis: • Durch Bestehen der Klausur am 21.07.2015, 16-18 Uhr, Jenoptik-Hörsaal, Helmholtzweg 5 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 2 3 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 http://www.minet.uni-jena.de/dbis/ • 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 2 4 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. 2001 Gunter Saake, Andreas Heuer, Kai-Uwe Sattler: Datenbanken: Implementierungstechniken. mitp-Verlag, Bonn, 2. Aufl. 2005 Datenbanksysteme 2 5 Gliederung Datenbanksysteme 2 (in Fortsetzung/Überarbeitung der DBS1-Gliederung vom Okt. ´14) 6. Transaktionen / Fehlerbehandlung 7. Synchronisation im Mehrbenutzerbetrieb 8. Embedded SQL / API 9. Normalformen / Erweiterungen 10. DBMS-Architektur (open end ...) Datenbanksysteme 2 6 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 BOT OP3 OP4 OP5 OP6 OP7 OP8 OP9 t EOT Die Operationen (SQL-Anweisungen) bilden eine Transaktion Datenbanksysteme 2 7 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 t 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 Datenbanksysteme 2 8 • 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 OP2 OP3 OP4 OP5 BOT Datenbank logisch konsistent (integer) mindestens 2 OPi ändern (sonst langweilig) OP6 t EOT 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 2 9 Bsp.: a) Transaktion T1 macht Umbuchung von einem Konto auf ein anderes, T2 läuft parallel T1 OP1 OP2 ändert OP1 T2 liest ... t 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 OP1 OP2 Abort OP1 ... ändert liest t Isolation ermöglicht u.a. das isolierte Zurücksetzen einer Transaktion im Fehlerfall!! Datenbanksysteme 2 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!! 10 • 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* erfolgreiche Ende OP1 OP2 OP3 OP4 OP5 BOT t 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 2 11 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 2 12 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 2 13 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 2 14 b) Fehlerbehandlung für Systemversagen Szenarium: (Bsp.) D T1 D! T2 T3 T4 „Nachgefahren“ CP CP-Int. CP Crash t 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 Datenbanksysteme 2 15 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 Checkpoint hinaus in die Vergangenheit gehen (z.B. alle Ä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 2 16 T1 T2 „D“ T3 T4 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) Datenbanksysteme 2 17 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 2 18 • 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 PerformanceGründen, kleine Nachteile können akzeptiert werden. Datenbanksysteme 2 19 Bemerkungen ... - 2 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 2 20 • 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 R4Recovery benötigt also kann nicht ganz sooo schnell weggeworfen werden, wie erhofft • Lösung (in DB2) z.B.: Volumen der online (Platte) gehaltenen LogDaten 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 2 21 Bemerkungen ... - 3 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 DBVerä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 2 22 Bemerkungen ... - 4 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 2 23 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 2 24 !
