View. Arbeiten mit den Sichten:

Transkript

1 View "individuelle Sicht" (vgl. 3-Schichten-Modell) virtuelle Tabellen: in der DB wird nicht deren Inhalt, sondern nur die Ableitungsregel gespeichert. Arbeiten mit den Sichten: Anfragen: kein Problem. Preprocessing-Schritt: alle in den Anfrage vorkommenden View-Namen werden durch den sie definierenden Ausdruck ersetzt Syntax: CREATE VIEW viewname [(spalte[,...])] AS unterabfrage [WITH CHECK OPTION] Aber: Ist Insert, delete und update immer möglich, bzw. wird das korrekte Ergebnis erzeugt? View-Namen können überall dort aufgerufen werden, wo auch Basistabellen stehen können. Vorteile: Vermeidung von Redundanzen einfachere Zugriffsbefehle födern Wiederverwendbarkeit einfache Migrations-/ Integritätshilfe

2 Zugriffsrechte Mittels der grant-anweisung wird angegeben, welcher Benutzer auf welche Tabelle bzw. Sicht welche Zugriffsrechte erhält. Mit Revoke werden die Zugriffsrechte wieder entzogen. REVOKE {objektprivileg All},..[,...] ON [schema.objekt] FROM {user},... [CASCADE CONSTRAINTS] Syntax. GRANT {objektprivileg All},..[,...] ON [schema.objekt] TO {user},... [WITH GRANT OPTION] Objektprivilegien: alter Tabellenänderungen delete Löschen von Zeilen index Erzeugen eines Index insert Einfügen einer Zeile references Erzeugung von constraintsselect update

3 Concurrency und Recovery Der Begriff der Transaktion Recovery Rekonstruktion einer Datenbank im Fehlerfall Die Art des Fehlers darf keinen Einfluss auf die Wiederherstellbarkeit haben Eine Transaktion ist eine Folge von Operationen, welche eine gegebene Datenbank in ununterbrechbarer Weise von einem konsistenten Zustand in einen (nicht notwendig verschiedenen) konsistenten Zustand überführt. Concurrency (engl. Parallelbetrieb) Zulassen "gleichzeitiger" Zugriffe von mehreren Benutzern auf eine DB ohne, dass sich die Benutzer bemerken oder sogar stören Operationen: Wir betrachten lediglich Lese- bzw. Schreiboperationen (read, write) Auch bei gleichzeitig ablaufenden Transaktionen muß die Konsistenz der DB gewahrt bleiben!! Synchronisationsmechanismen erforderlich (concurrency control) Grundregel für Concurrency. Jede Transaktion hat so abzulaufen, als sei sie momentan allein im System.

4 Das ACID-Prinzip Atomicity (Atomarität) Das Programm wird aus der Sicht des Benutzers vollständig oder gar nicht ausgeführt. Consistency (Konsistenz) Alle Integritätsbedingungen werden eingehalten. Kommt es innerhalb der Befehle zu Konsistenzproblemen, wird die Transaktion nicht ausgeführt. Isolation Das Programm läuft isoliert von anderen Transaktionen ab. dem Programm werden nur "gesicherte" Daten aus der DB zur Verfügung gestellt, welche Teil eines konsistenten Zustands sind. Durability (Persistenz) Falls das Programm als "erfolgreich beendet" gemeldet wurde, überleben die von ihm in der DB erzeugten Effekte jeden danach auftretenden Hard- oder Softwarefehler. Concurrency-Strategien optimistische: jede Transaktion darf in der DB beliebig ändern, obige Effekte werden bewusst in Kauf genommen Wird bei Transaktionsende festgestellt, dass auch andere Transaktionen die gleichen Daten änderten, so wird ein Rollback durchgeführt und die Transaktion neu gestartet. Vorteil: leicht implementierbar Nachteil: bei häufigen Zugriffen auf bestimmte Daten müssen viele Transaktionen zurückgesetzt werden schlimmster Fall: zwei Transaktionen greifen wechselseitig auf das gleiche Datum zu, beide werden zurückgesetzt, beide starten neu, greifen wieder zu,... pessimistische alle in einer Transaktion angeforderten Daten werden für alle anderen Transaktionen gesperrt. erst bei Transaktionsende werden die Sperren wieder freigegeben.

5 Schedule 2-Phasen-Scheduler alle in einer Zeitspanne eintreffenden Transaktionen werden zu einem sog. "Schedule" zusammengefasst. Dynamische Situation bei der Verarbeitung von Transaktionen 2- Phasen: in der ersten werden nur Sperren beschafft in der zweiten nur noch Sperren freigegeben Schedule gibt darüber Auskunft, wie eine Transaktion endet: commit = erfolgreich : vollständig und ohne Unterbrechung durch einen Fehler abort = Abbruch: keine Effekte auf die DB Lesesperre: nicht exclusiv (shared modus) andere Transaktionen können ebenfalls Lesesperren auf dieses Objekt setzen Schreib-Sperre: exklusiv gesperrt andere Transaktionen können dann weder lese- noch Schreibsperren auf x setzen Sperrmatrix s s x x

