C. Mohan Recovery und Transaktionen

Transkript

1 Hauptseminar Database Hall of Fame C. Mohan Recovery und Transaktionen Christopher Lewis 11. Dezember 2001

2 Inhaltsverzeichnis 1 Einleitung Zur Person Motivation Überblick ARIES Buffer Management Write Ahead Logging (WAL) Datenstrukturen Logical Logging Page-oriented Logging Ziele Vorgehen von ARIES Normal Processing Restart Recovery Ein komplexeres Beispiel Erweiterte Problemstellungen Zusammenfassung und Ausblick Eigenschaften von ARIES Implementierungen von ARIES

3 Kapitel 1 Einleitung Diese Ausarbeitung soll eine Beschreibung des ARIES-Systems liefern, welches sich mit dem Thema Recovery und Transaktionen in Datenbanksystemen beschäftigt. Das System ARIES wurde von C. Mohan (et al.) entwickelt. 1.1 Zur Person C. Mohan ist seit 1981 für IBM tätig und arbeitet dort am Almaden Research Center in Kalifornien. Seine Haupttätigkeiten sind Recovery und Transaktionsmanagement in Datenbanksystemen. Weiterhin arbeitete er an den Projekten R* und Starburst. Die hier vorgestellten Thesen zum Transaktionssystem ARIES veröffentlichte er 1992 zusammen mit einigen Kollegen [TODS]. Für seine Arbeit an ARIES erhielt er 1996 den SIG- MOD Innovations Award [SIGMOD] der Association for ComputingMachinery [ACM]. Im Jahre 1997 wurde er zum IBM Fellow ernannt, welches die höchste technische Auszeichnung bei IBM darstellt. 1.2 Motivation Seit jeher ist effiziente Fehlerbehandlung in Datenbanksystemen ein brisantes Thema. Kommerziell eingesetzte Datenbanken beinhalten eine Fülle an wichtigen Daten, deren Konsistenz von großer Bedeutung ist. Läuft eine Transaktion im laufenden Betrieb auf einen Fehler oder stürzt sogar das ganze System ab, so ist sehr daran gelegen, möglichst schnell wieder einen konsistenten Zustand zu erreichen und verlorengegangene Daten wiederherzustellen. In heutigen Datenbanken werden Daten von einer Großzahl von Benutzern gleichzeitig eingefügt, verändert oder gelöscht. Deswegen werden Transaktionen nicht sofort für alle anderen Benutzer sichtbar gemacht, sondern erst, wenn die Transaktion einen zulässigen Zustand erreicht hat. Tritt vor diesem Commit ein Transaktionsfehler auf, ist die Datenbank in einem inkonsistenten Zustand und es muss eine entsprechende Behandlung eingeleitet werden, d.h. alle Änderungen bis zu einem konsistenten Zustand müssen zurückgesetzt 2

4 KAPITEL 1. EINLEITUNG 3 werden (Undo). Weiterhin ist zu beachten, dass aus Performanzgründen auch bei einem Commit nicht alle Modifikationen sofort in den Hintergrundspeicher geschrieben werden. Im Falle eines Systemfehlers vor dem Speichern gehen solche Datenänderungen verloren. Diese müssen somit wiederhergestellt werden (Redo), um das ACID-Konzept (hier Durability) zugewährleisten. Im Folgenden wird zwischen zwei Fällen unterschieden: Normal Processing Im normalen Betrieb läuft eine Transaktion auf einen Fehler und es muss ein sog. Rollback (= Undo) vorgenommen werden, d.h., alle Aktionen der Transaktion werden in umgekehrter Reihenfolge rückgängig gemacht, bis ein konsistenter Zustand erreicht ist (Savepoint oder Begin Transaction, siehe 2.3). Restart Recovery Das gesamte Datenbanksystem ist abgestürzt und muss neu gestartet werden. Hier ist es besonders wichtig, dass die Daten sich nach diesem Vorgang wieder in einem zulässigen Zustand befinden und keine Änderungen aus Transaktionen, die diese bereits freigegeben, also committed haben, verloren gegangen sind. Das Recovery-System hat in diesen Fehlerfällen für die Einhaltung des Transaktionskonzepts zu sorgen. Ein wichtiger Aspekt dabei ist auch der dafür verwendete Zusatzaufwand. Dieser soll so gering wie möglich ausfallen und insbesondere soll der Parallelitätsgrad (Concurrency) von Transaktionen nicht übermässig reduziert werden.

