Kapitel 2 ¨Uberblick ARIES

Hauptseminar Database Hall of Fame“
”
C. Mohan
Recovery und Transaktionen
Christopher Lewis
11. Dezember 2001
Inhaltsverzeichnis
1 Einleitung
1.1 Zur Person . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
2
2 Überblick ARIES
2.1 Buffer Management . . . . . .
2.2 Write Ahead Logging (WAL)
2.2.1 Datenstrukturen . . .
2.2.2 Logical Logging . . . .
2.2.3 Page-oriented Logging
2.3 Ziele . . . . . . . . . . . . . .
.
.
.
.
.
.
4
4
5
5
6
6
6
.
.
.
.
8
8
10
11
13
4 Zusammenfassung und Ausblick
4.1 Eigenschaften von ARIES . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Implementierungen von ARIES . . . . . . . . . . . . . . . . . . . . . . . .
14
14
15
3 Vorgehen von ARIES
3.1 Normal Processing . . . . . .
3.2 Restart Recovery . . . . . . .
3.3 Ein komplexeres Beispiel . . .
3.4 Erweiterte Problemstellungen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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 SIGMOD Innovations Award [SIGMOD] der Association for Computing Machinery [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
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) zu gewä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.
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 FixAttribut 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 UndoVorgä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
KAPITEL 2. ÜBERBLICK ARIES
2.2
5
Write Ahead Logging (WAL)
WAL bedeutet, dass alle Änderungen (Updates) auf dem Hintergrundspeicher vor ihrer
Durchführung in einem Log protokolliert werden; solche Log Records 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 WALProtokoll 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.
2.2.1
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 log sequence 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.
KAPITEL 2. ÜBERBLICK ARIES
2.2.2
6
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.
2.2.3
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
KAPITEL 2. ÜBERBLICK ARIES
7
in Abschnitt 2.2.3 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 2.2.3 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.
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 log records (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
KAPITEL 3. VORGEHEN VON ARIES
9
2
1
1
SP
2
3
2‘
3‘
2
3
3‘
T
2‘
2
T
Gespeicherte Änderung
Nicht gespeicherte Änderung
SP Savepoint
Transaktionsfehler
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.
KAPITEL 3. VORGEHEN VON ARIES
1
T
UndoNextLSN
1‘
10
1
T
1‘
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
KAPITEL 3. VORGEHEN VON ARIES
1
11
2
3
S
S
Systemfehler
Redo:
2
Undo:
3‘
3
2‘
1‘
Abbildung 3.3: Restart Processing
Fall, wenn nicht alle Updates wiederholt werden, also kein Repeating History 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 Repeating History 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
CT
LSN: 10
LSN der Seite:
20
30
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
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
LSN:
30
LSN der Seite:
T1c
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
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.
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ützung verschiedener 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 Log Records (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
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 Log Sequence Numbers (LSN) können Transaktionsabläufe exakt wiederholt werden (Repeating History). 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 (→ Repeating History)
• SQL Server, Microsoft
• Windows NT File System (NTFS), Microsoft
• Lotus Domino, IBM
Eine ausführlichere Liste ist unter [impact] zu finden.
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): 94-162 (1992)
[impact] C. Mohan, Impact of ARIES Family of Locking and Recovery Algorithms
http://www.almaden.ibm.com/u/mohan/ARIES Impact.html
[ACM] Association for Computing Machinery
http://www.acm.org
[SIGMOD] SIGMOD Innovation Award
http://www.acm.org/sigmod/sigmodinfo/awards.html
16