Ein Data-Pump-Export kann Minuten oder Stunden laufen, während die Anwendung weiterarbeitet. Ändern sich währenddessen zusammengehörige Datensätze, kann ein Export ohne festgelegten Zeitpunkt Werte aus unterschiedlichen Momenten enthalten. Bei einer Migration mit mehreren Exportjobs wird das besonders kritisch: Eine Bestellung könnte im einen Dump bereits vorhanden sein, ihre Positionen im anderen aber noch nicht.
FLASHBACK_SCN oder FLASHBACK_TIME liest Data Pump Nutzdaten so, wie sie zu einem definierten Datenbankzeitpunkt bestanden. Für mehrere getrennte Exportjobs verwenden Sie denselben zuvor ermittelten SCN.Zeitpunktkonsistenz gezielt aktivieren
Für einen einzelnen Exportjob kann FLASHBACK_TIME=SYSTIMESTAMP einen konsistenten Startzeitpunkt auf Basis der aktuellen Zeit festlegen. Wenn mehrere Jobs denselben Stand exportieren müssen, ermitteln Sie vor dem ersten Export einen SCN und tragen ihn in alle Parameterdateien ein:
-- Einmal vor den Exportjobs ermitteln und dokumentieren:
SELECT current_scn FROM v$database;
-- Beispielinhalt einer Data-Pump-Parameterdatei:
DIRECTORY=DPUMP_DIR
DUMPFILE=orders_%U.dmp
LOGFILE=orders_export.log
SCHEMAS=ORDERS_APP
FLASHBACK_SCN=1234567890123Die konkrete SCN-Zahl ist hier nur ein Beispiel. Die Exportverbindung muss auf die richtige Quelldatenbank beziehungsweise PDB zeigen; dokumentieren Sie Service, Schema, Zeitpunkt und SCN gemeinsam im Migrationsprotokoll. FLASHBACK_SCN und FLASHBACK_TIME sind Alternativen und dürfen nicht gemeinsam für denselben Job angegeben werden. Ein SCN aus einer anderen Datenbank ist kein geeigneter Bezugspunkt.
Der SCN braucht ausreichend UNDO
Data Pump verwendet Flashback Query, um ältere Zeilenversionen für den gewählten Stand zu lesen. Dafür müssen die benötigten UNDO-Datensätze noch verfügbar sein, bis der Export sie gelesen hat. Hohe Änderungsrate, knapp bemessener UNDO-Tablespace oder eine lange Laufzeit können zu ORA-01555: snapshot too old führen.
Vor dem Lauf sollten DBAs Exportdauer, Änderungsvolumen und UNDO-Nutzung in einer repräsentativen Umgebung beobachten. UNDO_RETENTION ist ein Planungswert, aber allein keine Garantie, wenn Speicher unter Druck steht. Eine Retention Guarantee sollte nicht unüberlegt gesetzt werden, denn sie kann stattdessen laufende DML-Transaktionen bei Platzmangel gefährden. Bei besonders langen Exporten sind ein belastbarer UNDO-Plan und ein getesteter Wiederanlauf entscheidend.
Vorgehen für eine Migration
- Schemaänderungen während der Snapshot-Phase einfrieren oder mit dem Migrationsteam koordinieren.
- Quell-PDB, betroffene Schemas, Jobanzahl und benötigte Objekte festlegen.
- SCN einmalig erfassen und dieselbe Zahl in alle zusammengehörigen Exportparameterdateien übernehmen.
- UNDO-Kapazität und erwartete Dauer anhand von Last und Testexport bewerten.
- Export-Logs prüfen und Import in einer Testumgebung mit den zugehörigen Dumps durchspielen.
- Vor dem Cutover fachliche Summen, Schlüsselbeziehungen und Stichproben zwischen Quelle und Ziel vergleichen.
Der feste SCN ersetzt weder Backup noch Importprüfung. Er sorgt dafür, dass die exportierten Zeilen zueinander passen; Berechtigungen, Objektdefinitionen, nicht exportierte Abhängigkeiten und die tatsächliche Wiederherstellbarkeit müssen weiterhin separat geprüft werden.
Fazit
Für konsistente Data-Pump-Migrationen ist ein gemeinsamer Snapshot oft wichtiger als ein schnellerer Export. Mit einem dokumentierten FLASHBACK_SCN, abgestimmten Jobs und realistisch dimensioniertem UNDO erhalten Sie einen reproduzierbaren Datenstand – und erkennen früh, ob die Exportlaufzeit zum vorhandenen Betriebsfenster passt.
Weiterführend: Oracles Referenz zu FLASHBACK_SCN und FLASHBACK_TIME beim Data-Pump-Export, zum Fehler ORA-01555 und zur UNDO-Verwaltung.