5 Kapitel 2 Überblick ARIES ARIES steht für Algorithm for Recovery and Isolation Exploiting Semantics. Es handelt sich dabei um eine Transaktions-Recovery-Methode, die das Prinzip des sog. Write-Ahead Logging (WAL) verwendet. Mit ARIES sind Teil-Rückläufe (Partial Rollbacks) und sehr feinaufgelöste Sperren (Fine-granularity Locking) möglich. Im Folgenden sollen einige wichtige Rahmenbedingungen von ARIES diskutiert werden. 2.1 Buffer Management Der Buffer Manager ist eine Art Schnittstelle zwischen dem Massenspeicher und dem Transaktionssystem. Er besitzt einen Pufferspeicher, in dem logische Seiten zwischengespeichert werden können. Wird eine Seite von einer Transaktion angefordert, sucht der Buffer Manager in seinem Puffer, ob diese dort bereits vorhanden ist. Ist dies nicht der Fall, wird ein neuer Platz (Slot) freigemacht und die Seite dorthin eingelesen. Will eine Transaktion schreibend auf eine Seite im Puffer zugreifen, muss sie das Fix- Attribut setzen, was eine entsprechende Sperre aktiviert. Wurde eine Seite im Puffer verändert, haben sich diese Änderungen aber noch nicht im Hintergrundspeicher auf der entsprechenden Seite niedergeschlagen, so wird diese Seite als dirty (schmutzig) bezeichnet. Der Buffer Manager schreibt im Hintergrund solche dirty pages in den Hintergrundspeicher. Dies setzt aber voraus, dass diese Seiten nicht mehr gesperrt sind, also das Fix-Attribut nicht mehr gesetzt ist und entsprechende Latches (extrem kurzzeitige Sperren auf physikalischer Ebene) entfernt wurden. Es existieren verschiedene Strategien für dieses Speichern von Seiten im Hintergrund. Bei der steal policy können Seiten bereits persistent gespeichert werden, bevor die entsprechende Transaktion committed hat. Dies kann bedeuten, dass bei der Recovery einige Undo- Vorgänge auf dem Hintergrundspeicher vorgenommen werden müssen. Können umgekehrt Transaktionen erst committen, wenn alle Änderungen gespeichert sind, spricht man von force policy. In diesem Fall müssen beim Redo keine Änderungen von Transaktionen wiederholt werden, die bereits committed haben. 4

6 KAPITEL 2. ÜBERBLICK ARIES Write Ahead Logging (WAL) WAL bedeutet, dass alle Änderungen (Updates) auf dem Hintergrundspeicher vor ihrer Durchführung in einem Log protokolliert werden; solche LogRecords müssen vor dem entsprechenden Update persistent gespeichert werden. Jedes Log Record ist über seine Log Sequence Number (LSN) eindeutig referenzierbar. Ein Log wird bei der Recovery verwendet, um Aufschluss über die vorzunehmenden Undo- und Redo-Aktionen zu bekommen. ARIES setzt voraus, dass der Buffer-Manager (siehe Abschnitt 2.1) nach dem WAL- Protokoll verfährt. Wurde das zur aktuellen Seite gehörige Log Record noch nicht gespeichert, so müssen zunächst alle vorherigen Einträge im Log inklusive diesem in den Speicher geschrieben werden (Forcing). WAL erlaubt, dass geänderte Seiten an dieselbe Stelle im Hintergrundspeicher zurückgeschrieben werden, von der sie gelesen wurden (sog. in-place updating). Im Unterschied dazu müssen bei der Shadow-Page-Technik Seiten immer an einer anderen Stelle gespeichert werden als dort, wo sie gelesen wurden, um die alte Version für das Undo verwenden zu können. Dies ist bei WAL nicht nötig, da die Undo-Information dem Log entnommen werden kann Datenstrukturen An dieser Stelle soll ein wenig auf die Datenstruktur von Records, Seiten und gewissen Tabellen eingegangen werden. Am interessantesten gestaltet sich der Aufbau eines Log Records. In ihm ist nicht nur die reine Re/Undo-Information gespeichert, sondern auch u.a. seine logsequence number (LSN). Weiterhin gibt das Record Auskunft über seinen Typ (Type, z.b. update oder compensation ), die Transaktion, die dieses Record erstellt hat (TransID), und das vorhergehende log record (PrevLSN). Handelt es sich um ein Log Record für eine Undo-Operation, so wird in dem Feld UndoNextLSN die LSN der vorherigen Änderung gespeichert (siehe dazu auch Abschnitt 3.1 auf Seite 9). Mittels dem Feld PageID kann die zugehörige Seite ermittelt werden, die von diesem Record betroffen ist. Umgekehrt speichert jede Seite im Feld page LSN die Adresse desjenigen Log Records, das als letztes die Seite verändert hat. Bei der Restart Recovery wird eine Tabelle verwendet, in der alle aktiven Transaktionen gespeichert werden (Transaction Table). Für jedes Element in dieser Tabelle werden einige Daten gespeichert, wie Zustand (State), das letzte Log Record (LastLSN) und das nächste zu verarbeitende Record (UndoNextLSN). Auch die bereits in 2.1 erwähnten dirty pages werden in einer Tabelle aufgelistet. Diese gibt Auskunft über Updates auf Seiten im Puffer, die noch nicht gespeichert sind.