6 Transaktionen in Oracle Folge von SQL-Anweisungen, die Oracle als Einheit betrachtet Transaktion beginnt mit: der ersten auszuführenden Anweisung nach COMMIT, ROLLBACK oder dem Verbinden mit der DB Transaktion endet mit COMMIT, ROLLBACK oder Beenden der Verbindung mit der DB Vor und nach DDL- Anweisungen setzt Oracle implizit commit. Syntax: COMMIT [WORK] ROLLBACK [WORK] [TO [SAVEPOINT] savepoint ] SAVEPOINT savepoint Savepoint identifiziert eine Stelle in einer Transaktion, bis zu der ein Rollback angegeben werden kann

7 Transaktionen Beispiel Buchung eines Flugs von München nach San Francisco über Frankfurt und New York! Gesamtbuchung besteht aus drei Einzelbuchungen update Flug set...; (Flug München Frankfurt) update Flug set...; (Flug Frankfurt New York) update Flug set...; (Flug New York San Fransisco) commit work, Vorreservierung der Einzelfüge, Möglichkeit der Stornierung (embedded SQL) exec sql update Flug set...; //Flug München Frankfurt exec sql update Flug set...; // Flug Frankfurt New York exec sql update Flug set...; (Flug New York San Fransisco) cout << "Wollen Sie den Gesamtflug fest buchen? (j/n):" ; getchar(zeichen); if (zeichen =="j") { exec sql commit work; // transaktion erfolgreich beendet cout << "der Flug ist gebucht\n" } else { exec sql Rollback work; //Transaktion wird zurückgesetzt cout << "der Flug wurde storniert\n"; }

8 Recovery Aufgabe des Recovery: Wiederherstellung eines konsistenten Datenbestandes nach Fehlern Methoden und Werkzeuge zur Wiederherstellung der Datenkonsistenz Duplizierung des Datenbestandes und Arbeiten mit Kopien (unüblich) Mitprotokollieren aller Datenbankänderungen (Logfile) Klassifizierungsarten des recovery Benutzer- und Programmierfehler Systemfehler in Form des Verlustes von Arbeits speicherinhalten Speicherfehler durch Schaden am dauerhaften Speichermedium Daraus resultierten folgende Fehlerklassen: Fehlerklasse Maßnahme Transaktionsfehler Rücksetzen der Transaktion (Rollback) Systemfehler Neustart (Instance-Recovery) Speicherfehler Rekonstruktion (Media- Recovery) Im Logfile (auch Journal ) werden alle Zugriffe auf die DB mitgeschrieben u.a. Beginn- und Endemarken einer Transaktion, Checkpoints Inhalte der bearbeiteten Objekte vor ("before-image") nach ("after-image") einer Operation Speicherung der Logdateien auf nichtflüchtigen Medien (persistent) nicht auf dem selben Medium, auf dem bereits die DB gespeichert ist

9 Funktionen der Logdatei und des DB-Puffers Metadaten: welche Daten stehen im Puffer, welche Transaktionen sind offen Synchronisation Puffer- und Logdateizugriff Transaktionsbetrieb mit Log und Arbeitsspeicherpufferung Lesen Daten werden von der Platte eingelesen, falls sie sich nicht bereits im Puffer des Arbeitsspeichers befinden Merken der Die zu ändernden daten werden in die Logdatei bisherigen Daten geschrieben (before images) Ändern der Daten Ändern (update, delete, insert) der Daten im Arbeitsspeicher, Sperren dieser Einträge für andere Benutzer Merken der Die geänderten Daten werden in die Loddatei geänderten Daten geschrieben (after-image)... während einer Transaktion evtl mehrmals Transaktionensende COMMIT: Schreiben evtl. noch nicht geschriebener mit COMMIT bzw. before- und after-images und benötigter Metadaten ROLLBACK zu dieser Transaktion in die Logdatei. Transaktionsende in der Logdatei vermerken. Sperren freigeben Rollback: Rücksetzen der Metadaten der Transaktion. Geänderte Daten im Arbeitsspeicher mittels der before-images restaurieren Alle geänderten Daten, die bereits in die DB geschrieben wurden, werden für ungültig erklärt. Sperren freigegeben Änderungen Die geänderten Daten werden asynchron speichern (unabhängig vom Transaktionsbetrieb) in die Datenbank geschrieben