Datenintegrität und Transaktionskonzept - home.hs
Werbung
Datenbanken Datenintegrität 1 Datenintegrität und Transaktionskonzept 1. Datenintegrität/ Datenkonsistenz Mögliche Gefährdung der Datenintegrität: Missachtung von Konsistenzbedingungen ("Semantische Integrität") Inkorrekte Verweise auf Datensätze in verschiedenen Tabellen ("Referentielle Integrität") System- oder Speicherfehler, während "zusammengehörende Befehle" noch nicht vollständig durchgeführt werden konnten Konkurrierende Zugriffe mehrerer Benutzer auf dieselben Daten Prof.Dr.Kühn / Fb W Datenbanken 2006 FK4-IMM-TA.DOC Datenintegrität 2 Transaktionskonzept Transaktion • Folge logisch zusammengehöriger Befehle • Eine Transaktion muß jeweils eröffnet und geschlossen werden • Falls eine Transaktion nicht abgeschlossen werden kann, müssen alle ihre Datenänderungen rückgängig gemacht werden Transaktionsmonitor • Bestandteil des DBMS / überwacht Transaktionsprogramme Transaktionsprogramm • Anwendungsprogramm, das unterschiedliche Transaktionen abhängig vom Transaktionscode durchführt • Kann viele Benutzer gleichzeitig bedienen • Der Benutzer bestimmt die auszuführende Transaktion durch Angabe eines Transaktionscodes Prof.Dr.Kühn / Fb W 2006 FK4-IMM-TA.DOC Datenbanken Datenintegrität 3 TA-Verwaltung bei einem Benutzer (Wiederanlauf nach Fehler) 1. Lokaler Fehler einer TA • Fehler im Anwendungsprogramm • Abbruch durch Benutzer • Systemgesteuerter Abbruch Aktion: • v. d. TA verursachte Änderungen müssen rückgängig gemacht werden • tritt häufig auf; Recoveryzeit: Millisekunden 2. Fehler mit Hauptspeicherverlust • Betriebssystemabsturz • Stromausfall Aktion: • alle Datenänderungen müssen nachvollzogen werden, die "commited sind", aber noch nicht in den DB-Tabellen stehen (globales redo) • Noch nicht dauerhaft gemachte Änderungen müssen rückgängig gemacht werden (globales undo); Tritt seltener auf; Recoveryzeit: Minuten Prof.Dr.Kühn / Fb W Datenbanken 2006 FK4-IMM-TA.DOC Datenintegrität 4 TA-Verwaltung bei mehreren Benutzern: Synchronisation zwingend erforderlich! Probleme bei fehlender Synchronisation: 1. 2. 3. 4. 5. „Lost-Update“ (Verlorengegangene Änderung) Zugriff auf „schmutzige Daten“ ("dirty read", "dirty write") Nicht-wiederholbares Lesen Phantomproblem Inkonsistente Analyse Prof.Dr.Kühn / Fb W 2006 FK4-IMM-TA.DOC Datenbanken Datenintegrität 5 1. Lost-Update Problem Transaktion A FETCH Satz1 UPDATE Satz1 Zeit Transaktion B t1 t2 FETCH Satz1 t3 t4 UPDATE Satz1 2. Zugriff auf „schmutzige Daten“ Transaktion A Zeit Transaktion B t1 UPDATE Satz1 FETCH Satz1 (dirty read) t2 t3 ROLLBACK UPDATE Satz1 (dirty write) t4 Prof.Dr.Kühn / Fb W Datenbanken 2006 FK4-IMM-TA.DOC Datenintegrität 6 3. Nicht wiederholbares Lesen Transaktion A Zeit Transaktion B t1 FETCH Satz1 UPDATE Satz1 t2 COMMIT t3 FETCH Satz1 4. Phantom-Problem Sonderform des nicht-wiederholbaren Lesens, in Verbindung mit einem INSERT oder UPDATE In der Lesetransaktion L erfolgt ein mengenorientiertes Lesen mit einem bestimmten Suchprädikat. Durch eine Änderungstransaktion wird die Menge der sich für das Suchprädikat qualifizierenden Objekte geändert Phantomproblem für L Prof.Dr.Kühn / Fb W 2006 FK4-IMM-TA.DOC Datenbanken Datenintegrität 7 5. Inkonsistente Analyse Anfangswerte: K1=400, K2=500, K3=300 ( S=1200) Transaktion A Zeit Transaktion B FETCH Satz1 (K=400) t1 -> S=400 FETCH Satz2 (K=500) t2 -> S=900 t3 FETCH Satz3 (K=300) t4 UPDATE Satz3 (K=300) (300 -> 200) t5 FETCH Satz1 t6 UPDATE Satz1 (K=400) (400 -> 500) t7 COMMIT FETCH Satz3 (K=200) t8 S=1100 Prof.Dr.Kühn / Fb W 2006 Datenbanken FK4-IMM-TA.DOC Datenintegrität 8 Mehrbenutzersynchronisation durch Transaktionskonzept • • (serialisierbare) Schedules • Prof.Dr.Kühn / Fb W Sperrenverfahren 2006 FK4-IMM-TA.DOC Datenbanken Datenintegrität 9 Geforderte Eigenschaften von Transaktionen (ACID-Eigenschaften): ♦ Atomarität: eine Transaktion stellt eine Folge von logisch zusammengehörigen Befehlen dar, die entweder als Ganzes oder gar nicht wirksam werden. ♦ Konsistenz: Eine Transaktion überführt die Datenbank von einem konsistenten Zustand in einen wiederum konsistenten Zustand. Hierzu können beim Datenbank-Entwurf auch semantische Integritätsbedingungen festgelegt werden, die das DBMS zu überwachen hat (Bsp: Wertebereich f. e. Attribut, best. Attributwerte eindeutig, ...). ♦ Isolation: trotz Mehrbenutzerbetrieb bleiben die einzelnen Transaktionen voneinander isoliert („logischer Einbenutzbertrieb“). Dies wird erreicht durch Synchronisationsmaßnahmen wie z.B. Sperrverfahren. ♦ Dauerhaftigkeit: die Ergebnisse von einmal akzeptierten Transaktionen (nach COMMIT) gehen auch bei künftigen Fehlern (Systemabsturz, Speicherausfall) nicht verloren Prof.Dr.Kühn / Fb W 2006 Datenbanken FK4-IMM-TA.DOC Datenintegrität 10 Transaktionen und Schedules TA-a TA-b Prog.1 Prog.2 TA-c Serielle Bearbeitung von Transaktionen TA-d Prog.3 Zeit Verzahnte Bearbeitung von Transaktionen Prog.a Prog.b Prog.c Zeit Prof.Dr.Kühn / Fb W 2006 FK4-IMM-TA.DOC Datenbanken Datenintegrität 11 Der Scheduler ... a3 a2 a1 TA-a Scheduler .. b3 b2 b1 Datenbank .. c2 a3 b2 c1 a2 b1 a1 TA-b ... c3 c2 c1 TA-c Prof.Dr.Kühn / Fb W Datenbanken 2006 FK4-IMM-TA.DOC Datenintegrität 12 Mehrbenutzersynchronisation: "Schedules" und Serialisierbarkeit 1."Schedule"= Gesamtheit aller Lese- und Schreibanweisungen aller betrachteten Transaktionen 2.Die einfachste Art zur Sicherstellung eines korrekten Ablaufs: jeweils alle Anweisungen einer Transaktion geschlossen nacheinander ablaufen lassen, die Transaktionen unterschiedlicher Benutzer laufen nacheinander ab. Ein solcher Schedule heisst "serieller Schedule" 3.Ein Schedule heißt „serialisierbar“ (oder „korrekt synchronisiert“), wenn es (irgend-) eine serielle Ausführung der Transaktionen gibt, die denselben Datenbankzustand erzeugt, wie der betrachtete Schedule aus verzahnten Anweisungen. ---------------------------Um einen korrekten Schedule zu ermöglichen, d.h. die Aktionen verschiedener Transaktionen so voneinander zu trennen, dass sie sich nicht beeinträchtigen, werden meist Sperrenverfahren verwendet Prof.Dr.Kühn / Fb W 2006 FK4-IMM-TA.DOC Datenbanken Datenintegrität 13 Sperren-Verfahren Prinzip: Teile der Datenbank werden für andere Transaktionen gesperrt, sobald eine Transaktion auf Daten zugreift. Unterschiede: Sperrgröße, Art der Sperre Mögliche Sperrgrößen: ♦ Tablespace (nur in Sonderfällen) ♦ Relation ♦ Tupel (Zeile) ♦ Attribut Mögliche Sperrarten: ♦ shared lock Andere TAs dürfen auch ein „shared lock“ setzen, aber kein „exclusive lock“ Häufig von lesender TA veranlasst (nicht Standard bei Oracle) ♦ exclusive lock Andere TAs dürfen überhaupt keine Sperre setzen. Häufig von schreibender TA veranlasst Prof.Dr.Kühn / Fb W 2006 Datenbanken FK4-IMM-TA.DOC Datenintegrität 14 Einfluß der Sperren auf andere Transaktionen Aktueller Modus Angeforderte Sperre Shared lock Exclusive lock Prof.Dr.Kühn / Fb W Keine Sperre Shared lock Exclusive lock + + + -- --- 2006 FK4-IMM-TA.DOC Datenbanken Datenintegrität 15 Zwei-Phasen Sperrprotokoll (führt zu serialisierbaren Schedules) Regeln: 1.Jedes Objekt, das von einer TA benutzt werden soll, muß vorher gesperrt werden 2.Eine TA fordert eine Sperre, die sie besitzt, nicht erneut an 3.Wenn einer TA eine Sperre wegen einer anderen vorhandenen TA nicht gegeben werden kann, so muß die später kommende TA warten. 4.Jede TA durchläuft 2 Phasen • eine Wachstumsphase, in der sie Sperren anfordern aber keine freigaben darf • einer Schrumpfungsphase, in der Sie gesetzte Sperren freigeben, aber keine neuen anfordern darf. 5.Bei Transaktionsende werden alle Sperren freigegeben Beachte: Serialisierbarkeit führt zu Geschwindigkeitsverlusten. Prof.Dr.Kühn / Fb W Datenbanken 2006 Datenintegrität FK4-IMM-TA.DOC 16 Der SQL92 Standard unterscheidet 4 Konsistenzstufen. Diese werden unterschieden nach den Anomalien die auftreten können („lost update“ darf nie vorkommen): Anomalie Konsistenzstufe Dirty Non repeatable Phantome read read Read un-commited + + + Read committed + + Repeatable read + Serializable +: kann auftreten; -: kann nicht auftreten Prof.Dr.Kühn / Fb W 2006 FK4-IMM-TA.DOC Datenbanken Datenintegrität 17 Zusammenfassung: Maßnahmen zur Sicherstellung der Datenintegrität • Semantische und referentielle Integrität weitgehend in der Verantwortung Benutzers unterstützt durch DBMS (Constraints, Check-Klausel, Trigger) • Ablaufintegrität: Verantwortung des DBMS Transaktionskonzept, Scheduler, Sperrenverfahren u. Transaktionsmonitor zur Mehrbenutzersynchronisation • Schutz vor Datenverlust: Benutzer und DBMS Backups:Laufende Sicherung beim Betrieb periodische Sicherung größerer Datenmengen Kontrollpunkte für Wiederanlauf Katastrophenvorsorge Prof.Dr.Kühn / Fb W 2006 FK4-IMM-TA.DOC
