Oracle Flashback Query: Gelöschte Daten mit SQL retten

Wichtige Daten wurden versehentlich gelöscht, ein fehlerhaftes UPDATE wurde ausgeführt oder eine Anwendung hat falsche Werte in eine Tabelle geschrieben. Besonders unangenehm wird die Situation, wenn die Änderung bereits mit einem COMMIT bestätigt wurde und das Problem erst im laufenden Betrieb auffällt.

Ein vollständiges Datenbank-Backup muss deshalb noch nicht sofort eingespielt werden. Oracle bietet mit der Flashback Query eine Möglichkeit, frühere Datenstände direkt per SQL abzufragen. Solange die dafür benötigten Informationen noch im Undo-Bereich der Datenbank verfügbar sind, können gelöschte oder überschriebene Datensätze häufig innerhalb weniger Minuten identifiziert und gezielt zurückgeschrieben werden.

Die wichtigste Einschränkung lautet jedoch:

Eine Flashback Query stellt Daten nicht automatisch wieder her. Sie zeigt zunächst nur, wie die Daten zu einem früheren Zeitpunkt ausgesehen haben.

Die eigentliche Wiederherstellung erfolgt anschließend beispielsweise über ein kontrolliertes INSERT, UPDATE oder MERGE.

Was ist eine Oracle Flashback Query?

Mit einer Flashback Query kann eine Tabelle so abgefragt werden, wie sie zu einem bestimmten Zeitpunkt oder bei einer bestimmten System Change Number ausgesehen hat.

Dafür stellt Oracle unter anderem folgende Klauseln bereit:

AS OF TIMESTAMP
AS OF SCN
VERSIONS BETWEEN TIMESTAMP
VERSIONS BETWEEN SCN

Die normale Tabelle bleibt dabei unverändert. Oracle rekonstruiert für die Abfrage einen konsistenten historischen Datenstand und liefert die damals vorhandenen Datensätze zurück. AS OF gibt dabei eine einzelne frühere Version zurück, während VERSIONS BETWEEN mehrere Versionen eines Datensatzes innerhalb eines Zeitraums anzeigen kann.

Eine Flashback Query eignet sich insbesondere für:

versehentlich gelöschte Datensätze,
fehlerhafte Massenänderungen,
überschriebene Spaltenwerte,
Vergleiche zwischen aktuellem und früherem Datenstand,
die Analyse zeitlich begrenzter Datenfehler,
die Vorbereitung einer gezielten Datenkorrektur.

Sie ist keine vollständige Alternative zu Backups, Recovery-Konzepten oder einem revisionssicheren Änderungsprotokoll.

Wie funktioniert die Flashback Query?

Oracle verwendet Undo-Daten, um frühere Versionen geänderter Datenblöcke zu rekonstruieren. Diese Informationen werden im Undo Tablespace gespeichert.

Undo-Daten werden unter anderem benötigt, um:

nicht bestätigte Transaktionen zurückzurollen,
konsistente Lesezugriffe zu ermöglichen,
ältere Datenstände für Flashback-Abfragen bereitzustellen,
konkurrierende Lese- und Schreibzugriffe voneinander zu entkoppeln.

Wird ein Datensatz während einer laufenden Abfrage verändert, kann Oracle mithilfe der Undo-Informationen die Version rekonstruieren, die zum Beginn der Abfrage gültig war. Ein lesender Benutzer erhält daher einen konsistenten Datenstand, ohne einen schreibenden Benutzer grundsätzlich blockieren zu müssen.

Dabei stammen nicht automatisch alle Ergebnisse aus dem Undo Tablespace. Oracle liest die aktuellen Datenblöcke und verwendet Undo-Informationen nur dort, wo frühere Zustände rekonstruiert werden müssen.

Was passiert nach einem COMMIT?

Ein häufiger Irrtum besteht darin, dass Undo-Daten unmittelbar nach einem COMMIT gelöscht würden.

Das ist nicht der Fall.

Nach dem COMMIT werden die Undo-Informationen nicht mehr für ein mögliches Rollback dieser Transaktion benötigt. Sie können aber weiterhin für konsistente Abfragen und Flashback-Funktionen verwendet werden. Erst wenn Oracle den Speicherplatz erneut benötigt, können ältere Undo-Informationen überschrieben werden.

Wie lange ein früherer Datenstand verfügbar bleibt, hängt unter anderem von folgenden Faktoren ab:

Größe des Undo Tablespace,
Änderungsvolumen der Datenbank,
Anzahl paralleler Transaktionen,
Dauer laufender Abfragen,
Einstellung von UNDO_RETENTION,
automatisch berechneter Undo-Aufbewahrungsdauer,
aktivierter oder deaktivierter Retention Guarantee.

Es gibt daher kein allgemeingültiges Flashback-Zeitfenster von fünf, zehn oder fünfzehn Minuten. Auf einer ruhigen Datenbank können historische Daten wesentlich länger verfügbar bleiben. Auf einem stark ausgelasteten System kann das nutzbare Zeitfenster deutlich kürzer sein.

Oracle stellt über V$UNDOSTAT.TUNED_UNDORETENTION einen Wert bereit, mit dem die tatsächlich angepasste Undo-Aufbewahrungsdauer beobachtet werden kann. Selbst ein gesetzter Wert für UNDO_RETENTION garantiert jedoch nicht grundsätzlich, dass ältere Undo-Daten bei Platzmangel erhalten bleiben. Dafür wäre eine Retention Guarantee erforderlich.

Voraussetzungen für eine Flashback Query

Damit eine Flashback Query funktioniert, müssen mehrere Voraussetzungen erfüllt sein.

Undo-Daten müssen noch vorhanden sein

Der gewünschte Zeitpunkt muss innerhalb des noch verfügbaren Undo-Zeitraums liegen. Wurden die benötigten Informationen bereits überschrieben, kann Oracle den früheren Zustand nicht mehr rekonstruieren.

Erforderliche Berechtigungen

Der Benutzer benötigt die erforderlichen Lese- und Flashback-Berechtigungen auf den betroffenen Objekten. Je nach Berechtigungskonzept können dazu beispielsweise gehören:

GRANT SELECT ON emp TO recovery_user;
GRANT FLASHBACK ON emp TO recovery_user;

Alternativ können entsprechende systemweite Berechtigungen vergeben sein. Flashback-Berechtigungen sollten in Produktivsystemen nur gezielt und nach dem Prinzip der minimal erforderlichen Rechte vergeben werden.

Keine problematischen Strukturänderungen

Bestimmte DDL-Operationen können verhindern, dass auf einen Datenstand vor der Strukturänderung zurückgegriffen wird. Dazu gehören beispielsweise Änderungen an Spalten, Partitionen, Tabellenbewegungen oder ein TRUNCATE TABLE.

Eine Flashback Query eignet sich daher vor allem zur Wiederherstellung nach fehlerhaften DML-Operationen wie:

INSERT,
UPDATE,
DELETE,
MERGE.

Erste Maßnahme nach einer fehlerhaften Änderung

Nach einer versehentlichen Datenänderung sollte zuerst der ungefähre Zeitpunkt des Fehlers bestimmt werden.

Dabei helfen:

Anwendungslogs,
SQL-Protokolle,
Batchlaufzeiten,
Benutzerangaben,
Job-Historien,
Monitoring-Daten,
Zeitstempel angrenzender Datensätze.

Je genauer der Zeitpunkt eingegrenzt wird, desto geringer ist das Risiko, einen falschen historischen Datenstand zu verwenden.

Weitere unnötige Änderungen an den betroffenen Tabellen sollten vermieden werden. Starkes zusätzliches Änderungsvolumen kann dazu führen, dass ältere Undo-Daten schneller überschrieben werden.

Vor jeder Rückschreibung sollte der historische Zustand ausschließlich mit SELECT geprüft und in einer separaten Sicherungstabelle gespeichert werden.

Einfache Flashback Query mit AS OF TIMESTAMP

Mit AS OF TIMESTAMP wird die Tabelle zu einem bestimmten Zeitpunkt in der Vergangenheit abgefragt.

Das folgende Beispiel zeigt den Zustand der Tabelle emp vor fünf Minuten:

SELECT *
FROM emp AS OF TIMESTAMP
     (SYSTIMESTAMP - INTERVAL '5' MINUTE)
WHERE empno = 1234;

Oracle versucht dabei, den Datensatz mit der Personalnummer 1234 so darzustellen, wie er vor fünf Minuten vorhanden war.

Das Intervall kann angepasst werden:

SELECT *
FROM emp AS OF TIMESTAMP
     (SYSTIMESTAMP - INTERVAL '30' MINUTE);

Oder für mehrere Stunden:

SELECT *
FROM emp AS OF TIMESTAMP
     (SYSTIMESTAMP - INTERVAL '2' HOUR);

