K6 Transaktionsverwaltung, Integritätssicherung und Zugriffskontrolle Flashcards
TA-Konzept: Gefährdung der DB-Konsistenz
TA-Konzept: Ablaufkontrollstruktur - Transaktion (TA)
Eine Transaktion ist eine ununterbrechbare Folge von DML-Befehlen, die die Datenbank von einem logisch konsistenten in einen (neuen) logisch konsistenten Zustand überführt.
“Transaktionen fassen mehrere Operationen zu einer Einheit zusammen; werden immer ganz oder gar nicht ausgeführt.”
haben ACID-Eigenschaften
TA-Konzept: Ablaufkontrollstruktur - ACID-Eigenschaften von Transaktionen
Atomicity (Atomarität)
- TA ist kleinste, nicht mehr weiter zerlegbare Einheit
- Entweder werden alle Änderungen der TA festgeschrieben oder gar keine („alles-oder-nichts“-Prinzip)
Consistency
- TA hinterlässt einen konsistenten DB-Zustand, sonst wird sie komplett (siehe Atomarität) zurückgesetzt
- Zwischenzustände während der TA-Bearbeitung dürfen inkonsistent sein
- Endzustand muss alle definierten Integritätsbedingungen erfüllen
Isolation
- Nebenläufig (parallel, gleichzeitig) ausgeführte TA dürfen sich nicht gegenseitig beeinflussen
- Parallele TA bzw. deren Effekte sind nicht sichtbar (logischer Einbenutzerbetrieb)
Durability (Dauerhaftigkeit)
- Wirkung erfolgreich abgeschlossener TA bleibt dauerhaft in der DB
- TA-Verwaltung muss sicherstellen, das dies auch nach einem Systemfehler (HW- oder System-SW) gewährleistet ist
- Wirkung einer erfolgreich abgeschlossenen TA kann nur durch eine sog. kompensierende TA aufgehoben werden
TA-Verwaltung: Wesentliche Abstraktionen (aus Sicht der DB-Anwendung) zur Gewährleistung einer ‚fehlerfreien Sicht‘ auf die Datenbank im logischen Einbenutzerbetrieb
- Alle Auswirkungen auftretender Fehler bleiben der Anwendung verborgen (failure transparency)
- Es sind keine anwendungsseitigen Vorkehrungen zu treffen, um Effekte der Nebenläufigkeit beim DB-Zugriff auszuschließen (concurrency transparency)
TA-Verwaltung
- koordiniert alle DBS-seitigen Maßnahmen, um ACID zu garantieren
- besitzt zwei wesentliche Komponenten
- Synchronisation
- Logging und Recovery
- kann zentralisiert oder verteilt (z.B. bei VDBS) realisiert sein
- soll Transaktionsschutz für heterogene Komponenten bieten
TA-Verwaltung: Abstraktes Architekturmodell (für das Read/Write-Modell auf Seitenbasis)
TA-Verwaltung: Komponenten
Transaktionsverwalter
- Verteilung der DB-Operationen in VDBS und Weiterreichen an den Scheduler
- zeitweise Deaktivierung von TA (bei Überlast)
- Koordination der Abort- und Commit-Behandlung
Scheduler ( Synchronisation)
- kontrolliert die Abwicklung der um DB-Daten konkurrierenden TA
Recovery-Komponente
- sorgt für die Rücksetzbarkeit/Wiederholbarkeit der Effekte von TA
DB-Pufferverwalter
- stellt DB-Seiten bereit und gewährleistet persistente Seitenänderungen
TA-Verwaltung: Transaktionsablauf und mögliche Ausgänge einer Transaktion
DB-Recovery
- Automatische Behandlung aller ‚erwarteten‘ Fehler durch das DBVS
- Voraussetzung: Sammeln redundanter Information während des normalen Betriebs (Logging)
- Fehlermodell von zentralisierten DBVS
- Transaktionsfehler
- Systemfehler
- Gerätefehler
- Katastrophe
- TA-Paradigma verlangt:
- Alles-oder-Nichts-Eigenschaft von TAs
- Dauerhaftigkeit erfolgreicher Änderungen
- Zielzustand nach erfolgreicher Recovery: jüngster transaktionskonsistenter DB-Zustand
- Durch die Recovery ist der jüngste Zustand vor Erkennen des Fehlers wiederherzustellen, der allen semantischen Integritätsbedingungen entspricht, der also ein möglichst aktuelles, exaktes Bild der Miniwelt darstellt
DB-Recovery: Recovery-Arten
1. Transaktions-Recovery
- Zurücksetzen einzelner (noch nicht abgeschlossener) Transaktionen im laufenden Betrieb (Transaktionsfehler, Deadlock)
- Arten:
- Vollständiges Zurücksetzen auf Transaktionsbeginn (TA-UNDO)
- Partielles Zurücksetzen auf Rücksetzpunkt (Savepoint) innerhalb der Transaktion
2. Crash-Recovery nach Systemfehler
- Wiederherstellen des jüngsten transaktionskonsistenten DB-Zustands
- Notwendige Aktionen:
- (partielles) REDO für erfolgreiche Transaktionen (Wiederholung verlorengegangener Änderungen)
- UNDO aller durch Ausfall unterbrochenen Transaktionen (Entfernen der Änderungen aus der permanenten DB)
3. Medien-Recovery nach Gerätefehler
- Spiegelplatten bzw.
- Vollständiges Wiederholen (REDO) aller Änderungen (erfolgreich abgeschlossener Transaktionen) auf einer Archivkopie
4. Katastrophen-Recovery
- Nutzung einer aktuellen DB-Kopie in einem ‚entfernten‘ System oder
- Stark verzögerte Fortsetzung der DB-Verarbeitung mit repariertem/neuem System auf der Basis gesicherter Archivkopien (Datenverlust)
Synchronisation: Einbenutzer-/Mehrbenutzerbetrieb
Synchronisation: Anomalien im unkontrollierten Mehrbenutzerbetrieb
- Abhängigkeit von nicht-freigegebenen Änderungen (Dirty-Read)
- Verlorengegangene Änderung (Lost Update)
- Inkonsistente Analyse (Non-repeatable Read)
- Phantom-Problem
Synchronisation: Anomalien im unkontrollierten Mehrbenutzerbetrieb - Abhängigkeit von nicht-freigegebenen Änderungen (Dirty-Read)
Geänderte, aber noch nicht freigegebene Daten werden als „schmutzig“ bezeichnet (dirty data), da die TA ihre Änderungen bis Commit (einseitig) zurücknehmen kann
Schmutzige Daten dürfen von anderen TAs nicht in „kritischen” Operationen benutzt werden
Synchronisation: Anomalien im unkontrollierten Mehrbenutzerbetrieb - Verlorengegangene Änderung (Lost Update)
ist in jedem Fall auszuschließen
Synchronisation: Anomalien im unkontrollierten Mehrbenutzerbetrieb - Inkonsistente Analyse (Non-repeatable Read)
Synchronisation: Anomalien im unkontrollierten Mehrbenutzerbetrieb - Phantom-Problem
Synchronisation: Korrektheit – Vorüberlegungen
einzelne TA T
- wenn T allein auf einer konsistenten DB ausgeführt wird, dann terminiert T (irgendwann) und hinterlässt die DB in einem konsistenten Zustand
- während der TA-Verarbeitung gibt es keine Konsistenzgarantien!
mehrere TAs
- wenn Transaktionen seriell ausgeführt werden, dann bleibt die Konsistenz der DB erhalten
- Ziel der Synchronisation: logischer Einbenutzerbetrieb, d.h. Vermeidung aller Mehrbenutzeranomalien
Synchronisation: Serialisierbarkeit
Formales Korrektheitskriterium: Serialisierbarkeit
Die parallele Ausführung einer Menge von TA ist serialisierbar, wenn es eine serielle Ausführung derselben TA-Menge gibt, die den gleichen DB-Zustand und die gleichen Ausgabewerte wie die ursprüngliche Ausführung erzielt.
Hintergrund:
- Serielle Ablaufpläne sind korrekt
- Jeder Ablaufplan, der denselben Effekt wie ein serieller erzielt, ist akzeptierbar
Synchronisation:
- Einbettung des DB-Schedulers
- Zur Realisierung der Synchronisation gibt es viele Verfahren
- Sperrbasierte (pessimistische) Verfahren
Einbettung des DB-Schedulers
- als Komponente der Transaktionsverwaltung zuständig für I von ACID
- kontrolliert die beim TA-Ablauf auftretenden Konfliktoperationen (Read/Write, Write/Read, Write/Write) und garantiert insbesondere, dass nur „serialisierbare“ TA erfolgreich beendet werden
- „nicht serialisierbare“ TAs müssen verhindert werden; dazu ist Kooperation mit der Recovery-Komponente erforderlich (Rücksetzen von TA).
Zur Realisierung der Synchronisation gibt es viele Verfahren
- Pessimistisch
- Optimistisch
- Versionsverfahren
- Zeitmarkenverfahren
- etc.
Sperrbasierte (pessimistische) Verfahren
- bei einer Konfliktoperation blockieren sie den Zugriff auf das Objekt
- universell einsetzbar
- es gibt viele Varianten
Synchronisation: Historische Entwicklung von Synchronisationsverfahren
Synchronisation: RX-Sperrverfahren - Sperrmodi und Kompatibilitätsmatrix
Sperrmodi
- Sperrmodus des Objektes: NL (no lock), R (read), X (exclusive)
- Sperranforderung einer Transaktion: R, X
Synchronisation: RX-Sperrverfahren - Formen der Zweiphasigkeit
Synchronisation: RX-Sperrverfahren - Deadlocks/Verklemmungen
Möglichkeit von Verklemmungen ist inhärent bei pessimistischen Methoden (blockierende Verfahren)
Synchronisation: Erweiterung: RUX
- Ziel: Verhinderung von Konversions-Deadlocks
- U-Sperre für Lesen mit Änderungsabsicht (Prüfmodus)
- bei Änderung Konversion U → X, andernfalls U → R (downgrading)
Synchronisation: Konsistenzebenen – in SQL
- SQL erlaubt Wahl zwischen vier Konsistenzebenen (Isolation Level)
- Konsistenzebenen sind durch die Anomalien bestimmt, die jeweils in Kauf genommen werden
- Abgeschwächte Konsistenzanforderungen betreffen nur Leseoperationen!
- Lost Update muss generell vermieden werden, d. h., Write/Write-Abhängigkeiten müssen stets beachtet werden
Semantische IBs: Integritätsbedingungen in SQL
Trigger: Syntax nach SQL:1999
Trigger-Granulat
Trigger: Einsatzbeispiel
- Gehaltsumme in Abt soll bei Änderungen in Pers, die „Gehälter“ betreffen, automatisch aktualisiert werden
- es sind Trigger für INSERT/DELETE/UPDATE erforderlich; sie werden bei Auftreten der spezifizierten Änderungsoperationen sofort ausgeführt
Zugriffskontrolle in SQL: Vergabe von Rechten
Objekte (accessible-object)
- Relationen bzw. Sichten
- aber auch: Domänen, Datentypen, Routinen usw.
Zugriffsrechte (privileges)
- SELECT, INSERT, UPDATE, DELETE, REFERENCES, USAGE, EXECUTE, . . .
- Attributeinschränkung bei INSERT, UPDATE und REFERENCES möglich
- Erzeugung einer „abhängigen“ Relation erfordert REFERENCES-Recht auf von Fremdschlüsseln referenzierten Relationen.
- USAGE erlaubt Nutzung spezieller Wertebereiche (character sets).
- dynamische Weitergabe von Zugriffsrechten: WITH GRANT OPTION (GO: dezentrale Autorisierung)
Empfänger (grantee)
- Liste von Benutzern bzw. PUBLIC
- Liste von Rollennamen
Zugriffskontrolle in SQL: Rücknahme von Zugriffsrechten
