Recovery
Zwei der während des Recovery-Prozesses potentiell durchgeführten Tätigkeiten sind:
• Undo - einige Schreibaktionen werden rückgängig gemacht, d.h. Datenobjekte bekommen den alten Wert zugewiesen, der vor der Schreibaktion galt;
• Redo - einige Schreibaktionen müssen wiederholt werden, da nicht klar ist, ob sie tatsächlich ausgeführt wurden.
Wenn der Recovery-Prozeß angestoßen wird, werden zunächst alle Schreibaktionen rückgängig gemacht, die von nicht committeten Transaktionen gemacht wurden. Dabei wird das Log in Richtung Vergangenheit bearbeitet. Dann werden alle Schreibaktionen wiederholt, die von committeten Transaktionen durchgeführt wurden. Jetzt wird das Log von seinem Anfang in Richtung Zukunft bearbeitet.
Nicht bei allen Update-Strategien sind sowohl Undo als auch Redo erforderlich.
Man unterscheidet deferred update, bei dem die Schreibaktionen zunächst nur im Datenbank-Log vermerkt werden und erst im Rahmen des commit-Vorgangs in den eigentlichen Datenbestand aufgenommen werden. Es ist also kein Undo nötigt, man spricht deshalb von no Undo/Redo.
Eine zweite Möglichkeit ist immediate update, bei dem Schreibaktionen direkt auf den Datenbestand wirken. In diesem Fall muß der vor der Schreibaktion vorhandene Wert des Datenobjekts im Datenbank-Log gesichert werden. Hier ist kein Redo nötig, also Undo/no Redo.
Das Datenbank-Log (oder Journal) vermerkt chronologisch alle Aktionen, die von den Transaktionen ausgeführt werden. Im allgemeinsten Fall werden folgende Typen von Log-Einträgen geschrieben:
• [BeginTransaction T], wenn die Transaktion T startet;
• [Read, X, T], wenn die Transaktion T das Datenobjekt X liest;
• [Write, X, T, Vbefore, Vafter], wenn die Transaktion T den Wert des Datenobjekts X von Vbefore (before image) auf Vafter (after image) ändert;
• [Commit T], wenn die Transaktion T den commit-Zustand erreicht;
• [Abort T], wenn die Transaktion T abgebrochen wird;
• [Checkpoint], wenn ein Checkpoint durchgeführt wurde.
Für die Verwaltung des Datenbank-Logs gelten zwei wichtige Grundsätze. Das write-ahead-logging Protokoll stellt sicher, daß das before image eines Datenobjekts ins Datenbank-Log gerettet wird, bevor das Datenobjekt von einer nicht committeten Transaktion überschrieben wird (Undo-Regel). Bei deferred update wird diese Regel automatisch eingehalten, da alle Schreibaktionen bis zum commit verzögert werden.
Die Commit-Regel bzw. Redo-Regel besagt, daß bevor eine Transaktion den commit-Zustand erreichen darf, alle Write-Aktionen entweder im Log vermerkt wurden (bei deferred update) oder zu Änderungen der Datenbank geführt haben (bei immediate update).
Die [Read, ...]-Einträge im Log sind notwendig, wenn das verwendete Concurreny Control Protokoll kaskadierende Rollbacks nicht vermeidet. Dann kann anhand des Logs im Nachhinein bestimmt werden, welche Transaktion von welchen anderen Transaktionen gelesen hat.
Ein [Checkpoint]-Eintrag im Log bedeutet, dass die Schreibaktionen aller vor dem Checkpoint committeten Transaktionen tatsächlich in der Datenbank durchgeführt wurden. Checkpoints sind zusammen mit immediate update nicht sinnvoll, da dann schon beim commit einer Transaktion alle Schreibaktionen durchgeführt wurden.
• Undo - einige Schreibaktionen werden rückgängig gemacht, d.h. Datenobjekte bekommen den alten Wert zugewiesen, der vor der Schreibaktion galt;
• Redo - einige Schreibaktionen müssen wiederholt werden, da nicht klar ist, ob sie tatsächlich ausgeführt wurden.
Wenn der Recovery-Prozeß angestoßen wird, werden zunächst alle Schreibaktionen rückgängig gemacht, die von nicht committeten Transaktionen gemacht wurden. Dabei wird das Log in Richtung Vergangenheit bearbeitet. Dann werden alle Schreibaktionen wiederholt, die von committeten Transaktionen durchgeführt wurden. Jetzt wird das Log von seinem Anfang in Richtung Zukunft bearbeitet.
Nicht bei allen Update-Strategien sind sowohl Undo als auch Redo erforderlich.
Man unterscheidet deferred update, bei dem die Schreibaktionen zunächst nur im Datenbank-Log vermerkt werden und erst im Rahmen des commit-Vorgangs in den eigentlichen Datenbestand aufgenommen werden. Es ist also kein Undo nötigt, man spricht deshalb von no Undo/Redo.
Eine zweite Möglichkeit ist immediate update, bei dem Schreibaktionen direkt auf den Datenbestand wirken. In diesem Fall muß der vor der Schreibaktion vorhandene Wert des Datenobjekts im Datenbank-Log gesichert werden. Hier ist kein Redo nötig, also Undo/no Redo.
Das Datenbank-Log (oder Journal) vermerkt chronologisch alle Aktionen, die von den Transaktionen ausgeführt werden. Im allgemeinsten Fall werden folgende Typen von Log-Einträgen geschrieben:
• [BeginTransaction T], wenn die Transaktion T startet;
• [Read, X, T], wenn die Transaktion T das Datenobjekt X liest;
• [Write, X, T, Vbefore, Vafter], wenn die Transaktion T den Wert des Datenobjekts X von Vbefore (before image) auf Vafter (after image) ändert;
• [Commit T], wenn die Transaktion T den commit-Zustand erreicht;
• [Abort T], wenn die Transaktion T abgebrochen wird;
• [Checkpoint], wenn ein Checkpoint durchgeführt wurde.
Für die Verwaltung des Datenbank-Logs gelten zwei wichtige Grundsätze. Das write-ahead-logging Protokoll stellt sicher, daß das before image eines Datenobjekts ins Datenbank-Log gerettet wird, bevor das Datenobjekt von einer nicht committeten Transaktion überschrieben wird (Undo-Regel). Bei deferred update wird diese Regel automatisch eingehalten, da alle Schreibaktionen bis zum commit verzögert werden.
Die Commit-Regel bzw. Redo-Regel besagt, daß bevor eine Transaktion den commit-Zustand erreichen darf, alle Write-Aktionen entweder im Log vermerkt wurden (bei deferred update) oder zu Änderungen der Datenbank geführt haben (bei immediate update).
Die [Read, ...]-Einträge im Log sind notwendig, wenn das verwendete Concurreny Control Protokoll kaskadierende Rollbacks nicht vermeidet. Dann kann anhand des Logs im Nachhinein bestimmt werden, welche Transaktion von welchen anderen Transaktionen gelesen hat.
Ein [Checkpoint]-Eintrag im Log bedeutet, dass die Schreibaktionen aller vor dem Checkpoint committeten Transaktionen tatsächlich in der Datenbank durchgeführt wurden. Checkpoints sind zusammen mit immediate update nicht sinnvoll, da dann schon beim commit einer Transaktion alle Schreibaktionen durchgeführt wurden.