Diese Schreibweise eignet sich für eine schnelle erste Analyse. Für eine tatsächliche Wiederherstellung sollte jedoch möglichst ein exakter Zeitpunkt verwendet werden.

Flashback Query mit einem festen Zeitpunkt

Ein konkreter Zeitstempel verhindert, dass sich der abgefragte Zeitpunkt bei jeder erneuten Ausführung verschiebt.

SELECT *
FROM emp AS OF TIMESTAMP
     TO_TIMESTAMP(
         '2026-07-30 10:42:00',
         'YYYY-MM-DD HH24:MI:SS'
     )
WHERE empno = 1234;

Diese Variante ist für Wiederherstellungsarbeiten wesentlich sicherer als ein relatives Intervall.

Der Zeitstempel sollte unmittelbar vor der fehlerhaften Transaktion liegen. Wird ein zu früher Zeitpunkt gewählt, können zwischenzeitlich korrekt durchgeführte Änderungen fehlen. Wird ein zu später Zeitpunkt gewählt, kann der Fehler bereits enthalten sein.

Flashback Query mit AS OF SCN

Alternativ kann ein früherer Zustand über die System Change Number abgefragt werden.

SELECT *
FROM emp AS OF SCN 123456789
WHERE empno = 1234;

Eine SCN identifiziert einen logischen Änderungsstand innerhalb der Oracle-Datenbank. Sie ist häufig genauer und eindeutiger als ein menschlich angegebener Zeitstempel.

Die aktuelle SCN kann beispielsweise mit folgender Abfrage ermittelt werden:

SELECT current_scn
FROM v$database;

Ein Zeitstempel kann außerdem in eine SCN umgerechnet werden:

SELECT TIMESTAMP_TO_SCN(
           TO_TIMESTAMP(
               '2026-07-30 10:42:00',
               'YYYY-MM-DD HH24:MI:SS'
           )
       ) AS flashback_scn
FROM dual;

Auch diese Umrechnung ist nur möglich, solange Oracle den betreffenden Zeitraum noch ausreichend zuordnen kann.

Flashback Query bei JOINs

Die AS OF-Klausel bezieht sich jeweils auf das unmittelbar davor angegebene Objekt.

Werden mehrere Tabellen miteinander verbunden, sollte für jede Tabelle derselbe Flashback-Zeitpunkt angegeben werden:

SELECT
    c.customer_id,
    c.customer_name,
    o.order_id,
    o.order_date
FROM customers AS OF TIMESTAMP :flashback_ts c
JOIN orders AS OF TIMESTAMP :flashback_ts o
    ON o.customer_id = c.customer_id
WHERE c.customer_id = :customer_id;

Die Verwendung einer Bind-Variable stellt sicher, dass beide Tabellen zum exakt gleichen Zeitpunkt abgefragt werden.

Ohne einheitlichen Zeitpunkt könnten aktuelle und historische Datenstände unbeabsichtigt miteinander kombiniert werden.

Aktuelle und frühere Daten vergleichen

Vor einer Wiederherstellung sollte zunächst ermittelt werden, welche Werte sich tatsächlich verändert haben.

SELECT
    current_data.empno,
    current_data.sal AS aktuelles_gehalt,
    old_data.sal     AS frueheres_gehalt
FROM emp current_data
JOIN emp AS OF TIMESTAMP :flashback_ts old_data
    ON old_data.empno = current_data.empno
WHERE NVL(current_data.sal, -1)
      &lt;> NVL(old_data.sal, -1);

Diese Abfrage zeigt alle Datensätze, deren Gehalt sich zwischen dem historischen Zeitpunkt und dem aktuellen Stand unterscheidet.

Für Textwerte, Datumsfelder und andere Datentypen muss die Vergleichslogik entsprechend angepasst werden.

Historischen Datenstand zuerst sichern

Bevor Daten in der Originaltabelle verändert werden, sollte eine separate Recovery-Tabelle angelegt werden:

CREATE TABLE emp_recovery_20260730 AS
SELECT *
FROM emp AS OF TIMESTAMP
     TO_TIMESTAMP(
         '2026-07-30 10:42:00',
         'YYYY-MM-DD HH24:MI:SS'
     );

Dadurch steht der rekonstruierte Datenstand auch dann noch zur Verfügung, wenn die ursprünglichen Undo-Informationen später überschrieben werden.

Anschließend sollten mindestens folgende Kontrollen durchgeführt werden:

