News zu Oracle

Lokales Dumpfile mit DataPump via Database Link erzeugen

Ein we­sent­li­ches Un­ter­schei­dungs­merk­mal des längst ab­ge­kün­dig­ten exp-Tools gegenüber DataPump ist, dass es Dumpfiles lokal auf dem Host ablegt, von dem aus des exp-Tool gestartet wurde. Für DataPump kann man dieses Feature mittels einer separaten Datenbank und Da­ta­base­Link nach­bil­den. Im folgenden Artikel wird das in Zu­sam­men­hang mit einem Kom­pa­ti­bi­li­täts­pro­blem bei einem Upgrade von 10gR2 nach 19c genutzt.

DataPump via Database Link

Grund­sätz­lich ist ein DataPump-Export sowohl hin­sicht­lich Quell-/Ziel­ver­sio­nen als auch En­di­an­for­ma­ten keinen Ein­schrän­kun­gen un­ter­wor­fen. Ein „Upgrade“ via Export/Import wird also technisch immer möglich sein. Pro­ble­ma­tisch kann das im konkreten Fall aber z.B. werden, wenn

  • auf dem Altsystem nicht mehr aus­rei­chend Platz für die Ex­port­files verfügbar ist,
  • das Neusystem keinen Zugriff auf die File­sys­te­me des Alt­sys­tems hat oder
  • kein ad­mi­nis­tra­ti­ver Zugriff auf das Altsystem möglich ist, um dort Shares zu mounten, auf die auch das Neusystem Zugriff hätte

Für diesen Zweck könnte man geneigt sein, auf DataPump via Database Link (Parameter network_link) zu­rück­zu­grei­fen. An dieser Stelle kann man aber sehr wohl in Kom­pa­ti­bi­li­täts­pro­ble­me laufen. Grund hierfür sind al­ler­dings nicht Ein­schrän­kun­gen des DataPump selbst, sondern die Tatsache, dass die Kom­mu­ni­ka­ti­on über Database Link den Re­strik­tio­nen der Client/Server In­ter­ope­ra­bi­li­ty (Doc ID 207303.1) un­ter­wor­fen ist.

So auch im vor­lie­gen­den Fall:

  • Das Altsystem läuft auf Oracle 10.2.0.3 (HP-UX, big endian)
  • Das Neusystem läuft auf Oracle 19c (Linux, little endian)
  • Es ist aus­schließ­lich Net*8‑Zugriff auf einen Account im Altsystem mit EX­P_FUL­L_­DA­TA­BA­SE-Privileg möglich
  • 19c-Clients sind nicht für den Zugriff auf 10gR2-Server zertifiziert

Der ur­sprüng­li­che Versuch, die Daten per Database Link direkt zu im­por­tie­ren, schei­ter­te folglich auch aufgrund der In­kom­pa­ti­bi­li­tät des 19c-Clients zum 10gR2-Server:

$ impdp userid=system/oracle network_link=altsystem nologfile=y full=y

Import: Release 19.0.0.0.0 - Production on Thu Jan 6 10:38:56 2022
Version 19.13.0.0.0

Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 19c Standard Edition 2 Release 19.0.0.0.0 - Production
ORA-39001: invalid argument value
ORA-39169: Local version of 19.13.0.0.0 cannot work with remote version of 10.2.0.3.0.

Eine mögliche Lösung für das Problem besteht darin, auf dem Neusystem zu­sätz­lich eine Client-/Server-kom­pa­ti­ble Datenbank zu in­stal­lie­ren und darüber einen Export in ein auf dem Neusystem ab­ge­leg­tes Dumpfile durch­zu­füh­ren. Im konkreten Fall fiel die Wahl auf eine Version 12.1.0, da das

  • lt Doc ID 207303.1 die höchste noch zu 10.2.0 Client-/Server-kom­pa­ti­ble Version und
  • von den 10gR2-kom­pa­ti­blen auch die einzige für das Neusystem-OS (Oracle En­ter­pri­se Linux 8) frei­ge­ge­be­ne ist.
    Innerhalb dieser zu­sätz­li­chen Datenbank (hier mig genannt) wird ein public database link auf den Benutzer im Altsystem angelegt, der über das EX­P_FUL­L_­DA­TA­BA­SE-Privileg verfügt:
SQL> create database link altsystem connect to system identified by „password“ using 'altsystem-ip:port/service';

Über diese 12.1‑Datenbank und den an­ge­leg­ten Database Link kann nun das 10gR2-Altsystem in ein Dumpfile auf dem Neusystem ex­por­tiert werden:

$ expdp userid=system/oracle@mig dumpfile=altsystem.dmp logfile=altsystem.exp.log network_link=altsystem full=y flashback_time=sysdate

Export: Release 12.1.0.2.0 - Production on Thu Jan 6 10:57:51 2022

Copyright (c) 1982, 2015, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 12c Standard Edition Release 12.1.0.2.0 - 64bit Production
Starting "SYSTEM"."SYS_EXPORT_FULL_01": userid=system/******** dumpfile=altsystem.dmp logfile=altsystem.exp.log network_link=altsystem full=y flashback_time=sysdate
Estimate in progress using BLOCKS method...
Processing object type DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 4.705 GB
Processing object type DATABASE_EXPORT/TABLESPACE
Processing object type DATABASE_EXPORT/SYS_USER/USER
Processing object type DATABASE_EXPORT/SCHEMA/USER

******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_FULL_01 is:
/u01/app/oracle/admin/migrate/dpdump/altsystem.dmp
Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully completed at Thu Jan 6 11:08:25 2022 elapsed 0 00:00:18

Das Dumpfile /u01/app/oracle/admin/migrate/dpdump/altsystem.dmp kann nun mit dem 19c impdp in die Ziel­da­ten­bank im­por­tiert werden.

Fazit

Wenn­gleich etwas auf­wän­di­ger als mit dem ab­ge­kün­dig­ten exp-Tool ist das Erstellen eines lokalen Ex­port­files auch mit DataPump weiterhin möglich. Der Aufwand ist al­ler­dings nur ge­recht­fer­tigt, wenn keine Mög­lich­keit besteht, auf die File­sys­te­me des Quell­sys­tems zuzugreifen.

Hier findest du weitere Posts zu den Themen Oracle Datenbank bzw. Mi­gra­tio­nen aus unserem News und Insights Bereich. 
icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook 
Twitter 
LinkedIn 
XING 
WhatsApp 
Email