Die Datenbank kontrolliert auf einen Zeitpunkt zurückdrehen
Ein falsches Massenupdate um 9:41 Uhr lässt sich zurücknehmen, wenn Sicherung und Archive-Logs zusammenpassen und du den Zeitpunkt begründen kannst, statt ihn zu schätzen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der teuerste Teil ist nicht das Zurückspielen
Der Auslöser ist selten ein defektes Laufwerk. Viel häufiger hat ein Update ohne WHERE-Bedingung 400.000 Zeilen überschrieben, ein Importlauf ist zweimal gestartet worden oder ein Entwicklungsskript ist versehentlich gegen die Produktion gelaufen. Der Schaden ist logisch, die Datenbank selbst läuft einwandfrei weiter und schreibt fleißig neue, korrekte Daten dazu.
Daraus entsteht der eigentliche Konflikt. Ein Rückdrehen der ganzen Instanz auf 9:40 Uhr entfernt den Fehler zuverlässig, wirft aber auch alles weg, was seitdem an richtigen Daten dazugekommen ist. Wer diese Abwägung erst im Moment der Panik trifft, entscheidet meist zu grob und dreht mehr zurück als nötig.
Deshalb steht die Frage nach dem Umfang vor der Frage nach dem Befehl. Für eine einzelne Tabelle gibt es RECOVER TABLE, für einen fachlich abgeschlossenen Bereich die Wiederherstellung auf Tablespace-Ebene, und für beschädigte übergreifende Strukturen die ganze Datenbank. Alle drei Wege benutzen dieselbe Mechanik, sie unterscheiden sich nur im Preis.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Schritt für Schritt
- 1
Den Schaden eingrenzen und die Uhr anhalten
Bevor irgendetwas zurückgespielt wird, stoppst du die Prozesse, die den Fehler wiederholen könnten, also den fehlerhaften Job, den Importlauf oder den betroffenen Anwendungsteil. Notier dabei, ab wann falsche Daten geschrieben wurden und ob seitdem korrekte Buchungen dazugekommen sind.
Geschafft, wenn: der Schaden wächst nicht weiter und der betroffene Zeitraum ist grob eingegrenzt
- 2
Den Zeitpunkt bestimmen
Mit einer Flashback-Abfrage über AS OF TIMESTAMP prüfst du den Inhalt der betroffenen Tabelle zu verschiedenen Uhrzeiten und findest so den letzten sauberen Stand. Reicht der Undo nicht mehr weit genug zurück, hilft V$LOG_HISTORY beim Zuordnen von Uhrzeit und Log-Sequenz. Notier den Wert als SCN, damit Zeitzonen und Datumsformate keine Rolle mehr spielen.
Geschafft, wenn: eine SCN oder Uhrzeit steht fest, die sich gegenüber der Fachabteilung begründen lässt
- 3
Den Umfang festlegen
Betrifft der Schaden einzelne Tabellen, ist RECOVER TABLE der schonendste Weg, weil die Datenbank offen bleibt. Betrifft er einen fachlich abgeschlossenen Tablespace ohne Verflechtungen nach außen, kommt die Wiederherstellung auf Tablespace-Ebene infrage; SYSTEM, SYSAUX und der Undo-Tablespace sind davon ausgenommen. Erst wenn übergreifende Strukturen beschädigt sind, dreht die ganze Instanz zurück.
Geschafft, wenn: die Entscheidung ist begründet und nicht aus Zeitdruck getroffen
- 4
Sicherung und Archive-Logs prüfen
LIST BACKUP SUMMARY zeigt, welche Sicherungen es gibt, CROSSCHECK gleicht den Katalog mit der Realität auf dem Datenträger ab. RESTORE DATABASE UNTIL SCN ... PREVIEW listet anschließend die benötigten Stücke auf, ohne etwas zu schreiben. Fehlt ein Archive-Log in der Kette, endet die Wiederherstellung genau dort, und das willst du vorher wissen.
Geschafft, wenn: RMAN meldet eine lückenlose Kette bis zum gewählten Zeitpunkt
- 5
Wenn möglich zuerst auf einer Kopie proben
DUPLICATE DATABASE ... UNTIL SCN baut auf einem zweiten Rechner eine Kopie zum gewünschten Zeitpunkt, ohne die Produktion anzufassen. Bei rein logischen Schäden ist das oft schon die Lösung: Du exportierst die fehlenden Zeilen aus der Kopie und spielst sie zurück, während die Produktion die ganze Zeit online bleibt.
Geschafft, wenn: die Daten des gewünschten Zeitpunkts liegen vor, ohne dass jemand Arbeit verloren hat
- 6
Restore und Recover ausführen
Muss die Instanz doch zurück, fährst du sie herunter und startest sie mit STARTUP MOUNT. Dann laufen RESTORE DATABASE UNTIL SCN und anschließend RECOVER DATABASE UNTIL SCN. Der Restore holt die Datendateien aus der Sicherung, der Recover fährt die Archive-Logs bis zur angegebenen Marke nach und hält dort an.
Geschafft, wenn: RMAN meldet media recovery complete und die Datenbank steht noch in MOUNT
- 7
Öffnen, prüfen, neu sichern
ALTER DATABASE OPEN RESETLOGS öffnet die Datenbank und beginnt eine neue Inkarnation. Lass die Anwendung zunächst draußen, prüf mit der Fachabteilung an konkreten Datensätzen, ob der Stand stimmt, und starte erst danach eine vollständige Sicherung. Ohne sie hättest du für den nächsten Zwischenfall nur noch Sicherungen aus der alten Inkarnation.
Geschafft, wenn: die Anwendung arbeitet auf einem geprüften Stand und eine frische Vollsicherung liegt vor
Fünf Bedingungen, ohne die es nicht funktioniert
- 01 Die Datenbank läuft im Archivelog-Modus, sonst gibt es keinen Zeitpunkt.
- 02 Eine Sicherung liegt vor dem gewünschten Zeitpunkt und ist lesbar.
- 03 Alle Archive-Logs von der Sicherung bis zum Zeitpunkt sind vorhanden.
- 04 Der Zeitpunkt ist belegt und nicht geraten, am besten als SCN.
- 05 Nach OPEN RESETLOGS folgt sofort eine neue vollständige Sicherung.
Was du nach dieser Seite entscheiden und ausführen kannst
Der Ablauf unten setzt eine Datenbank im Archivelog-Modus und eine gültige RMAN-Sicherung voraus, die vor dem gewünschten Zeitpunkt liegt. Ohne Archive-Logs zwischen Sicherung und Zeitpunkt gibt es keine zeitpunktgenaue Wiederherstellung, dann bleibt nur der Stand der Sicherung selbst.
Den Zeitpunkt belegen statt schätzen
Eine Flashback-Abfrage mit AS OF TIMESTAMP zeigt dir den Inhalt einer Tabelle zu einer gewählten Uhrzeit, solange der Undo weit genug zurückreicht. Damit tastest du dich an den letzten unbeschädigten Stand heran, bevor irgendetwas zurückgespielt wird.
Den kleinstmöglichen Umfang wählen
RECOVER TABLE holt einzelne Tabellen über eine Hilfsinstanz zurück und legt sie auf Wunsch unter neuem Namen ab. Die laufende Datenbank bleibt dabei offen, und niemand verliert die Buchungen der letzten zwei Stunden.
Vorher wissen, ob es klappt
RESTORE DATABASE UNTIL TIME ... PREVIEW listet auf, welche Sicherungsstücke und Archive-Logs RMAN benötigt, ohne eine einzige Datei anzufassen. VALIDATE prüft zusätzlich, ob diese Stücke lesbar sind.
Die Zeitangabe eindeutig schreiben
UNTIL TIME hängt am Datumsformat der Sitzung. Schreib den Zeitpunkt als TO_DATE mit ausgeschriebener Maske oder arbeite gleich mit UNTIL SCN, dann spielen Umgebungsvariablen und Sommerzeit keine Rolle mehr.
Den Zugriff während der Aktion sperren
Zwischen MOUNT und dem geöffneten Zustand darf keine Anwendung verbinden, sonst schreibt ein Batchlauf in eine Datenbank, die gerade zurückgedreht wird. Ein Start im eingeschränkten Modus gibt dir danach Zeit für die fachliche Prüfung.
Das Ende sauber gestalten
Nach unvollständiger Wiederherstellung öffnet die Datenbank nur mit RESETLOGS und beginnt eine neue Inkarnation. Eine vollständige Sicherung direkt danach ist keine Formsache, sondern die Bedingung dafür, dass du beim nächsten Zwischenfall wieder vorwärtskommst.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Zeitpunkt, SCN oder Log-Sequenz
RMAN kennt drei Arten, das Ende der Wiederherstellung anzugeben. UNTIL TIME ist die lesbarste und zugleich anfälligste, weil die Zeichenkette über das Datumsformat der Sitzung interpretiert wird und weil eine Uhrzeit in der Nacht der Zeitumstellung zweimal vorkommt. Schreib deshalb TO_DATE('16.08.2026 09:40:00','DD.MM.YYYY HH24:MI:SS') aus, statt dich auf NLS_DATE_FORMAT zu verlassen.
UNTIL SCN ist eindeutig und die bessere Wahl, sobald der Zeitpunkt fachlich wichtig ist. Die passende SCN bekommst du über TIMESTAMP_TO_SCN, über V$LOG_HISTORY oder aus dem ORA_ROWSCN der letzten unbeschädigten Zeilen. UNTIL SEQUENCE brauchst du vor allem dann, wenn ein Archive-Log fehlt und du bewusst kurz davor anhältst.
Ein Detail, das im Ernstfall Zeit kostet: Der Recover hält vor der angegebenen Marke an, das UNTIL ist also ausschließend gemeint. Wähl den Zeitpunkt großzügig eine Minute vor dem Schaden und nicht auf die Sekunde genau, sonst spielst du die schädliche Anweisung mit ein.
Wann eine einzelne Tabelle reicht
Seit Oracle 12c beherrscht RMAN den Befehl RECOVER TABLE. Im Hintergrund passiert deutlich mehr, als der kurze Befehl vermuten lässt: RMAN baut eine Hilfsinstanz auf, stellt dort SYSTEM, SYSAUX, Undo und den betroffenen Tablespace zum gewünschten Zeitpunkt wieder her, exportiert die Tabelle und importiert sie in die laufende Datenbank. Du brauchst dafür freien Plattenplatz in der Größenordnung dieser Tablespaces und ein Verzeichnis, das du über AUXILIARY DESTINATION angibst.
Mit REMAP TABLE landet die wiederhergestellte Tabelle unter einem anderen Namen. Das ist fast immer die bessere Variante, weil du dann in Ruhe vergleichen kannst, welche Zeilen fehlen, statt die produktive Tabelle blind zu ersetzen. Fremdschlüssel und abhängige Objekte kommen nicht automatisch mit, das gehört in die Nachbereitung.
Die Wiederherstellung auf Tablespace-Ebene folgt derselben Idee für größere Einheiten. Das verlangt allerdings, dass der Tablespace in sich abgeschlossen ist, also keine Objekte enthält, die mit Objekten außerhalb verzahnt sind. DBMS_TTS.TRANSPORT_SET_CHECK prüft das vorab und meldet die Verstöße, und diese Prüfung machst du besser einmal in Ruhe als mitten im Störungsfall.
Flashback ist der schnellere Weg, wenn er vorbereitet ist
Flashback Query und Flashback Table arbeiten aus dem Undo heraus und brauchen keine Sicherung. Beide reichen aber nur so weit zurück, wie Undo aufbewahrt wird, im Alltag also oft Stunden statt Tage. Für den versehentlich geänderten Datensatz von vor zwanzig Minuten sind sie die richtige Antwort, für den Importfehler von gestern Abend nicht mehr.
Flashback Database dreht die gesamte Datenbank zurück und ist um ein Vielfaches schneller als Restore plus Recover, weil nichts aus der Sicherung gelesen wird. Dafür muss die Funktion vorher eingeschaltet und der Fast Recovery Area genug Platz zugewiesen worden sein, und die Reichweite begrenzt DB_FLASHBACK_RETENTION_TARGET. Ob sie in deiner Edition und nach deinem Vertrag zur Verfügung steht, klärst du am besten einmal in Ruhe und nicht im Störungsfall.
Praktisch heißt das: Prüf im Ernstfall zuerst, wie weit Undo und Flashback zurückreichen, und greif erst danach zur Sicherung. Diese Reihenfolge kostet dich zwei Minuten und spart im günstigen Fall zwei Stunden.
Nach dem RESETLOGS beginnt eine neue Zeitrechnung
Mit OPEN RESETLOGS setzt Oracle die Log-Sequenz auf 1 zurück und legt eine neue Inkarnation an. Die alten Archive-Logs verlieren damit ihren Anschluss an die geöffnete Datenbank, sie gehören zur vorherigen Inkarnation. RMAN verwaltet das sauber, und mit RESET DATABASE TO INCARNATION lässt sich auch wieder auf einen älteren Zweig wechseln, verlassen solltest du dich darauf aber nicht.
Deshalb ist die vollständige Sicherung direkt nach dem Öffnen kein Nice-to-have. Ohne sie hast du für die nächsten Stunden nur Sicherungen, die vor dem RESETLOGS liegen, und jeder weitere Zwischenfall wird deutlich unangenehmer. Plan die Zeit dafür von vornherein in das Wartungsfenster ein.
Zum Abschluss gehört ein kurzes Protokoll: gewählter Zeitpunkt, Begründung, verwendete Sicherung, Dauer der einzelnen Schritte. Beim nächsten Mal ist das die Grundlage für eine belastbare Aussage darüber, wie lange eine Wiederherstellung tatsächlich dauert, statt für eine Schätzung.
Dazu passende Kurse
Den Ablauf einmal unter Anleitung durchzuspielen, bevor er ernst wird, ist genau das, wofür es Oracle-Schulungen zu Backup und Wiederherstellung gibt.
Die Fragen nach Wiederanlaufzeit und zulässigem Datenverlust stellen sich bei jedem System gleich, deshalb lohnen sich Kurse rund um Sicherung und Verfügbarkeit von Datenbanken auch für gemischte Landschaften.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Super Schulung, in der der Trainer auch auf eigene Fragestellungen eingegangen ist.
Super Grundlagenschulung mit allen wichtigen Punkten und hilfreichen Tipps!
Schön, sich 5 Tage ungestört mit Postgres beschäftigen zu können.
Häufige Fragen
Brauche ich für eine zeitpunktgenaue Wiederherstellung den Archivelog-Modus?
Was passiert, wenn mitten in der Kette ein Archive-Log fehlt?
Kann ich eine einzelne Tabelle zurückholen, ohne die Datenbank zu schließen?
Wie oft sollte eine Wiederherstellung geübt werden?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Datenbanken-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Wiederherstellung, die im Ernstfall sitzt
RMAN am laufenden System zu bedienen, samt Probe auf einer Kopie, üben die Oracle-Kurse bei cmt an echten Datenbanken statt an Folien.