7 KAPITEL 2. ÜBERBLICK ARIES Logical Logging Auf der logischen Ebene werden Operationen auf Tupeln (Records) betrachtet, beispielsweise add tuple t set x (x+5) Dies ist beim Redo nicht unbedingt von Vorteil: So werden von einem Update meist mehrere Seiten berührt; welche dies sind, muss durch eine Untersuchung des Index-Baums ermittelt werden. Außerdem werden hier bei einem Redo möglicherweise andere Seiten verändert als beim ursprünglichen Update. Dies kann zu Problemen und erhöhtem Overhead führen. Vorteil des Logical Logging ist, dass eine Transaktion Updates, die von einer anderen durchgeführt wurden, aber noch nicht freigegeben sind, in eine andere Seite schreiben kann. Dies bewirkt einen hohen Parallelitätsgrad, da sonst die zweite Transaktion auf die erste warten müsste, bis diese ihre Änderungen committed hat Page-oriented Logging Hier werden die Änderungen auf Seitenebene protokolliert. Beim Redo muss demnach immer dieselbe Seite modifiziert werden wie bei der ursprünglichen Operation. Dies ermöglicht eine höhere Datenunabhängigkeit. Page-oriented Undo bedeutet, Log Records speichern den Inhalt der Seite vor und nach der Änderung (sog. before- und after-images). Dies kann zu erhöhtem Speicherplatzbedarf führen. Neben der gerade vorgestellten Trennung (logical/page-oriented logging) gibt es noch ein weiteres Konzept des Loggings, nämlich die Betrachtung von value/state (Änderungen von Werten/Zuständen) und operation logging (Änderung auf Operationen-Ebene). Während page-oriented logging beide Vorgehensweisen unterstützt, bedingt logical logging das Prinzip des operation logging, da nur dies eine effektive Protokollierung auf logischer Ebene zur Verfügung stellt. Dies bedeutet, dass nicht alle Änderungen explizit gespeichert werden müssen (z.b. die Menge des freien Speichers in der Seite); auf diese Weise kann Speicherplatz für das Log gespart werden. 2.3 Ziele Nachfolgend werden kurz die Ziele der ARIES-Methode beschrieben. Um die Fehleranfälligkeit zu senken, soll der in ARIES vorgestellte Algorithmus möglichst einfach sein. Werden außer Wert- und Zustandsänderungen auch Operationen protokolliert, so erlaubt dies sehr mächtige Sperrverfahren. So können zwei Transaktionen die gleichen Daten modifizieren, ohne dass eine der beiden diese vorher committen müsste, wenn dies semantisch kompatibel ist (z.b. bei In- oder Dekrement). Diese Methode (operation logging) wird

8 KAPITEL 2. ÜBERBLICK ARIES 7 in Abschnitt beschrieben. Um eine höhere Concurrency zu erreichen, sollen möglichst feine (d.h. auf sehr niedriger Ebene) und kurzzeitige Sperren verfügbar sein (fine-granularity locking). Neben einer flexiblen Puffer- und Speicherverwaltung (d.h., ARIES soll das Buffer Management nicht beeinflussen) ist ein weiteres Ziel die Möglichkeit des Partial Rollback, also ein Rückgängigmachen nur eines Teils der letzten Aktionen. Hierbei werden sog. Savepoints innerhalb der Transaktionen eingerichtet. Ein partial rollback führt dann das Undo nur bis zum letzten Savepoint aus. Wie bereits in erwähnt, spielt die Unabhängigkeit (recovery independence) bei der Wiederherstellung eine große Rolle. Das Re/Undo eines Objekts (Seiten bzw. Tupel) soll nach Möglichkeit keinen Einfluss auf andere Objekte haben. Ein letztes Ziel ist minimaler Overhead. Die Größe der Log-Dateien und des verbrauchten Speichers soll so klein wie möglich sein. Diese Ziele stehen teilweise im Widerspruch zueinander. Es war die Herausforderung bei der Entwicklung von ARIES, hier einen akzeptablen Kompromiss zu erreichen.

