DBAtlas · Atlas für Datenbankbetrieb

Oracle Data Pump: Export / Import, Migration, Schema-Refresh und Transportable

OracleStufe: MittelDauer: 30–90 min (je nach Datenmenge)

Tabellen-, Schema-, Tablespace- oder Full-Export und -Import mit expdp/impdp, Migration zwischen zwei Datenbanken (Dumpdatei + scp + Prüfsumme oder NETWORK_LINK) und DDL-Extraktion aus einem Dump (SQLFILE). Inklusive Vorbereitung von Directory, Benutzer und Parfile, Konsistenz, Parallelität, Remapping, Überwachung und Bereinigung abgebrochener Jobs. Unter RAC: Verbindung über SCAN + Service, CLUSTER=YES mit gemeinsamem Directory oder CLUSTER=NO mit lokaler Platte; optional die zeitgesteuerte Ausführung des Exports mit einem Wallet-basierten Skript und /etc/cron.d. Szenarien: Schema-Refresh von Produktion nach Test (DROP USER … CASCADE oder TABLE_EXISTS_ACTION=REPLACE, Passwort/Profil und Berechtigungen bleiben erhalten), Transportable Tablespace (gleiche/andere Plattform und Endian, RMAN CONVERT), Full Transportable (11g/12c → 19c-PDB), Verschlüsselung und Komprimierung des Dumps, Performance bei großen Migrationen sowie das Steuern eines abgebrochenen Jobs mit ATTACH/START_JOB/KILL_JOB.

Topologie: 1 Datenbank (Single Instance, Oracle Restart oder RAC); bei einer Migration Quelle + Ziel

Szenarien

  • Export: Dumpdatei aus der Datenbank erzeugen — Eine Tabelle, ein Schema, ein Tablespace oder die gesamte Datenbank wird in eine Dumpdatei geschrieben (expdp). Die Datenbank bleibt geöffnet, die Anwendung läuft weiter. Es ist eine logische Kopie: Sie ersetzt kein RMAN-Backup (Point-in-Time- und vollständiges Recovery erfordern RMAN).
  • Import: Dumpdatei in die Datenbank laden — Eine zuvor erstellte Dumpdatei wird mit impdp geladen; Schema-, Tablespace- und Tabellennamen lassen sich umbenennen (Remap). Das Ziel bleibt geöffnet; die Anwendung, die die geladenen Objekte nutzt, muss gestoppt werden.
  • Migration: Daten von der Quelldatenbank ins Ziel übertragen — Export → Dateikopie → Import oder direkt mit NETWORK_LINK ohne Dumpdatei. Wähle diese Karte, wenn das Schema im Ziel noch nicht existiert (Erstbefüllung); existiert dasselbe Schema im Ziel bereits und soll durch den Stand aus der Produktion ersetzt werden, wähle die Karte "Schema-Refresh". Die Quelle bleibt geöffnet.
  • Nur die DDL aus einer Dumpdatei extrahieren (SQLFILE) — Es wird nichts geladen; die CREATE-Anweisungen der Objekte werden in eine .sql-Datei geschrieben. Die Datenbank wird nicht verändert.
  • Schema-Refresh von Produktion nach Test — Ein Schema, das in Test/UAT bereits existiert, wird durch seinen aktuellen Stand aus der Produktion ersetzt: Backup des Zielschemas, Beenden der Sessions, DROP USER … CASCADE oder TABLE_EXISTS_ACTION=REPLACE, Passwort/Profil und Berechtigungen bleiben erhalten. Die Quelle bleibt geöffnet; das Zielschema ist während des Jobs nicht nutzbar.
  • Tablespace durch Kopieren der Datendateien übertragen (Transportable Tablespace) — Große Tablespaces (Hunderte GB und mehr) werden nicht zeilenweise, sondern durch Kopieren der Datendateien übertragen; gleiche oder andere Plattform/Endian (RMAN CONVERT). Die Zeichensätze müssen auf beiden Seiten gleich sein. In der Quelle sind die Tablespaces während des Jobs READ ONLY (Schreibunterbrechung).
  • Gesamte Datenbank übertragen: Full Transportable (11g/12c → 19c, Non-CDB → PDB) — Mit FULL=Y TRANSPORTABLE=ALWAYS werden die Benutzer-Tablespaces als Datendateien und alles andere (Benutzer, PL/SQL, Berechtigungen) als Metadaten in eine neue PDB übertragen; bei einer Quelle ab 11.2.0.3 mit VERSION=12. In der Quelle sind alle Benutzer-Tablespaces während des Jobs READ ONLY.
  • Abgebrochener / hängender Data-Pump-Job: überwachen, fortsetzen, beenden — Ein expdp/impdp-Job hängt (resumable wait), wurde gestoppt oder ist abgebrochen; du willst dich mit ATTACH anhängen und ihn fortsetzen, ihn mit KILL_JOB beenden oder eine verwaiste Master-Tabelle bereinigen. Die Datenbank bleibt geöffnet.

