Datenintegrität und Transaktionskonzept

Transkript

1 und Transaktionskonzept 1. / Datenkonsistenz 1 Mögliche Gefährdung der : 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 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 2

2 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 3 TA-Verwaltung bei mehreren Benutzern: 4 Synchronisation zwingend erforderlich! Probleme bei fehlender Synchronisation: 1. Lost-Update (Verlorengegangene Änderung) 2. Zugriff auf schmutzige Daten ("dirty read", "dirty write") 3. Nicht-wiederholbares Lesen 4. Phantomproblem 5. Inkonsistente Analyse

3 1. Lost-Update Problem 5 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) t 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

4 5. Inkonsistente Analyse 7 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) -> S=900 t2 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) S=1100 t8 8 Mehrbenutzersynchronisation durch Transaktionskonzept (serialisierbare) Schedules Sperrenverfahren

5 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 Transaktionen und Schedules 10 TA-a Prog.1 Prog.2 TA-c TA-b TA-d Serielle Bearbeitung von Transaktionen Prog.3 Zeit Prog.a Prog.b Prog.c Verzahnte Bearbeitung von Transaktionen Zeit

6 11 Der Scheduler... a3 a2 a1 TA-a.. b3 b2 b1 Scheduler.. c2 a3 b2 c1 a2 b1 a1 Datenbank TA-b TA-c... c3 c2 c1 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 12

7 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 Einfluß der Sperren auf andere Transaktionen Aktueller Modus Angeforderte Sperre Keine Sperre Shared lock Exclusive lock Shared lock Exclusive lock

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

9 17 Zusammenfassung: Maßnahmen zur Sicherstellung der 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