SELECT COUNT(*)
FROM emp_recovery_20260730;

SELECT *
FROM emp_recovery_20260730
WHERE empno = 1234;

Erst nach einer fachlichen Prüfung sollte mit der Rückschreibung begonnen werden.

Gelöschte Datensätze wiederherstellen

Wurden Datensätze durch ein fehlerhaftes DELETE entfernt, können sie aus dem historischen Zustand zurückgeschrieben werden.

INSERT INTO emp (
    empno,
    ename,
    deptno,
    sal
)
SELECT
    old_data.empno,
    old_data.ename,
    old_data.deptno,
    old_data.sal
FROM emp AS OF TIMESTAMP :flashback_ts old_data
WHERE NOT EXISTS (
    SELECT 1
    FROM emp current_data
    WHERE current_data.empno = old_data.empno
);

Die NOT EXISTS-Bedingung verhindert, dass bereits vorhandene Primärschlüssel erneut eingefügt werden.

In der Praxis sollte die Abfrage zusätzlich auf die tatsächlich betroffenen Datensätze eingeschränkt werden. Ein unkontrolliertes Zurückschreiben der gesamten historischen Tabelle kann korrekte spätere Änderungen verfälschen.

Beispiel:

INSERT INTO emp (
    empno,
    ename,
    deptno,
    sal
)
SELECT
    old_data.empno,
    old_data.ename,
    old_data.deptno,
    old_data.sal
FROM emp AS OF TIMESTAMP :flashback_ts old_data
WHERE old_data.deptno = 20
  AND NOT EXISTS (
      SELECT 1
      FROM emp current_data
      WHERE current_data.empno = old_data.empno
  );

Fehlerhafte Updates mit MERGE zurücksetzen

Bei versehentlich überschriebenen Werten ist häufig ein gezieltes MERGE sinnvoll:

MERGE INTO emp current_data
USING (
    SELECT
        empno,
        ename,
        deptno,
        sal
    FROM emp AS OF TIMESTAMP :flashback_ts
    WHERE empno = :empno
) old_data
ON (
    current_data.empno = old_data.empno
)
WHEN MATCHED THEN
    UPDATE SET
        current_data.ename  = old_data.ename,
        current_data.deptno = old_data.deptno,
        current_data.sal    = old_data.sal;

Vor der Ausführung sollte dieselbe Datenmenge zunächst mit einem SELECT geprüft werden.

Die Transaktion sollte erst bestätigt werden, nachdem Anzahl und Inhalt der geänderten Zeilen kontrolliert wurden:

SELECT *
FROM emp
WHERE empno = :empno;

Danach folgt entweder:

COMMIT;

oder bei einem fehlerhaften Ergebnis:

ROLLBACK;

Änderungen mit VERSIONS BETWEEN analysieren

Eine Flashback Version Query zeigt nicht nur einen einzelnen früheren Zustand, sondern mehrere bestätigte Versionen eines Datensatzes innerhalb eines Zeitraums.

SELECT
    empno,
    sal,
    versions_starttime,
    versions_endtime,
    versions_operation,
    versions_xid
FROM emp
VERSIONS BETWEEN TIMESTAMP
    TO_TIMESTAMP(
        '2026-07-30 10:00:00',
        'YYYY-MM-DD HH24:MI:SS'
    )
    AND SYSTIMESTAMP
WHERE empno = 1234
ORDER BY versions_starttime;

Wichtige Pseudospalten sind:

Pseudospalte	Bedeutung
`VERSIONS_STARTTIME`	Beginn der Datensatzversion
`VERSIONS_ENDTIME`	Ende der Datensatzversion
`VERSIONS_STARTSCN`	SCN beim Beginn der Version
`VERSIONS_ENDSCN`	SCN beim Ende der Version
`VERSIONS_OPERATION`	Art der Änderung
`VERSIONS_XID`	Transaktionskennung

Bei VERSIONS_OPERATION werden typischerweise folgende Werte angezeigt:

I für Insert,
U für Update,
D für Delete.

Damit lässt sich nachvollziehen, ob ein Datensatz eingefügt, verändert oder gelöscht wurde. Oracle weist darauf hin, dass eine Änderung eines Indexschlüssels unter bestimmten Umständen als Kombination aus Löschen und Einfügen erscheinen kann.

Verfügbare Undo-Dauer prüfen

Administratoren können die konfigurierte Undo-Aufbewahrung prüfen:

