Savepoint
Einsatzmöglichkeiten
Das Datenbanksystem führt im Betriebszustand ONLINE und während eines Restarts automatisch Savepoints (Sicherungspunkte) durch. Bei einem Savepoint schreibt das Datenbanksystem alle Datenänderungen seit dem letzten Savepoint aus dem Data-Cache (Arbeitsspeicher) in den Datenbereich (permanenter Speicher).
Die Daten, die mit einem Savepoint in den Datenbereich geschrieben werden, repräsentieren immer einen konsistenten Zustand der Datenbank. Sie können die Datenbankinstanz immer, beispielsweise auch nach einem Stromausfall, in einem konsistenten Zustand starten, ohne dass Sie hierfür Log-Sicherungen einlesen müssen.
Wohin schreibt das Datenbanksystem die Datenänderungen?
Beim Savepoint überschreibt das Datenbanksystem nicht die beim vorherigen Savepoint geschriebenen Seiten im Datenbereich, sondern es schreibt die geänderten Daten auf neue freie Positionen. Der Grund hierfür ist, dass das Datenbanksystem diese Informationen des vorherigen Savepoints für den Restart benötigt, falls es während des neuen Savepoints zu einem Systemausfall kommt.
Erst nachdem das Datenbanksystem den neuen Savepoint erfolgreich abgeschlossen hat, gibt es die Seiten des vorherigen Savepoints im Datenbereich wieder zum Überschreiben frei.
Wann führt das Datenbanksystem Savepoints durch?
Das Datenbanksystem führt Savepoints in folgenden Situationen durch:
● Seit dem letzten Savepoint hat das Datenbanksystem 2/3 des Log-Bereichs mit Redo-Log-Einträgen gefüllt.
● Das Datenbanksystem hat 5000 Log-I/O-Operationen durchgeführt, und es ist seit dem letzten Savepoint mindestens die Zeit vergangen, die mit dem Support-Datenbankparameter _RESTART_TIME festgelegt ist.
Wenn Sie den Wert von _RESTART_TIME vergrößern, verringert sich zwar die Anzahl der Savepoints und damit die Systemlast, aber nach einem Systemausfall verlängert sich die für den Restart benötigte Zeitspanne.
● Verschiedene Datenbankaktivitäten, wie beispielsweise das Starten einer Datensicherung, fordern implizit einen Savepoint an. Alle Savepoints und die Aktionen, die durch sie ausgelöst wurden, protokolliert das Datenbanksystem im Kernprotokoll.
Ablauf
Der Savepoint wird vom Datenbanksystem über eine Server-Task (Savepoint Coordinator) gesteuert. Er läuft folgendermaßen ab:
...
1. Das System schreibt alle geänderten permanenten Datenseiten aus dem Data-Cache in den Datenbereich.
2. Das System wartet auf das Ende alle Operationen, die sich mit dem Savepoint synchronisieren müssen, beispielsweise das Einfügen eines Datensatzes in einen B*-Baum. Neue Operationen dieser Art lässt das Datenbanksystem nicht mehr zu.
3. Das System lässt kein Starten oder Beenden von Transaktionen mehr zu.
4. Bei einem Savepoint während des normalen Datenbankbetriebs:
Das System schreibt einen Redo-Log-Eintrag. Dieser markiert, ab wann das System noch Log-Einträge einlesen muss, wenn später ein Restart mit den Daten dieses Savepoint durchgeführt werden muss.
Bei einem Savepoint während eines Restarts:
Das System ermittelt die aktuelle Position des Log-Lesers und trägt diese in die Restart-Information ein.
5. Das System speichert Informationen über die offenen Transaktionen in Datenseiten, damit diese bei einem Restart für das Wiederholen oder Rückgängigmachen der Transaktionen zur Verfügung stehen.
6. Das System liest die History-Informationen in den Data-Cache ein.
7. Das System markiert alle seit Schritt 1 geänderten permanenten Datenseiten im Data-Cache.
8. Das System lässt alle in den Schritten 2 und 3 aufgeführten Operationen wieder zu.
Alle Änderungen, die Datenbankbenutzer ab diesem Zeitpunkt durchführen, haben keinen Einfluss mehr auf die im Schritt 7 markierten Daten. Diese Änderungen kann das System frühestens nach dem Ende des aktuellen Savepoint in den Datenbereich schreiben.
9. Das System schreibt die in Schritt 7 markierten Datenseiten in den Datenbereich. Neben den Änderungen, die bereits mit einem COMMIT abgeschlossen wurden, gehören hierzu auch die Undo-Log-Dateien nicht abgeschlossener Transaktionen, die das System im Falle eines Restarts benötigt.
10. Das System schreibt alle geänderten Seiten des internen Dateiverzeichnisses in den Datenbereich.
11. Das System schreibt alle geänderten Converter-Seiten in den Datenbereich.
12. Das System aktualisiert die Restart-Information, die unter anderem die Savepoint-Version (=Converter-Version) enthält.
Der eigentliche Savepoint ist damit abgeschlossen.
13. Nun gibt das System alle Seiten im Datenbereich, die nicht mehr benötigt werden, zum Überschreiben frei.
14. Das System weckt diejenigen Tasks auf, die den Savepoint angefordert oder auf einen Savepoint gewartet haben.
Wenn der Savepoint wegen des Übergangs in den Betriebszustand OFFLINE ausgelöst wurde, dann stoppt das System nun den Datenbankkern.
Siehe auch:
Volumes (permanenter Speicher)
Database Manager
CLI,
db_restartinfo