DBIS-2016-SQL-DCL-TCL
Werbung
Daten- und Transaktionskontrolle mit SQL DCL, TCL Wintersemester 16/17 DBIS 1 Zugriffsrechte für Datenbankobjekte • Zugriff zu einer Relation (inkl. Daten) mit allen Rechten hat zunächst nur der Benutzer, der sie erzeugt hat • Situation in realen Anwendungen • Datenbankadministrator ist „Eigentümer“ der DB und damit Inhaber aller Rechte auf allen Relationen • Notwendigkeit zur selektiven, zielgerichteten Weitergabe von Rechten • Syntax zur Rechtevergabe (ausführlich nächste Folie): GRANT <privileges> ON <object> TO <grantee> [WITH GRANT OPTION] • Syntax zum Rechteentzug: REVOKE <privileges> FROM <grantee> <drop_behaviour> • Angabe <drop_behaviour> steuert Verhalten bei abhängigen Objekten • CASCADE: vererbte Rechte werden entzogen • RESTRICT: Rechteentzug schlägt fehl Wintersemester 16/17 DBIS 2 Ausführliche Syntax für GRANT relation GRANT ALL ON PUBLIC TO view DELETE benutzer , SELECT WITH GRANT OPTION INSERT ( UPDATE attribut ) , , • Privileges: ALL, SELECT, INSERT, DELETE, UPDATE, ... • Object: TABLE, DOMAIN, TYPE, ... • Grantee: PUBLIC, Role, User • WITH GRANT OPTION: Möglichkeit für den berechtigten Nutzer, das empfangene Recht an andere Nutzer weiterzugeben Wintersemester 16/17 DBIS 3 GRANT und REVOKE – Beispiele • Beispiel 1: Benutzer „KK“ soll die Berechtigung zum Lesen der „Angest“-Relation erhalten und die Möglichkeit, diese Berechtigung weiterzugeben: GRANT SELECT ON Angest TO KK WITH GRANT OPTION • Beispiel 2: Benutzer „ML“ soll nur die Spalte „Wohnort“ von „MeineSichtderDinge“ ändern dürfen, Weitergabe dieser Berechtigung sei unzulässig: GRANT UPDATE (Wohnort) ON MeineSichtderDinge TO ML • Beispiel 3: Jedermann soll das Recht erhalten, die „Projekt“-Relation zu lesen: GRANT SELECT ON Projekt TO PUBLIC • Beispiel 4: Benutzer „KK“ wird das Leserecht auf „Angest“ entzogen, anderen durch „KK“ berechtigten Nutzern ebenfalls: REVOKE SELECT ON Angest FROM KK CASCADE Wintersemester 16/17 DBIS 4 Transaktionsverwaltung/Fehlerbehandlung • Transaktionsbegriff • Was ist eine Transaktion • Wozu braucht man Transaktionen • ACID-Eigenschaften • Fehlerszenarien • Klassifikation • Fehlerursachen • Fehlerbehandlungsmaßnahmen • Klassifikation • Lösungen für verschiedene Fehlerszenarien Wintersemester 16/17 DBIS 5 Der Transaktionsbegriff I • Definition: eine Transaktion ist eine Folge zusammengehöriger Operationen (SQL-Anweisungen) auf der Datenbank (Lese- und Schreiboperationen, DML!) für die gewisse Eigenschaften gelten sollen OP1 OP2 • Bemerkung: OP3 OP4 OP5 OP6 BOT OP7 OP8 OP9 t EOT • Publiziert in den 1970er Jahren durch Jim Gray • Veranschaulichung als „Klammerung“ von Operationen, wird explizit vom Benutzer bzw. der Anwendung gesetzt • Öffnende Klammer: BOT (Begin of Transaction) • Schließende Klammer: EOT (End of Transaction) • COMMIT: Durchführung aller Operationen seit BOT • ROLLBACK: Zurücksetzen aller Operationen seit BOT Wintersemester 16/17 DBIS 6 Der Transaktionsbegriff II • Operationen auf Datenbanken finden ausschließlich im Rahmen von Transaktionen statt • Es gibt keine Operationen „außerhalb“ von Transaktionen! • Im Extremfall veranlasst das DBMS die implizite Klammerung, jede Operation bildet dann eine Transaktion für sich (wenig spannend...) • Transaktionseigenschaften (ACID-Eigenschaften) • Erstmals formuliert von Härder/Reuter 1983 (ACM Computing Surveys) • ACID: Atomicity – Consistency – Isolation – Durability OP1 OP2 OP3 OP4 OP5 OP6 OP7 t Wintersemester 16/17 DBIS 7 Das ACID-Prinzip I • Atomariät (A = atomicity): Eine Transaktion wird entweder komplett oder gar nicht ausgeführt („All or nothing“-Prinzip) • Genauer: eine Transaktion darf nicht im „halbfertigen“ Zustand verbleiben (bei Abbruch, Absturz, etc.), d.h. einige Änderungen auf der Datenbank wurden ausgeführt, andere hingegen nicht • Konsistenz (C = consistency): Eine Transaktion überführt die Datenbank per Definition von einem logisch konsistenten Zustand in einen logisch konsistenten Zustand • Logisch konsistenter Zustand: alle Integritätsregeln gelten OP1 OP2 OP3 OP4 OP5 BOT Datenbank logisch konsistent Wintersemester 16/17 OP6 t EOT Datenbank hier möglicherweise inkonsistent Bsp.: Umbuchung von einem Konto auf ein anderes DBIS Datenbank logisch konsistent 8 Das ACID-Prinzip II • Isolation (I = isolation): Ergebnisse innerhalb einer Transaktion (durchgeführte DBÄnderungen) werden erst bei EOT nach außen hin sichtbar (d.h. für andere, parallel laufende Transaktionen im Mehrbenutzerbetrieb) • Isolation ermöglicht u.a. isoliertes Zurücksetzen einer Transaktion! • Probleme bei unvollständiger/fehlender Isolation • Lost Update: Verlust gleichzeitiger Änderung paralleler Transaktionen • Dirty Read: Lesen von Daten nicht abgeschlossener paralleler Transaktionen • Nonrepeatable Read: Wiederholtes Lesen liefert verschiedene Ergebnisse OP1 T1 T2 • Lösung: • „Isolation level“ seit SQL-92 OP2 OP1 ändert ... liest t ohne Isolation würde T2 hier inkonsistente Datenbank sehen!! • Gratwanderung zwischen Problemlösung vs. Performance • Beispiel: Transaktion T1 buchten Konten um, Transaktion T2 liest parallel die Kontenstände Wintersemester 16/17 DBIS 9 Das ACID-Prinzip III • Dauerhaftigkeit (D = durability): Bei erfolgreichem Ende einer Transaktion (COMMIT) müssen die von ihr durchgeführten Änderungen auch nachfolgende Fehlerfälle überleben • Fehlerfälle: „Systemabsturz“, Platten-Crash • Überleben kann auch heißen: automatisch vom DBMS rekonstruierbar • Benutzer muss sich darauf verlassen können, dass seine durchgeführten und mit COMMIT „freigegebenen/festgeschriebenen“ Änderungen auch wirklich Bestand haben • Beispiel: OP1 OP2 OP3 BOT OP4 Fehlersituation t COMMIT • Transaktion zur Eheschließung, d.h. Änderung des Familienstandes an zwei Personen • Nach erfolgreicher Eintragung fällt der Strom aus (schlechtes Omen!) Ehe sollte deswegen nicht nochmal geschlossen werden müssen! Wintersemester 16/17 DBIS 10 Fehlerszenarien I • Klassifikation (mit zunehmendem Disaster): • Transaktionsversagen • Systemversagen • Externspeicherversagen • Transaktionsversagen (Transaction Failure) • Symptom: Eine einzelne Transaktion erreicht nicht ihr normales Ende (COMMIT) sondern bricht vorzeitig ab • Gründe aus Benutzersicht: • Anwender hat es sich anders überlegt (z.B. Reiseplanung beendet) • Anwender bricht ab aufgrund falscher Eingabedaten / Fehler • Gründe aus Sicht des DBMS: • „Absturz“ eines Anwendungsprogramms • Timeout beim Anwendungsprogramm (z.B. Verbindungsproblem) • Deadlock (Verklemmung) paralleler Transaktionen Wintersemester 16/17 DBIS 11 Fehlerszenarien II • Systemversagen (System Failure, Crash) • Symptom: Das DBMS „stürzt ab“, d.h. die gesamte DB-Verarbeitung wird abrupt unterbrochen; alle laufenden und ggf. auch abgeschlossene Transaktionen betroffen • Gründe z. B. : Fehler in der DBMS-Software, Betriebssystem-Fehler, Hardware-Versagen (Defekt, Stromausfall, ...) • Konsequenz: Inhalt des Hauptspeichers geht verloren (Systempuffer, Sperrtabellen, ...), Platteninhalte bleiben jedoch erhalten + intakt • Externspeicherversagen (Media Failure) • Symptom: Datenverlust auf Externspeicher, Datenbank ganz oder teilweise zerstört • Gründe: Head Crash, „magnetische Alterung“, Plattendefekte aller Art • Wie lassen sich die ACID-Eigenschaften (vorallem „A“ und „D“) trotzdem garantieren? Fehlerbehandlungsmaßnahmen (Datenbank-Recovery) Wintersemester 16/17 DBIS 12 Fehlerbehandlung bei Transaktionsversagen • DBMS setzt betroffene Transaktion auf ihren Anfangszustand zurück, d.h. alle Änderungen am DB-Zustand, die von der Transaktion bereits vorgenommen wurden, werden rückgängig gemacht (ROLLBACK) • Sogenannte R1-Recovery • Gewährleistung der Atomarität • Mögliches Vorgehen: • DBMS protokolliert die Änderungen am Datenbankzustand in Form von „before images“ (z.B. Tupel vor der Modifikation) und „after images“ (z.B. Tupel nach der Modifikation) • Speicherung in sogenannten Protokolldateien (Log) auf der Platte • Durchführung eines ROLLBACK mit den before images aus der Protokolldatei automatisch vom DBMS möglich • Konsequenz: Aufwand zur Verwaltung der Log-Datei und Redundanz erforderlich! Wintersemester 16/17 DBIS 13 Fehlerbehandlung bei Systemversagen I • Beispielszenario: D T1 D T2 T3 T4 „Nachgefahren“ CP1 CP2 CP-Intervall Crash t • DBMS führt automatisch oder vom DBA veranlasst einen Wiederanlauf (Restart) durch verbunden mit Crash Recovery • „Nachfahren“ (REDO) von Transaktionen mit COMMIT vor dem Systemversagen • Sogenannte R2-Recovery (wegen Dauerhaftigkeit) • Grund: trotz COMMIT können die Änderung einer Transaktion noch im Systempuffer stehen und noch nicht auf Platte persistiert sein • Verwendung der after images aus der Logdatei • Beispiel: Änderung der Transaktionen T1 und T2 nachfahren Wintersemester 16/17 DBIS 14 Fehlerbehandlung bei Systemversagen II • Zurücksetzen (ROLLBACK) von unterbrochenen Transaktionen • Sogenannte R3-Recovery (wegen Atomarität, analog R1-Recovery) • Verwendung der before images aus der Logdatei • Beispiel: Änderungen der Transaktionen T3 und T4 zurücksetzen • Problem bezüglich des Nachfahrens: • Wie weit in der Vergangenheit muss begonnen werden? • Theoretisch ab Zeitpunkt des DBMS-Starts sehr aufwändig für R2! • Lösung: • Sicherungspunkte (Checkpoints, CP) in regelmäßigen Abständen (Checkpoint-Intervall), z.B. alle 10 Minuten • Inhalt des Systempuffers wird komplett in die Datenbank geschrieben, d.h. auf Platte persistiert („flush buffer“) • Nachfahren braucht nicht über den aktuellsten Checkpoint hinaus in die Vergangenheit (Logfile!) gehen • Beispiel: T1 muss nicht mehr nachgefahren werden, nur noch ab CP2 Wintersemester 16/17 DBIS 15 Fehlerbehandlung bei Externspeicherversagen • Ausgangspunkt / Voraussetzung: • Gelegentliches Erstellen von Datenbankkopien („Archivkopien“), d.h. Planung und Durchführung von Backup-Strategien • Protokollieren der Änderungen aller (zumindest abgeschlossenen) Transaktionen in Form von after images in Protokolldatei (Log) • Vorgehen: • Datenbankadministrator lädt Archivkopie, meist von Band auf Platte • Start DBMS-seitigen Nachfahrens aller abgeschlossenen Transaktionen (R4Recovery) wegen Dauerhaftigkeit • DB anschließend wieder in aktuellem konsistentem Zustand, keine Änderungen abgeschlossener Transaktionen verlorengegangen • Beispiel: T1 T2 T3 T4 R4-Recovery für T2 und T3 t Externspeicherversagen Archivkopie Wintersemester 16/17 DBIS 16 Sonstiges Wintersemester 16/17 DBIS 17 Das Feld der Datenbanken ist noch viel weiter… • Data Mining • Slices and Dices • Data Integration • Procedures • Mapping & Matching • Trigger • Data Warehouse • SQL-Injections • Data Mart • Structured Storage • Data Quality • NoSQL • Data Profiling … • Data Cleansing Wintersemester 16/17 DBIS 18 Letzte Termine • Gastvorträge: • Di. 24.01.2017: Michael Burwig (SAP) 12:15 Uhr, CZ 3, SR 308 • Do. 26.01.2017: Dr. Markus Döhring (BASF) 16:15 Uhr, CZ 3, SR 314 • Probeklausur: • Di. 31.01.2017, 12:15 o Wintersemester 16/17 DBIS 19