SHOW PARAMETER undo_retention;

Die von Oracle automatisch angepasste Aufbewahrungsdauer kann über V$UNDOSTAT ausgewertet werden:

SELECT *
FROM (
    SELECT
        begin_time,
        end_time,
        tuned_undoretention
    FROM v$undostat
    ORDER BY begin_time DESC
)
WHERE ROWNUM &lt;= 12;

TUNED_UNDORETENTION wird in Sekunden angegeben.

Der Wert ist eine wichtige Orientierung, aber keine uneingeschränkte Garantie, dass jede Tabelle über den gesamten Zeitraum erfolgreich abgefragt werden kann.

Häufige Fehler bei Flashback Queries

ORA-01555: snapshot too old

ORA-01555: snapshot too old

Dieser Fehler bedeutet, dass Undo-Informationen, die für eine konsistente Rekonstruktion benötigt würden, bereits überschrieben wurden.

Mögliche Ursachen sind:

zu kleiner Undo Tablespace,
zu geringe Undo-Aufbewahrung,
hohes Änderungsvolumen,
sehr lange laufende Abfrage,
zu weit zurückliegender Flashback-Zeitpunkt.

Oracle beschreibt den Fehler als Situation, in der benötigte Rollback-Informationen durch andere Schreibvorgänge überschrieben wurden.

ORA-08180: no snapshot found based on specified time

ORA-08180: no snapshot found based on specified time

Bei diesem Fehler konnte Oracle den angegebenen Zeitpunkt keiner geeigneten SCN mehr zuordnen.

Ein geringfügig späterer Zeitpunkt kann funktionieren. Liegt der gewünschte Datenstand zu weit zurück, sind jedoch andere Recovery-Verfahren erforderlich.

ORA-01466: unable to read data – table definition has changed

ORA-01466: unable to read data - table definition has changed

Dieser Fehler kann auftreten, wenn sich die Definition der Tabelle oder eines zugehörigen Objekts zwischen dem historischen Zeitpunkt und der aktuellen Abfrage geändert hat.

Besonders kritisch sind Operationen wie:

TRUNCATE TABLE,
Verschieben einer Tabelle,
Ändern oder Entfernen von Spalten,
bestimmte Partitionsänderungen,
größere strukturelle DDL-Anpassungen.

Flashback Query, Flashback Table und Flashback Database

Die verschiedenen Oracle-Flashback-Funktionen dürfen nicht miteinander verwechselt werden.

Flashback Query

SELECT ...
FROM tabelle AS OF TIMESTAMP ...

Die Flashback Query liest historische Daten. Die aktuelle Tabelle wird nicht verändert.

Flashback Table

FLASHBACK TABLE emp
TO TIMESTAMP ...;

Flashback Table setzt eine komplette Tabelle auf einen früheren Zustand zurück. Dafür gelten zusätzliche Voraussetzungen, Berechtigungen und Einschränkungen. Unter anderem muss für bestimmte Vorgänge Row Movement aktiviert sein.

Flashback Database

Flashback Database setzt einen wesentlich größeren Teil der Datenbank oder die gesamte Datenbank auf einen früheren Zustand zurück. Diese Funktion arbeitet mit Flashback Logs und ist für größere logische Fehler vorgesehen. Sie ist kein Ersatz für die gezielte Wiederherstellung einzelner Datensätze.

Backup und Point-in-Time Recovery

Sind die benötigten Undo-Daten nicht mehr verfügbar, bleiben je nach Infrastruktur unter anderem:

Wiederherstellung aus einem Backup,
Point-in-Time Recovery,
Data Guard,
Exportdateien,
Audit-Tabellen,
Anwendungsprotokolle,
LogMiner,
Flashback Data Archive.

Flashback Query ersetzt kein Backup

Eine Flashback Query ist ein leistungsfähiges Werkzeug für kurzfristig erkannte logische Fehler. Sie schützt jedoch nicht vor:

beschädigten Datendateien,
Hardwareausfällen,
verlorenen Tablespaces,
länger zurückliegenden Fehlern,
überschriebenen Undo-Daten,
ungeeigneten DDL-Änderungen,
vollständigem Datenbankverlust.

Ein belastbares Datenbankkonzept benötigt weiterhin regelmäßige Backups, getestete Wiederherstellungsverfahren und eine angemessene Aufbewahrung von Archiv- und Redo-Logs.

Bewährtes Vorgehen im Ernstfall