9 Kapitel 3 Vorgehen von ARIES Dieses Kapitel beschäftigt sich mit den bereits vorgestellten Szenarien, die für ARIES interessant sind, nämlich Transaktionsmanagement und Fehlerbehandlung (Rollback) im normalen Datenbankbetrieb (Normal Processing) auf der einen Seite und das Verhalten nach einem Absturz (Restart Recovery Processing) auf der anderen. Obwohl Recovery ein sehr komplexes Thema darstellt, ist der Hauptalgorithmus von ARIES sehr einfach gehalten. Alle Änderungen an der Datenbank werden in einer Datei protokolliert (geloggt); auch wenn eine Modifikation rückgängig gemacht wird, so ist hierfür ebenfalls ein Eintrag vorzunehmen. Solche Records werden compensation logrecords (CLRs) genannt; sie können zwar wiederholt ausgeführt werden, werden aber beim Undo gesondert behandelt. 3.1 Normal Processing Sämtliche Updates auf Records werden auf der zugehörigen Seite im Buffer Manager durchgeführt. Nachdem das Record gesperrt wurde, wird die Seite vom Buffer Manager angefordert, das Fix-Attribut gesetzt, die Änderung dort durchgeführt und anschließend die Sperre wieder aufgehoben. Wie in 2.2 erwähnt, wird zur Einhaltung des WAL-Protokolls erst ein Log Record geschrieben, bevor die Seite gespeichert wird. ARIES unterstützt das Prinzip des Partial Rollback, d.h. ein Undo nur bis zu einem bestimmten Punkt (Savepoint) anstatt die komplette Transaktion rückgängig zu machen. Einige Datenbanksysteme (z.b. IBM DB2) nutzen dieses Konzept und setzen vor jeder schreibenden Aktion einen Savepoint, um die Atomizität, die vom ACID-Verfahren gefordert wird, auf Anweisungsebene zu gewährleisten. Abbildung 3.1 zeigt den Ablauf eines Partial Rollback in einer Transaktion mit 3 Aktionen. Nach der Ausführung der ersten Aktion wird ein Savepoint gesetzt, die Änderung also in den Hintergrundspeicher geschrieben. Nach der dritten Aktion tritt ein Fehler auf (z.b. eine Integrity-Constraints-Verletzung o.ä.). Die letzten beiden Aktionen (2 und 3) müssen in umgekehrter Reihenfolge rückgängig gemacht werden. Für jedes Undo wird ein entsprechendes CLR (3 und 2 ) im Log angefügt. In solchen CLRs wird außerdem ein Eintrag 8

10 KAPITEL 3. VORGEHEN VON ARIES SP T Gespeicherte Änderung T Transaktionsfehler Nicht gespeicherte Änderung SP Savepoint I Undo für Aktion I Abbildung 3.1: Partial Rollback nach Inkonsistenz (UndoNextLSN) vorgenommen, in dem die Adresse des Vorgängers des durch dieses CLR zurückgesetzten Records gespeichert ist, um in einem möglichen weiteren Undo-Fall nachvollziehen zu können, welche Aktionen nicht noch einmal zurückgesetzt werden müssen. Da wir mit Logical Undo arbeiten, müssen die Undo-Operationen nicht das exakte Gegenteil der Original-Aktion sein, denn in dem entsprechenden CLR ist ja die vorzunehmende Undo-Aktion vermerkt. Allgemein kann beim Undo im normalen Datenbankbetrieb (anders als bei der Restart Recovery, siehe 3.2) davon ausgegangen werden, dass die Änderungen, die zurückgesetzt werden, auch wirklich durchgeführt wurden, d.h. ein früheres Update ist immer auf einer Seite vorhanden (zumindest im Puffer). Nach dem Undo der Aktionen 3 und 2 kann an dieser Stelle die Transaktion wieder fortgesetzt werden (also mit Aktion 2). Tritt jetzt wieder ein Fehler auf, so müssen bereits rückgängig gemachte Aktionen und deren CLRs nicht noch einmal zurückgesetzt werden; aus dem Feld UndoNextLSN eines CLRs kann die nächste Aktion ermittelt werden, deren Änderungen wirksam sind und deshalb aufgehoben werden müssen. Abbildung 3.2 zeigt einen solchen Fall, bei dem gleich nach der ersten Änderung ein Fehler auftritt.