Vor dem Start

  • Die Befehle laufen auf dem Datenbankserver als Benutzer oracle; dessen Login-Profil definiert die Variablen ORACLE_HOME, ORACLE_SID und PATH, und expdp/impdp liegen im Pfad. expdp, impdp und sqlplus liegen unter $ORACLE_HOME/bin; ist das Verzeichnis nicht im PATH, erhältst du bash: expdp: command not found (. oraenv oder der vollständige Pfad: $ORACLE_HOME/bin/expdp).… Unter RAC ist ORACLE_SID auf jedem Knoten der Instanzname dieses Knotens (z. B. …………… auf Knoten 1).…
  • Datenbank 12.2 oder höher (19c, 21c, 23ai). Die in diesem Guide verwendeten Parameter LOGTIME, ENCRYPTION_PWD_PROMPT und DISABLE_ARCHIVE_LOGGING kamen mit 12c. Für 10g/11g ist die Parameterliste eine andere; .dmp-Dateien aus Oracle 9i und früher lassen sich nur mit dem alten imp öffnen.… Full Transportable: Export wird ab 11.2.0.3 unterstützt (unter 11g mit VERSION=12), Import ab 12.1; 11g kennt LOGTIME/METRICS nicht, der Guide verwendet sie in diesem Fall nicht.…
  • Der Listener läuft und der Service … ist registriert…; im Ziel ist der Service … registriert….
  • Auf dem Zielserver läuft der Listener und der Service … ist registriert.
  • Für …… (Quelle) und … (Ziel)… ist genug freier Platz vorhanden: beim Export so viel wie die geschätzte Größe (mit COMPRESSION=ALL meist 3- bis 5-mal weniger), beim Import müssen die Dumpdateien bereits in diesem Verzeichnis liegen. Das Verzeichnis darf nicht auf derselben Platte liegen wie die Datendateien und die FRA.
  • Damit bei einem lange laufenden konsistenten Export (FLASHBACK_TIME/SCN) kein ORA-01555 auftritt, ist UNDO_RETENTION länger als die Exportdauer (z. B. mindestens 10800 s für einen dreistündigen Export) und der Undo-Tablespace groß genug für diesen Zeitraum (autoextend).
  • Ein Import erzeugt viel Redo: Läuft die Datenbank im ARCHIVELOG-Modus, muss in der FRA (oder im Archivziel) Platz sein. DISABLE_ARCHIVE_LOGGING ist ohne Wirkung, wenn FORCE LOGGING aktiv ist (Data Guard).
  • Für die Zieldatenbank gibt es ein aktuelles RMAN-Backup und das Fallback-Verfahren ist festgelegt (ein Import lässt sich nicht rückgängig machen: Ein Import in das falsche Schema oder mit TRUNCATE/REPLACE lässt sich nur aus einem Backup oder mit Flashback zurücknehmen). In einer kritischen Umgebung kann vor dem Import ein Guaranteed Restore Point angelegt werden (erfordert ARCHIVELOG + FRA).
  • Ein Wartungsfenster ist eingeplant: …in der Quelle sind die übertragenen Tablespaces während des Exports und der Kopie der Datendateien READ ONLY (schreibende Anwendungen erhalten Fehler, ORA-00372); im Ziel dürfen die neuen Objekte während des Plug-in nicht genutzt werden…Anwendungen, die die Zielobjekte nutzen, müssen während des Imports gestoppt werden, oder es muss sichergestellt sein, dass sie nicht betroffen sind…da keine Konsistenzoption gewählt wurde, müssen Schreibzugriffe der Anwendung während des Exports gestoppt werden….
  • Der Benutzer oracle in der Quelle kann ohne Passwort (schlüsselbasiert) per SSH/SCP auf das Ziel zugreifen, oder die Dateien werden auf anderem Weg übertragen (gemeinsamer Speicher, Object Storage).
  • Der Zielserver erreicht den Listener-Port der Quelle (…:…) (Firewall offen).
  • Lizenzprüfung: …COMPRESSION=ALL (und DATA_ONLY) erfordert die Lizenz Advanced Compression Option. ……Die Dump-Verschlüsselung (ENCRYPTION, ENCRYPTION_PASSWORD/ENCRYPTION_PWD_PROMPT) erfordert unter Enterprise Edition die Lizenz Advanced Security Option. …Hast du keine Lizenz dafür, deaktiviere diese Optionen.