Bei einer versehentlichen Änderung empfiehlt sich folgende Reihenfolge:

Zeitpunkt und Umfang des Fehlers bestimmen.
Weitere unnötige Änderungen an den betroffenen Daten vermeiden.
Historischen Stand ausschließlich mit SELECT prüfen.
Betroffene Datensätze möglichst eng filtern.
Historischen Stand in einer separaten Recovery-Tabelle sichern.
Aktuelle und frühere Werte miteinander vergleichen.
Rückschreibeskript zunächst ohne COMMIT ausführen.
Zeilenanzahl und Ergebnis fachlich kontrollieren.
Erst danach die Transaktion bestätigen.
Ursache des Fehlers dokumentieren und dauerhaft beheben.

Besonders bei Massenänderungen sollte niemals allein aufgrund eines ungeprüften Zeitstempels die gesamte Tabelle zurückgeschrieben werden.

Häufige Fragen zur Oracle Flashback Query

Funktioniert eine Flashback Query auch nach einem COMMIT?

Ja. Ein COMMIT verhindert die Flashback Query nicht automatisch. Die Abfrage funktioniert, solange die benötigten Undo-Informationen noch vorhanden sind.

Wie lange kann auf frühere Daten zugegriffen werden?

Es gibt keinen festen Zeitraum. Die verfügbare Dauer hängt unter anderem von Undo-Größe, Änderungsvolumen, UNDO_RETENTION und den Tablespace-Einstellungen ab.

Kann eine gelöschte Zeile direkt wiederhergestellt werden?

Die Flashback Query liest zunächst nur den früheren Datensatz. Anschließend kann er mit einem kontrollierten INSERT zurückgeschrieben werden.

Kann ein fehlerhaftes UPDATE rückgängig gemacht werden?

Ja. Die früheren Werte können mit AS OF TIMESTAMP oder AS OF SCN gelesen und anschließend beispielsweise über UPDATE oder MERGE zurückgeschrieben werden.

Funktioniert Flashback Query nach TRUNCATE TABLE?

Ein TRUNCATE TABLE ist eine DDL-Operation und kann eine normale Flashback Query auf einen Zeitpunkt vor dem Truncate verhindern. In diesem Fall müssen andere Flashback- oder Recovery-Verfahren geprüft werden.

Verändert eine Flashback Query die Tabelle?

Nein. Eine Flashback Query ist zunächst eine historische Leseabfrage. Erst ein zusätzlich ausgeführtes INSERT, UPDATE, MERGE oder FLASHBACK TABLE verändert aktuelle Daten.

Kann AS OF TIMESTAMP mit FOR UPDATE kombiniert werden?

Nein. Oracle erlaubt die AS OF-Klausel nicht gemeinsam mit FOR UPDATE.

Fazit

Die Oracle Flashback Query gehört zu den wichtigsten Werkzeugen bei versehentlichen Datenänderungen. Mit wenigen SQL-Erweiterungen kann geprüft werden, wie eine Tabelle vor einem fehlerhaften DELETE, UPDATE oder MERGE ausgesehen hat.

Die grundlegende Abfrage lautet:

SELECT *
FROM emp AS OF TIMESTAMP
     (SYSTIMESTAMP - INTERVAL '5' MINUTE);

Für eine sichere Wiederherstellung reicht dieser Befehl allein jedoch nicht aus. Entscheidend sind ein exakt bestimmter Fehlerzeitpunkt, eine eng gefilterte Datenmenge, eine separate Sicherung des historischen Zustands und eine kontrollierte Rückschreibung.

Solange die benötigten Undo-Daten noch vorhanden sind, kann die Flashback Query aus einem kritischen Produktionsfehler eine überschaubare und gezielt korrigierbare Situation machen.

Hinweis: Alle Angaben wurden sorgfältig und nach bestem Wissen recherchiert. Für Richtigkeit, Vollständigkeit und Aktualität wird keine Gewähr übernommen. Termine, Preise, Leistungen, Teilnahmebedingungen, Öffnungszeiten, Verfügbarkeiten, gesetzliche Regelungen und sonstige Rahmenbedingungen können sich jederzeit kurzfristig ändern. Dieser Beitrag stellt keine individuelle Rechts-, Finanz-, Steuer-, Gesundheits- oder sonstige Fachberatung dar. Änderungen sind jederzeit möglich; maßgeblich sind die aktuellen Angaben des jeweiligen Anbieters oder Veranstalters. Eine Haftung wird ausgeschlossen.