Zusammenfassung
Eine eminent wichtige Aufgabe von DBS liegt in der Gewährleistung einer weitgehenden Datensicherung. Trotz Auftretens von Fehlern verschiedener Art ist die Konsistenz der Datenbank automatisch zu wahren und Datenverlust zu verhindern. Die Fehlerbehandlung ist Aufgabe der Recovery-Komponente des DBS. Sie benötigt neben den Datenbankinhalten redundante Informationen, welche durch ein Logging im Normalbetrieb zu protokollieren sind. Die notwendigen Recovery-Aufgaben sind weitgehend durch das Transaktionskonzept (vor allem die Eigenschaften A und D, siehe Abschnitt 13.1) bestimmt. Insbesondere sind aufgrund der Dauerhaftigkeitszusicherung Änderungen erfolgreich beendeter Transaktionen gegenüber allen erwarteten Fehlerarten zu bewahren. Weiterhin verlangt die Alles-oder-Nichts-Eigenschaft das Zurücksetzen von Änderungen für Transaktionen, welche aufgrund eines Fehlers ihr Commit nicht abschließen konnten.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Notes
Bei dieser Pufferung kann noch ausgenutzt werden, daß bei mehrfachen Änderungen einer Seite pro Transaktion als Undo-Information nur das älteste Before-Image, für die Redo-Recovery nur das jüngste After-Image zu sichern ist.
Dies trifft genau genommen nur für die Redo-Recovery zu. Eine logische Undo-Recovery ist möglich, wenn zunächst durch die (physische) Redo-Recovery eine aktionskonsistente Datenbank erzeugt wird. Dies ist u. a. der Fall beim ARIES-Konzept, wo sämtliche Änderungen (auch von gescheiterten Transaktionen) beim Redo wiederholt werden (Abschnitt 15.6).
Derartige Seitenoperationen stellen nach [GRAY93] „Mini-Transaktionen“ dar und führen zu einer speziellen Realisierung von geschachtelten bzw. Mehrebenen-Transaktionen (Abschnitt 16.5).
Wir betrachten hier nur Sperrverfahren zur Synchronisation.
In der praktischen Realisierung sind wenigstens zwei Log-Puffer vorzusehen, um während des Ausschreibens eines Puffers anfallende Log-Daten im zweiten Log-Puffer ablegen zu können [UNTE90].
Bei sortiert-wahlfreier Ausgabe wird der Zugriffsarm nur in einer Richtung bewegt, so daß zwischen den einzelnen Schreibvorgängen keine oder nur sehr kurze Zugriffsarmbewegungen anfallen. Wir schätzen deshalb die Dauer eines Schreibvorgangs mit 4-6 ms ab.
Dies kann erreicht werden, indem zur Durchführung des Sicherungspunktes eine Lesesperre auf der gesamten Datenbank angefordert wird. Dabei muß jedoch darauf geachtet werden, daß laufende Änderungstransaktionen bei neuen Sperranforderungen nicht blockiert werden.
Zudem können noch gewisse Optimierungen zur Reduzierung des Redo-Log-Umfangs vorgenommen werden; z. B. ist nur Redo-Information von erfolgreichen Transaktionen in den Archiv-Log zu schreiben usw.
MinTxLSN entspricht der sog. Commit-LSN aus [MOHA90], siehe Abschnitt 14.5.
Aufgrund der Analyse-Phase können die für das Redo relevanten Seiten auch bereits vor der Redo-Phase gebündelt eingelesen werden. Dies erlaubt die Reduzierung von Zugriffsarmbewegungen (sortiert-wahlfreie Eingabe, Abschnitt 2.4.3) bzw. Nutzung von E/A-Parallelität.
Bei byte-orientiertem Zustands-Logging kann dagegen ein After-Image mehrfach angewandt werden, da das wiederholte Überschreiben eines bestimmten Byte-Bereiches mit demselben Wert keinen Schaden anrichtet.
Dies entspricht der Vorgehensweise beim Undo zur Behandlung von Transaktionsfehlern. Im Normalbetrieb liegen stets die aktuellsten Versionen der DB-Seiten mit allen Änderungen beendeter und laufender Transaktionen vor. Zum Undo sind somit alle Änderungen der betroffenen Transaktion (ohne Beachtung von LSN-Werten) in umgekehrter Reihenfolge zurückzunehmen.
Falls nicht alle Rechner befragt werden sollen, setzt dies voraus, daß der Koordinator z. B. mit der PREPARE-Nachricht mitteilt, welche Agenten noch an der Transaktion beteiligt sind.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2001 Springer-Verlag Berlin Heidelberg
About this chapter
Cite this chapter
Härder, T., Rahm, E. (2001). Logging und Recovery. In: Datenbanksysteme. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-56419-2_15
Download citation
DOI: https://doi.org/10.1007/978-3-642-56419-2_15
Publisher Name: Springer, Berlin, Heidelberg
Print ISBN: 978-3-642-62659-3
Online ISBN: 978-3-642-56419-2
eBook Packages: Springer Book Archive