Phasen der Anleitung

  • Vorbereitung: Umgebung, Benutzer und Directory — Umgebung und Listener-Service prüfen · Umgebung und Listener-Service prüfen (Quelle) · Umgebung und Listener-Service prüfen (Ziel) · SCAN und Instanzen des Service prüfen · Version, Zeichensatz und Log-Modus prüfen · Version, Zeichensatz und Log-Modus prüfen (Quelle) …
  • 1. Diagnose: Ist das das richtige Ziel? (Schema-Refresh) — Zustand des Zielschemas festhalten (Ziel) · Zustand des Quellschemas festhalten (Quelle)
  • 2. Sicherheitsnetz: Backup des Zielschemas und der Benutzerdefinition — Definition und Berechtigungen des Testbenutzers sichern (Ziel) · Backup des Zielschemas erstellen (Ziel)
  • 1. Diagnose: Voraussetzungen für Transportable — Plattform, Zeichensatz und Tablespace-Menge in der Quelle prüfen (Quelle) · Plattform, Zeichensatz und Namenskonflikte im Ziel prüfen (Ziel)
  • 2. Sicherheitsnetz und Vorbereitung — Liste der Datendateien und aktuellen READ-ONLY-Status festhalten (Quelle) · Datendatei-Verzeichnis im Ziel vorbereiten (Ziel)
  • 3. Durchführung: READ ONLY, Metadaten-Export und Kopie in der Quelle — Tablespaces auf READ ONLY setzen (Quelle) · Parfile für den Transportable-Export schreiben (Quelle) · Metadaten-Export ausführen (Quelle) · Datendateien und Dump ins Ziel kopieren (Quelle)
  • 4. Durchführung: Plug-in im Ziel — Kopierte Dateien prüfen (Ziel) · Datendateien für diese Plattform konvertieren: RMAN CONVERT (Ziel) · Schemas der Objekteigentümer anlegen (Ziel) · Parfile für den Plug-in-Import anlegen (Ziel) · Plug-in-Import ausführen (Ziel) · Tablespaces beschreibbar machen (Ziel)
  • 5. Verifikation und Nacharbeiten — Objekte außerhalb der Tablespaces exportieren (Quelle) · Objekte außerhalb der Tablespaces laden (Ziel) · Ungültige Objekte kompilieren und prüfen (Ziel) · Tablespaces in der Quelle wieder auf READ WRITE setzen (Quelle)
  • Export — Große Objekte, LOBs und Partitionen prüfen · Größe schätzen (ESTIMATE_ONLY) · Größe schätzen (ESTIMATE_ONLY) (Quelle) · Export-Parfile schreiben · Export-Parfile schreiben (Quelle) · Export ausführen …
  • Dumpdateien ins Ziel übertragen — Prüfsummendatei anlegen · Dumpdateien ins Ziel kopieren · Prüfsumme im Ziel prüfen
  • Database Link (NETWORK_LINK) — Database Link im Ziel anlegen
  • 3. Durchführung: Zielschema leeren — Benutzer sperren und Sessions beenden (Ziel) · Schema löschen und Testbenutzer neu anlegen (Ziel) · Objekte auflisten, die im REPLACE-Modus nicht aktualisiert werden (Ziel)
  • Import — Dumpdateien prüfen · Dumpdateien prüfen (Ziel) · Platz und vorhandene Schemas im Ziel prüfen · Platz und vorhandene Schemas im Ziel prüfen (Ziel) · Import-Parfile schreiben · Import-Parfile schreiben (Ziel) …
  • Nach dem Import: Kompilierung und Statistiken — Ungültige Objekte kompilieren · Ungültige Objekte kompilieren (Ziel) · Statistiken erheben · Statistiken erheben (Ziel)
  • 4. Verifikation und Nacharbeiten (Schema-Refresh) — Aus der Produktion übernommene Scheduler-Jobs deaktivieren (Ziel) · Vom Schema an andere erteilte Berechtigungen erneut anwenden (Ziel) · Objekte, Synonyme und Links prüfen (Ziel) · Benutzer entsperren (Ziel)
  • SQLFILE: DDL aus einem Dump extrahieren — Dumpdateien prüfen · SQLFILE-Parfile schreiben · DDL-Datei erzeugen · DDL-Datei prüfen
  • Zeitplanung: Export regelmäßig ausführen (cron) — Verzeichnisse für Skript, Log und TNS vorbereiten… (…)… · Wallet anlegen und Zugangsdaten hinzufügen · Wallet auf die anderen Knoten kopieren · sqlnet.ora schreiben (nur für diesen Job)… (…)… · tnsnames.ora schreiben (nur für diesen Job)… (…)… · Export-Skript schreiben… (…)… …
  • 1. Diagnose: In welchem Zustand ist der Job? — Status, Sessions und Wartegrund des Jobs anzeigen · Ergebnis auswerten und Aktion wählen
  • 2. Durchführung: Job fortsetzen — Ursache für Stopp oder Suspendierung beheben · An den Job anhängen und fortsetzen (ATTACH, START_JOB) · Prüfen, dass der Job läuft
  • 2. Durchführung: Job beenden (KILL_JOB) — An den Job anhängen und mit KILL_JOB beenden · Prüfen, dass der Job entfernt ist
  • 2. Durchführung: verwaiste Master-Tabelle bereinigen — Master-Tabelle des verwaisten Jobs löschen
  • Überwachung — Laufenden Job überwachen · Laufenden Job überwachen (Quelle) · Laufenden Job überwachen (Ziel) · An den Job anhängen: ATTACH und interaktive Befehle · An den Job anhängen: ATTACH und interaktive Befehle (Quelle) · An den Job anhängen: ATTACH und interaktive Befehle (Ziel)
  • Bereinigung und Sicherheit — Abgebrochene Jobs und Master-Tabellen auflisten · Abgebrochene Jobs und Master-Tabellen auflisten (Quelle) · Abgebrochene Jobs und Master-Tabellen auflisten (Ziel) · Job mit KILL_JOB beenden · Job mit KILL_JOB beenden (Quelle) · Job mit KILL_JOB beenden (Ziel) …
Schritt-für-Schritt-Plan für Ihre Umgebung öffnen →