Daten- und Transaktionskontrolle mit SQL DCL, TCL

Transkript

1 Daten- und Transaktionskontrolle mit SQL DCL, TCL 1

2 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 2

3 Ausführliche Syntax für GRANT GRANT ALL ON relation view TO PUBLIC benutzer DELETE, SELECT INSERT WITH GRANT OPTION 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 3

4 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 4

5 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 5

6 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 Bemerkung: BOT OP1 OP2 OP3 OP4 OP5 OP6 OP7 OP8 OP9 EOT t 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 6

7 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 7

8 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 OP6 t BOT EOT Datenbank logisch konsistent Datenbank hier möglicherweise inkonsistent Bsp.: Umbuchung von einem Konto auf ein anderes Datenbank logisch konsistent 8

9 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 Lösung: Isolation level seit SQL-92 T1 T2 OP1 OP2 OP1 ändert... liest ohne Isolation würde T2 hier inkonsistente Datenbank sehen!! t Gratwanderung zwischen Problemlösung vs. Performance Beispiel: Transaktion T1 buchten Konten um, Transaktion T2 liest parallel die Kontenstände 9

10 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 Beispiel: Bestand haben OP1 OP2 OP3 OP4 BOT COMMIT Fehlersituation Transaktion zur Eheschließung, d.h. Änderung des Familienstandes an zwei Personen t Nach erfolgreicher Eintragung fällt der Strom aus (schlechtes Omen!) Ehe sollte deswegen nicht nochmal geschlossen werden müssen! 10

11 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 11

12 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) 12

13 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! 13

14 Fehlerbehandlung bei Systemversagen I Beispielszenario: T1 T2 T3 T4 CP1 CP-Intervall D D Nachgefahren CP2 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 14

15 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 15

16 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 (R4- Recovery) wegen Dauerhaftigkeit DB anschließend wieder in aktuellem konsistentem Zustand, keine Änderungen abgeschlossener Transaktionen verlorengegangen Beispiel: T1 T2 T3 T4 Archivkopie R4-Recovery für T2 und T3 Externspeicherversagen t 16

17 Sonstiges 17

18 Das Feld der Datenbanken ist noch viel weiter Data Mining Data Integration Mapping & Matching Data Warehouse Data Mart Data Quality Data Profiling Slices and Dices Procedures Trigger SQL-Injections Structured Storage NoSQL Data Cleansing 18

19 Letzte Termine Gastvorträge: Di : Michael Burwig (SAP) 12:15 Uhr, CZ 3, SR 308 Do : Dr. Markus Döhring (BASF) 16:15 Uhr, CZ 3, SR 314 Probeklausur: Di , 12:15 o Wintersemester 16/17 DBIS 19