11 KAPITEL 3. VORGEHEN VON ARIES 10 1 T 1 1 T 1 UndoNextLSN UndoNextLSN Abbildung 3.2: Erneuter Fehler nach einem Rollback 3.2 Restart Recovery Bei einem Systemneustart nach einem Fehler gestaltet sich die Recovery folgendermaßen: Zunächst wird das Log analysiert und daraus die vorzunehmenden Aktionen ermittelt. Dieser Analysis Pass beginnt bei der LSN des letzten durchgeführten Checkpoints. Dabei wird die Tabelle der dirty pages aufgebaut; wird ein Log Record für eine Seite gefunden, die noch nicht in dieser Tabelle steht, wird sie dort eingefügt und im Feld RecLSN das aktuelle Log Record gespeichert. Die Transaktionstabelle wird ebenfalls auf den neuesten Stand gebracht. Weiterhin wird im Feld RedoLSN das Log Record gespeichert, an dem die nächste Phase beginnen soll. Daraufhin werden alle Aktionen, deren Änderungen geloggt, aber nicht persistent gespeichert wurden, wiederholt (Redo Pass). Dies geschieht auf Grundlage der soeben erstellten dirty-pages-tabelle, die ja Änderungen wiederspiegelt, die noch nicht gespeichert wurden. Wird dort eine Seite gefunden, bei der die Werte page LSN und RecLSN kleiner als die LSN des zugehörigen Log Records sind, so wird ein Redo durchgeführt. Nachdem die Datenbank jetzt wieder auf dem Stand vor dem Fehler ist, müssen bereits durchgeführte Aktionen verlorengegangener Transaktionen (die also nicht committed haben) wieder rückgängig gemacht werden (Undo Pass). Dies geschieht auf exakt die gleiche Weise wie bei einem normalen Rollback (siehe Abschnitt 3.1). Als Eingabe fungiert die in der Analysephase erstellte Transaktionstabelle. Dies soll nun an einem ähnlichen Beispiel (Abbildung 3.3) verdeutlicht werden: Als Ausgangssituation nehmen wir an, dass die erste Aktion bereits gespeichert wurde. Nach der dritten Aktion trat ein Systemfehler auf. Der Analysis Pass stellt fest, dass alle Aktionen nach der ersten dirty sind. Im Redo Pass werden also die Aktionen 2 und 3 erneut ausgeführt. Nun sind wir wieder auf dem Stand vor dem Systemfehler. Es wird erkannt, dass die Transaktion nicht bis zum Ende ausgeführt wurde (also kein Commit gesetzt wurde); also muss sie zurückgesetzt werden. Dazu werden die Aktionen 3, 2 und 1 (in dieser Reihenfolge) widerrufen. Zu beachten ist, dass bei der Restart Recovery im Unterschied zum normalen Rollback nicht alle Updates notwendigerweise auf den Seiten vorhanden sein müssen. Dies ist der

12 KAPITEL 3. VORGEHEN VON ARIES S Redo: 2 3 S Systemfehler Undo: Abbildung 3.3: Restart Processing Fall, wenn nicht alle Updates wiederholt werden, also kein RepeatingHistory bzw. Redo ALL durchgeführt wird, und kann zu Problemen führen, wie nachfolgend in Abschnitt 3.3 aufgezeigt wird. 3.3 Ein komplexeres Beispiel An dieser Stelle soll anhand eines etwas komplexeren Beispiels aufgezeigt werden, warum ARIES RepeatingHistory vornimmt, also alle noch nicht gespeicherten Änderungen wiederholt, auch wenn die zugehörigen Transaktionen nicht committed haben. Unsere Ausgangssituation (Abbildung 3.4) besteht aus zwei Transaktionen (T1 und T2), T1a T2 T1b T1 S LSN: CT LSN der Seite: 10 CT Commit Transaction Abbildung 3.4: Ausgangssituation des Selective Redo Problems die auf derselben Seite arbeiten. Nach der ersten Änderung durch T1 (T1a) wird die Seite gespeichert (LSN 10). Nun führen nacheinander T2 und T1 Änderungen (T2 und T1b, LSN 20 und 30) auf der Seite aus, die aber nicht mehr gespeichert werden können, da davor ein

