Oracle Database · · 3 Min.

Guaranteed Restore Points: Schutz mit Ablaufplan

Vor einem Upgrade schnell zurückspringen können – ohne dabei die Fast Recovery Area unbemerkt volllaufen zu lassen.

Veröffentlicht am 24.10.2026 · Verfasst von Veysi Guenay

Vor einem Datenbank-Upgrade oder einer riskanten Änderung ist ein Guaranteed Restore Point (GRP) ein nützlicher Sicherheitsanker. Er markiert einen SCN, zu dem sich die Datenbank mit FLASHBACK DATABASE zurücksetzen lässt. Anders als ein normales Restore Point läuft ein GRP nicht automatisch ab: Oracle hält die dafür erforderlichen Flashback-Logs zurück, bis der Restore Point explizit gelöscht wird.

Der operative Trade-off: Die Rückkehr zu einem bekannten Zustand wird verlässlicher – gleichzeitig können geschützte Logs Speicher im Fast Recovery Area (FRA) binden. Ist dort kein Platz mehr verfügbar, kann das den Datenbankbetrieb beeinträchtigen.

Vor dem Change einen eindeutigen Marker setzen

Ein CDB-weiter Restore Point wird im Root erstellt. In einem Wartungsplan gehören Name, Change-ID, Erstellzeitpunkt, erwartete Laufzeit und verantwortliche Person zusammen:

CREATE RESTORE POINT before_release_20261024
  GUARANTEE FLASHBACK DATABASE;

In Multitenant-Umgebungen gibt es zusätzlich PDB-Restore-Points. Ein garantierter PDB-Restore-Point kann jedoch Logs festhalten, die für die CDB benötigt werden. Auch wenn nur eine PDB geschützt werden soll, muss der DBA daher die FRA-Auswirkung auf den gesamten Container im Blick behalten.

Platzbedarf sichtbar machen

Der tatsächliche Log-Bedarf hängt stark von Änderungsrate und Dauer des Changes ab. Ein kurzer Testlauf mit wenig Schreiblast ist deshalb keine verlässliche Hochrechnung für einen produktiven Batch. Prüfen Sie vorab vorhandenen FRA-Spielraum und überwachen Sie ihn während des Wartungsfensters. Die View V$RESTORE_POINT zeigt unter anderem garantierte Restore Points und deren ungefähren gebundenen Speicher:

SELECT name,
       guarantee_flashback_database,
       storage_size
FROM   v$restore_point
ORDER BY time;

STORAGE_SIZE ist eine Näherung für den Speicher der Logs, die zur Garantie benötigt werden. Ergänzen Sie diese Sicht um Ihre bestehende FRA-Überwachung und Alarmierung; besonders wichtig sind freier Speicher, Spitzenlast und eine realistische Obergrenze für die Change-Dauer.

Nach erfolgreichem Change bewusst aufräumen

Ist die fachliche und technische Abnahme abgeschlossen und der Rücksprung nicht mehr erforderlich, wird der GRP explizit entfernt:

DROP RESTORE POINT before_release_20261024;

Danach können Logs, die nur für diesen GRP aufbewahrt wurden, wieder nach den FRA-Regeln freigegeben werden. Löschen Sie den Marker nicht allein aufgrund eines erfolgreichen Skriptendes: Prüfen Sie auch Anwendung, Schnittstellen, Backup-Status und Change-Freigabe. Umgekehrt sollte der Restore Point nicht aus Bequemlichkeit über Wochen bestehen bleiben. Solange erforderliche Logs geschützt sind, kann Platzdruck dazu führen, dass keine Dateien mehr reclaimable sind.

Kurze Runbook-Checkliste

  1. Vor dem Change Voraussetzungen, Rollback-Entscheidung und Rücksprungverantwortung festhalten.
  2. FRA-Füllstand, freie Kapazität und jüngste Änderungsrate vor dem GRP bewerten.
  3. Restore Point mit eindeutigem Namen anlegen und in V$RESTORE_POINT verifizieren.
  4. Während des Wartungsfensters FRA-Werte alarmieren und Laufzeitgrenzen überwachen.
  5. Nach erfolgreicher Abnahme den GRP entfernen und kontrollieren, dass sich der FRA-Spielraum erholt.

Fazit

Ein Guaranteed Restore Point ist eine gezielte Rückfalloption, kein kostenloser Ersatz für Backup und Recovery. Sein Nutzen hängt davon ab, dass der Speicherbedarf geplant, die FRA überwacht und ein klares Ablaufdatum im Change-Runbook verankert ist. So bleibt der schnelle Rücksprung verfügbar, ohne dass ein vergessener Marker zum Betriebsrisiko wird.

Weiterführend: Oracles Anleitung zu Flashback Database und Restore Points, die SQL-Referenz für CREATE RESTORE POINT und die Oracle Flashback Best Practices.