13 KAPITEL 3. VORGEHEN VON ARIES 12 Systemfehler auftritt. Vorher setzt T1 aber noch ein commit (CT). Nun beginnt der Redo Pass (Abbildung 3.5). Würden wir mit Selective Redo arbeiten, al- Redo: T1b T1c LSN: 30 LSN der Seite: 30 Abbildung 3.5: Der Selective Redo Pass so nur Transaktionen wiederherstellen, die committed haben, würde nur T1b durchgeführt (T1a ist ja bereits im Hintergrundspeicher), nicht aber T2, da das bei dieser Transaktion ja nicht der Fall ist. Die LSN der Seite wird nun auf die LSN des letzten Log Records (30) gesetzt. Im darauffolgenden Undo Pass (Abbildung 3.6) werden alle Änderungen zurückgesetzt, Undo: T2 LSN: 20 LSN der Seite: 30 Abbildung 3.6: Undo Pass nach einem Selective Redo deren LSN kleiner als die LSN der Seite (momentan 30) ist. In unserem Fall also auch die Änderung von T2, die aber gar nicht durchgeführt wurde. Es ist leicht verständlich, dass ein solches Szenario zu unvorhergesehenen Inkonsistenzen führen kann. Wird im Gegensatz dazu die Repeating-History-Methode angewandt, wird auch die Änderung von T2 wiederholt. Dies führt dazu, dass im Undo Pass diese Änderung ohne Probleme wieder zurückgenommen werden kann. Auch eine Umkehrung der Reihenfolge von Redo und Undo Pass löst dieses Problem nicht. Hier werden zwar keine unnötigen Undos durchgeführt, dafür kann es passieren, dass im Redo Pass schon durchgeführte Änderungen nochmals angestoßen werden. Nachteil des Redo ALL ist der erhöhte Aufwand bei langen Transaktionen, die abgebrochen

14 KAPITEL 3. VORGEHEN VON ARIES 13 werden, also nicht committen. Vorteil ist das einfache Undo, da die Analysephase nicht so kompliziert wird. Bei Selective Redo dagegen muss viel mehr auf die Reihenfolge und die gegenseitigen Abhängigkeiten von Änderungen geachtet werden. 3.4 Erweiterte Problemstellungen ARIES stellt wenige Voraussetzungen an die konkrete Implementierung. So ist es möglich, verschiedene Logs zu führen: Ein Log für beide Passes (Redo/Undo log) oder für jeden eines (Redo-only, Undo-only logs). In diesem Zusammenhang gibt es auch verschiedene Strategien zur Speicherung von Änderungen; beim deferred update (verzögerte Änderung) werden Updates vom Buffer Manager in einer Warteschlange gehalten, bis sichergestellt ist, dass die zugehörige Transaktion committet. Dies impliziert, dass keine steal policy angewendet werden darf. Vorteil ist hier, dass keine Undos bei der Restart Recovery nötig sind, da alle nicht committeten Updates nicht persistent gespeichert wurden. Im Gegensatz dazu sind beim immediate update Undo-Vorgänge nötig, da hier alle Änderungen durch die steal policy gehandhabt werden. Ein Vorteil ist hier die bessere Lastverteilung auf dem Buffer Manager. In den vorausgegangenen Abschnitten wurde aus Gründen der Vereinfachung davon ausgegangen, dass für jede Operation nur ein Log Record benötigt wird. Dies ist in der Praxis meist nicht der Fall. Dennoch kann das vorgestellte Konzept relativ einfach an diese geänderten Gegebenheiten angepasst werden; ARIES gibt diese Einschränkung auch nicht. Beim Thema Effizienz soll noch einmal das Konzept der Unabhängigkeit aufgegriffen werden. Diese wird am einfachsten durch page-oriented redo sichergestellt, da in diesem Fall nur einzelne Seiten geändert werden. Bei logical redo kann davon nicht ausgegangen werden. Hier ist es also möglich, dass ein Redo Daten anderer Transaktionen verändert, was zu höhrem Aufwand führt. Analog wird logical undo dem seitenweisen Rückgängigmachen vorgezogen, um mehr Parallelität von Transaktionen zu erreichen. Ein effizientes Redo wird durch möglichst hohe Parallelität (mehrere gleichzeitige Vorgänge z.b. bei Multiprozessorsystemen) erreicht. Beim Undo sorgt eine hohe Concurrency (mehrere Transaktionen gleichzeitig) für diese Effizienz.

15 Kapitel 4 Zusammenfassung und Ausblick Abschließend sollen in diesem Kapitel die Hauptattribute und Vorteile von ARIES vorgestellt werden sowie eine Übersicht über reale Systeme, in denen die hier diskutierten Vorgehensweisen implementiert wurden. 4.1 Eigenschaften von ARIES Wir möchten hier eine kleine Auswahl der wichtigsten Attribute, die ARIES besitzt, vorstellen. Unterstützungverschiedener Granularitäten Sowohl das Setzen von Sperren als auch die Verwaltung gleichzeitig aktiver Transaktionen lassen sich auf mehreren Ebenen vornehmen. Flexibles Puffermanagement ARIES setzt keine bestimmte Strategie für die Speicherverwaltung für den Buffer Manager voraus. Dies ist der konkreten Implementierung vorbehalten. Beispiele sind die steal policy, bei der dirty pages schon vor dem Commit gespeichert werden können, oder die no-force policy, bei der umgekehrt nicht alle dirty pages gespeichert werden müssen, damit die Transaktion committen darf. Undo-Aktionen müssen nicht das exakte Gegenteil der ursprünglichen Operation sein Dies wird durch das Konzept der Compensation LogRecords (CLRs) sichergestellt, wie in Abschnitt 3 bereits beschrieben. Operation Logging wird unterstützt Protokolleinträge können auf logischer Ebene vorgenommen werden. Dies ermöglicht eine Einsparung beim Speicherplatzbedarf der Log Records, da nur die Änderungen und nicht komplette Vorher/Nachher- Abbilder (bzw. Information über den freien Speicher) einer Seite gespeichert werden müssen. 14

16 KAPITEL 4. ZUSAMMENFASSUNG UND AUSBLICK 15 Mehrere Transaktionen können gleichzeitig auf Seiten zugreifen Bis auf die kurze Zeitspanne während einer Latch-Sperre, in der auf Seiten physikalisch zugegriffen wird, können Transaktionen zeitgleich auf den Seiten arbeiten. Keine Sperren während der Rollback-Phase Da bei der Restart Recovery das Transaktionssystem noch nicht wieder gestartet wurde, können Änderungen rückgängig gemacht werden, ohne Sperren setzen zu müssen. Dies führt dazu, dass auch keine Deadlocks entstehen können. Diese können auch beim Rollback im Normal Processing nicht auftreten, da alle Sperren für Undos bereits von der ursprünglichen Operation gesetzt wurden. CLRs brauchen nur Redo-Information Da Änderungen durch CLRs nicht rückgängig gemacht werden, muss diese Information auch nicht gespeichert werden. LSN-Konzept Mithilfe der LogSequence Numbers (LSN) können Transaktionsabläufe exakt wiederholt werden (RepeatingHistory). Dies erlaubt Sperren auf Record-Ebene und effektives Speichermanagement. CLRs werden verkettet Mittels des UndoNextLSN-Felds kann von einem Record zum nächsten gesprungen werden, ohne CLRs rückgängig machen zu müssen. 4.2 Implementierungen von ARIES Wie erwähnt, stellt ARIES nur theoretische Voraussetzungen vor. Im Folgenden sollen einige Systeme aufgelistet werden, bei denen die hier vorgestellten Konzepte ganz oder teilweise implementiert wurden: Starburst/Quicksilver, IBM EXODUS/Gamma, Universität Wisconsin OS/2 Extended Edition Database Manager, IBM Workstation Data Save Facility, IBM DB2 Version 2, IBM ( RepeatingHistory) SQL Server, Microsoft Windows NT File System (NTFS), Microsoft Lotus Domino, IBM Eine ausführlichere Liste ist unter [impact] zu finden.

17 Literaturverzeichnis [TODS] C. Mohan, Donald J. Haderle, Bruce G. Lindsay, Hamid Pirahesh, Peter Schwarz: ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging. TODS 17(1): (1992) [impact] C. Mohan, Impact of ARIES Family of Locking and Recovery Algorithms Impact.html [ACM] Association for Computing Machinery [SIGMOD] SIGMOD Innovation Award 16