Datenbank Migration · ASPICON Newsarchiv https://www.aspicon.de/news/tag/migration/ Database Technology and Service Wed, 21 May 2025 13:26:21 +0000 de hourly 1 https://wordpress.org/?v=7.0.4 https://www.aspicon.de/wp-content/uploads/2023/12/favicon_white_verlauf_2-50x50.png Datenbank Migration · ASPICON Newsarchiv https://www.aspicon.de/news/tag/migration/ 32 32 Near-Zero-Downtime-Migration mit Oracle GoldenGate https://www.aspicon.de/news/near-zero-downtime-migration-mit-oracle-goldengate/ Wed, 21 May 2025 12:58:02 +0000 https://www.aspicon.de/?p=24645 In diesem Beitrag tauchen wir gemeinsam in die Welt von Oracle GoldenGate ein. Wir zeigen dir, wie du lästige Downtimes auf ein absolutes Minimum reduzieren kannst.

Der Beitrag Near-Zero-Downtime-Migration mit Oracle GoldenGate erschien zuerst auf ASPICON.

]]>

Near-Zero-Downtime-Migration mit Oracle GoldenGate

Wenn du “Oracle Datenbank Migration” hörst, klingelt da bei dir auch direkt die Alarmglocke? Verständlich! Denn meistens sind diese Umzüge leider mit teuren, mehr oder weniger langen Ausfallzeiten für deine Anwendungen verbunden. Aber was, wenn wir dir sagen, dass es auch anders geht? In diesem Beitrag tauchen wir gemeinsam in die Welt von Oracle GoldenGate ein. Wir zeigen dir, wie du diese lästige Downtime auf ein absolutes Minimum reduzieren kannst.

Oracle - blk

Das erwartet dich in diesem Beitrag

Wieso dauern Migrationen überhaupt meist so lange?

Offlinewartungen an der Oracle Datenbank sind zuweilen nicht zu vermeiden. Sei es, weil veraltete Hardware getauscht, auf ein neues Release gewechselt oder eine Offlinewartung der Datenbank durchgeführt werden muss. Migrierst du auf Basis von RMAN-Backups und Archivelogs, kannst du diese Downtime relativ gering halten. Ein reiner Hardwareumzug ohne Wechsel des Releases oder Patchlevels lässt sich – unabhängig von der Datenbankgröße – in weniger als einer Stunde erledigen. Zumindest wenn er sauber geplant und vorbereitet ist. Aber bereits ein vermeintlich simpler Quartalspatch kann beim Timezoneupgrade zu langen Downtimes führen. Es gibt zahlreiche weitere Fälle, in denen ein schnelles Migrationsszenario nicht möglich ist oder aufwändige Nacharbeiten anfallen.

Einige typische Fälle dafür sind:

  • Das Timezoneupgrade, das im Zuge der Critical Patch Updates anfällt, wird aufgrund der hohen Menge an timezone-behafteten Daten sehr lang dauern.
  • Du willst den Zeichensatz einer Datenbank ändern.
  • Du willst Daten in großem Umfang in andere Tablespaces oder Schemata verschieben.
  • Strukturelle Änderungen am Datenmodell, wie zum Beispiel Änderung von Datentypen oder Entfernen von Spalten, betreffen große Datenmengen.
  • Ein Wechsel des Endianformats ist erforderlich, z.B. bei einer Migration von AIX oder HP-UX auf Linux. Dabei ist der Einsatz des Transportable Tablespace Feature möglicherweise nicht möglich, weil du keine Enterprise Edition lizenziert hast.
  • Die Datafiles oder Objekte sind sehr stark fragmentiert und du willst sie reorganisieren, möchtest aber nicht auf Redefiniton zurückgegreifen.

In vielen dieser genannten Fälle (und sicher einigen mehr) müsstest du wahrscheinlich auf DataPump als Migrationswerkzeug zurückgreifen. In jedem Fall könnten aber auch bei „in-place“-Änderungen Downtimes anstehen, die weit über dem betrieblich akzeptablen Maß liegen.

Die Krux an diesen Änderungen ist immer, dass die betroffene Datenbank während der gesamten Wartungszeit nicht oder nur eingeschränkt zur Verfügung steht. Ein Grund hierfür kann sein, dass die Datenbank für die Wartung in einem Modus betrieben werden muss, der keine Nutzerinteraktionen zulässt. Ein weiterer Grund ist, dass im Fall von Migrationen Änderungen auf der Quelldatenbank, die ab Migrationsstart anfallen, verloren wären, da sie nicht mehr auf das Zielsystem übertragen werden können.

Oracle GoldenGate: Der Datenpuffer während der Wartung

An dieser Stelle kommt Oracles Data Integration Tool „Oracle GoldenGate (OGG)“ ins Spiel. Eigentlich als Replikationstool konzipiert, kannst du es ebenso gut als Migrationswerkzeug nutzen und die Downtime – unabhängig vom Szenario und der Datenbankgröße – auf wenige Minuten drücken. Der Schlüssel hierbei ist, dass GoldenGate alle Änderungen, die auf einer Datenbank vorgenommen werden, abgreifen, in einem portablen Format zwischenspeichern und sie später auf einer anderen Datenbank nacharbeiten kann.

Die folgende Abbildung zeigt die logische Architektur von Oracle GoldenGate für das initiale Laden von Daten und für die Synchronisierung von DML- und DDL-Operationen. Dies ist die Grundkonfiguration. Je nach Anforderungen sind Variationen dieses Modells möglich.

Oracle GoldenGate Logical Architecture
Quelle: https://docs.oracle.com/goldengate/1212/gg-winux/GWUAD/wu_about_gg.htm#GWUAD110

Schritt für Schritt zur Oracle GoldenGate basierten Migration

Eine Möglichkeit, eine OGG-basierte Migration durchzuführen, wäre zum Beispiel die folgende:

  1. Erstelle eine leere Zieldatenbank mit den gewünschten Eigenschaften. Bezogen auf das oben genannte Beispiel “Timezoneupgrade” wäre das also: Eine leere Zieldatenbank mit der aktuellen Timezoneversion.

  2. Starte das OGG-Extract. Alle folgenden Änderungen an den Daten und der Struktur der Datenbank werden abgegriffen und zwischengespeichert.

  3. Übertrage die Quelldatenbank in die Zieldatenbank, z.B. per DataPump, in wenigen Anwendungsfällen auch per RMAN-Clone oder ‑Restore.

  4. Starte das OGG-Replicat, welches nun alle vom Beginn der Datenübertragung an auf der Quelldatenbank angefallenen Änderung auf der Zieldatenbank nacharbeitet.

  5. Sobald die zwischengespeicherten Änderungen komplett nachgearbeitet sind, sind Quell- und Zieldatenbank synchron. Jetzt – oder zu einem beliebigen späteren Zeitpunkt – erfolgt „nur“ noch die Umschaltung der Anwendung von der alten auf die neue Datenbank.

Warum Near-Zero-Downtime statt Zero-Downtime?

Abgesehen von der zwangsläufigen Downtime, die die Umschaltung der Anwendung an sich mit sich bringt, sind auf der Zieldatenbank noch einige kleinere Nacharbeiten erforderlich. Diese rühren daher, dass während einer laufenden Oracle GoldenGate-Replikation ausschließlich die Replikation selbst Änderungen auf der Zieldatenbank durchführen sollte, keine Usersessions und auch keine Businesslogic innerhalb der Datenbank. Das würde sonst sehr wahrscheinlich zu Replikationskonflikten führen, im schlimmsten Fall unbemerkt zu logischen Inkonsistenzen. Um selbiges zu vermeiden, werden in der Zieldatenbank bis zur Produktivsetzung im allgemeinen folgende Restriktionen durchgesetzt:

  • Der Parameter job_queue_processes=0 wird gesetzt.
  • Foreign Key Constraints mit „on delete cascade“ oder „on delete set null“ werden disabled.
  • Anwendungs-Trigger werden disabled.
  • Der Zugriff auf die Datenbank wird netzwerkseitig beschränkt auf den OGG-Replicat-Prozess, sei es durch Firewallregeln oder eine TCP.INVITED_NODES-Konfiguration am Listener.

Hinweis:
Replikationskonflikte sollten nach Möglichkeit vermieden werden, da sie zum Stoppen der Replikation führen und mindestens eine manuelle Intervention erfordern. Je nach Umfang der Konflikte kann auch eine komplette Neusynchronisation der Zieldatenbank erforderlich sein. Das ist zwar auch ohne Downtime möglich, kann aber womöglich einen bereits vereinbarten Migrationstermin gefährden.

Bevor die Datenbank für die Anwendung freigegeben werden kann, müssen diese Anpassungen erst wieder zurückgenommen werden. Der Aufwand dafür wird sich zwar im Bereich weniger Minuten bewegen, ehrlicherweise sind diese Arbeiten aber eben der Downtime zuzurechnen. Praktische Erfahrungen zeigen, dass das Stoppen, Umkonfigurieren und Starten der Anwendung(en) in der Regel aber länger dauert als die genannten Anpassungen.

Gibt es auch Nachteile von Oracle GoldenGate?

Wie so vieles im Leben hat auch Oracle GoldenGate eine Schattenseite: Die Lösung muss lizenziert werden, die Near-Zero-Downtime-Migration ist also nicht zum Nulltarif zu bekommen. Wird das Produkt jedoch nur zeitlich begrenzt für eine Migration eingesetzt, könnte eine Fixed-term-license zu einem attraktiven Preis infrage kommen. Auch erwähnenswert in dem Zusammenhang ist die kostenfreie Version » Oracle GoldenGate Free. Diese ist allerdings auf Datenbanken von maximal 20GB Größe limitiert, wird nicht mit Patches versorgt und nicht vom Oracle Support betreut. Sie ist somit, vergleichbar mit der Oracle Database Express Edition, eher für Test- und Ausbildungszwecke geeignet. Wende dich bei Lizenzfragen gern an die Experten von ASPICON.

Ein weiterer möglicher Nachteil: Eine Migration per GoldenGate ist in aller Regel komplexer als beispielsweise der simple Einsatz von RMAN, dem Character Set Migration Tool oder DataPump. Entsprechend können die Projektkosten höher ausfallen. Es empfiehlt sich also, die Kosten und den Aufwand für OGG mit den Kosten einer langen Downtime zu ver­glei­chen. Auch hierbei werden dir die Spezialisten von ASPICON gern mit einer fundierten technischen Beratung und einer realistischen Kosteneinschätzung unter die Arme greifen.

Fazit und Empfehlung

Sollten anstehende Migrationen von oder Wartungen an Oracle Datenbanken den Rahmen einer für das Unternehmen akzeptablen Downtime sprengen, kann Oracle GoldenGate ein attraktives Werkzeug für alternative Migrationswege sein. Die Stärke von Oracle GoldenGate ist, dass ein gewünschtes Zielsystem während laufendem Produktivbetrieb vorbereitet, mit Daten befüllt und mit der Produktivdatenbank synchronisiert werden kann. Die Umschaltung auf das neue System ist eine Angelegenheit von wenigen Minuten. Alle gewünschten Anpassungen sind dann bereits durchgeführt und es gehen keine Daten verloren.

Du bist dir unsicher, ob Oracle GoldenGate das richtige Werkzeug für dich ist oder benötigst weiterführende Infos zur Lizenzierung?
Wir sind gern für dich da!
Kontakt

Hier findest du weitere Infos aus der Welt von » Oracle aus unserem News und Insights Bereich.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

Der Beitrag Near-Zero-Downtime-Migration mit Oracle GoldenGate erschien zuerst auf ASPICON.

]]> Lokales Dumpfile mit DataPump via Database Link erzeugen https://www.aspicon.de/news/lokales-dumpfile-mit-datapump-via-database-link-erzeugen/ Fri, 21 Jan 2022 09:00:18 +0000 https://www.aspicon.de/?p=15949 Oracle DBA Tipp: über einen kleinen Kniff lassen sich auch mit DataPump Dumpfiles auf das lokale Filesystem exportieren.

Der Beitrag Lokales Dumpfile mit DataPump via Database Link erzeugen erschien zuerst auf ASPICON.

]]>

Lokales Dumpfile mit DataPump via Database Link erzeugen

Ein wesentliches Unterscheidungsmerkmal des längst abgekündigten 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 DatabaseLink nachbilden. Im folgenden Artikel wird das in Zusammenhang mit einem Kompatibilitätsproblem bei einem Upgrade von 10gR2 nach 19c genutzt.

DataPump via Database Link

Grundsätzlich ist ein DataPump-Export sowohl hinsichtlich Quell-/Zielversionen als auch Endianformaten keinen Einschränkungen unterworfen. Ein „Upgrade“ via Export/Import wird also technisch immer möglich sein. Problematisch kann das im konkreten Fall aber z.B. werden, wenn

  • auf dem Altsystem nicht mehr ausreichend Platz für die Exportfiles verfügbar ist,
  • das Neusystem keinen Zugriff auf die Filesysteme des Altsystems hat oder
  • kein administrativer 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) zurückzugreifen. An dieser Stelle kann man aber sehr wohl in Kompatibilitätsprobleme laufen. Grund hierfür sind allerdings nicht Einschränkungen des DataPump selbst, sondern die Tatsache, dass die Kommunikation über Database Link den Restriktionen der Client/Server Interoperability (Doc ID 207303.1) unterworfen ist.

So auch im vorliegenden 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 ausschließlich Net*8‑Zugriff auf einen Account im Altsystem mit EXP_FULL_DATABASE-Privileg möglich
  • 19c-Clients sind nicht für den Zugriff auf 10gR2-Server zertifiziert

Der ursprüngliche Versuch, die Daten per Database Link direkt zu importieren, scheiterte folglich auch aufgrund der Inkompatibilitä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 zusätzlich eine Client-/Server-kompatible Datenbank zu installieren und darüber einen Export in ein auf dem Neusystem abgelegtes Dumpfile durchzuführen. 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-kompatible Version und
  • von den 10gR2-kompatiblen auch die einzige für das Neusystem-OS (Oracle Enterprise Linux 8) freigegebene ist.
    Innerhalb dieser zusätzlichen Datenbank (hier mig genannt) wird ein public database link auf den Benutzer im Altsystem angelegt, der über das EXP_FULL_DATABASE-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 angelegten Database Link kann nun das 10gR2-Altsystem in ein Dumpfile auf dem Neusystem exportiert 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 Zieldatenbank importiert werden.

Fazit

Wenngleich etwas aufwändiger als mit dem abgekündigten exp-Tool ist das Erstellen eines lokalen Exportfiles auch mit DataPump weiterhin möglich. Der Aufwand ist allerdings nur gerechtfertigt, wenn keine Möglichkeit besteht, auf die Filesysteme des Quellsystems zuzugreifen.

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

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

Der Beitrag Lokales Dumpfile mit DataPump via Database Link erzeugen erschien zuerst auf ASPICON.

]]> End of Support für Oracle 18c Datenbank am 30.06.21 https://www.aspicon.de/news/end-of-support-fuer-oracle-18c-datenbank-am-300621/ Tue, 27 Apr 2021 15:00:36 +0000 https://www.aspicon.de/?p=12927 Der Support für die Oracle Datenbank Version 18c endet am 30.06.21, es gibt hierfür keinen Extended Support!

Der Beitrag End of Support für Oracle 18c Datenbank am 30.06.21 erschien zuerst auf ASPICON.

]]>

End of Support für Oracle 18c Datenbank am 30.06.21

Alle die aktuell noch ein Oracle Datenbank Release 18c einsetzen (also technisch 12.2.0.2) sollten auf dem Radar haben, dass der Oracle Premier Support am 30.06.2021 ausläuft. Für das Release 18c gibt es keinen Extended Support. Von daher sollten nun zeitnah eine Migration auf ein aktuelleres Release erfolgen.

Zwar gibt es inzwischen eine Oracle 21c, aber dieses sogenannte Innovation Release hat auch nur eine vergleichsweise kurze Supportlaufzeit. Von daher empfehlen wir nach wie vor eine Migration auf Oracle 19c. Für dieses Long-Term-Release gibt es ab 2024 dann auch Extended Support, so dass bis zum Final Patch am 30.04.2027 erstmal kein weiterer Migrationsstress besteht.

Eine komplette Übersicht zu den Supportlaufzeiten gibt es hier:
https://www.datenbank-lizenzen.com/oracle-support-laufzeiten/
Die Daten werden von uns stets zeitnah aktualisiert.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

Der Beitrag End of Support für Oracle 18c Datenbank am 30.06.21 erschien zuerst auf ASPICON.

]]> End of Support für 11.2.0.4 und 12.2.0.1 – Jetzt dringend handeln und nach 19c migrieren! https://www.aspicon.de/news/end-of-support-fuer-11-2-0-4-und-12-2-0-1-jetzt-dringend-handeln-und-nach-19c-migrieren/ Fri, 28 Feb 2020 14:15:00 +0000 https://www.aspicon.de/?p=7324 In diesem Jahr läuft der Support für die Datenbankversionen 11.2.0.4 und 12.2.0.1 aus. Im Rahmen der Migration nach 19c müssen mehrere Faktoren berücksichtigt werden!

Der Beitrag End of Support für 11.2.0.4 und 12.2.0.1 – Jetzt dringend handeln und nach 19c migrieren! erschien zuerst auf ASPICON.

]]>

End of Support für 11.2.0.4 und 12.2.0.1 – Jetzt dringend handeln und nach 19c migrieren!

Kunden, die zum aktuellen Zeitpunkt noch das Terminal Patch Set 11.2.0.4 der Datenbankversion 11gR2 oder das erste Patchset 12.2.0.1 der 12cR2 Familie im Einsatz haben, sollten jetzt dringend weiterlesen, denn:

  • der (Extended) Support für 11.2.0.4 endet am 31.12.2020,

  • der Premier Support für 12.2.0.1 endet am 20.11.2020, ein Extended Support ist nicht möglich.

Was bedeutet das konkret?

Ganz einfach: Plane kurzfristig eine Migration auf das aktuelle Datenbankrelease 19c!

Beachte jedoch, dass hier mehrere Faktoren berücksichtigt werden müssen. Dazu zählen u.a.:

  • Sofern du noch ein altes Betriebssystem im Einsatz hast, musst du hier ebenfalls ein Upgrade berücksichtigen. Die nachfolgenden Betriebssysteme sind für 19c NICHT zertifiziert:
    • Oracle Linux 6 und älter (OL6, OL5, …)
    • Oracle Solaris 10 und älter
    • Red Hat Enterprise Linux 6 und älter (RHEL6, RHEL5, …)
    • Microsoft Windows Server 2012 R1 und älter (2012 R1, 2008 R2, 2008, …)
    • IBM AIX 7.1 Technology Level 4 und älter

  • Prüfe in diesem Kontext, ob ein Hardware-Refresh – auch in Hinblick auf künftiges Wachstum oder erhöhte Anforderungen – sinnvoll ist.

  • Sofern lediglich die Freigabe für 12.2.0.1, nicht jedoch für 19c, seitens des Anwendungsherstellers erteilt wurde, informiere, dass es sich bei 19c um kein Major Release im eigentlichen Sinn handelt. Vielmehr ist die 19c das Terminal Release bzw. das Terminal Patch Set der 12c Release 2 Familie (12.2.0.3).Die Datenbankversionen 12.2.0.1, 18c (12.2.0.2) und 19c (12.2.0.3) sind dem Release 12cR2 untergeordnet. Analog dazu gehören die Minor Releases 11.2.0.1, 11.2.0.2, 11.2.0.3 und 11.2.0.4 zum 11gR2 Major Release.

  • Plane entsprechende Downtimes für die Migration deiner Datenbank(en) ein.

  • Prüfe, ob eine Anpassung der Oracle Lizenzierung – gerade bei einer Migration von 11.2.0.4 nach 19c – erforderlich ist.
    Besitzt du noch DB SE1 (Standard Edition One)  oder DB SE (Standard Edition) Lizenzen?
    Diese müssen im Rahmen einer technischen Migration in DB SE2 (Standard Edition Two) Lizenzen gewandelt werden. Bei Named User Plus Lizenzen ändert sich bei der Lizenzumstellung zusätzlich die Mindestlizenzierung!

  • Bedenke, dass Oracle RAC und RAC One Node in der Version 19c für Standard Edition Two NICHT mehr enthalten ist. Sofern du aktuell einen RAC auf DB SE oder DB SE2 Basis einsetzt, ist im Rahmen der Migration ein Umbau der Infrastruktur notwendig.
    -> hier geht’s zum entsprechenden Post dazu

  • Beachte, dass Oracle Fail Safe mit 19c deprecated ist und in einem der künftigen Datenbank Releases nicht mehr verfügbar sein wird. Sofern du deine Oracle Datenbanken auf Basis eines Windows Failover Clusters mit Oracle Fail Safe einsetzt, ist ein Umbau der Infrastruktur sinnvoll.

  • Ein gültiger Oracle Supportvertrag (Software Update License & Support) ist sowohl für die technische Migration Ihrer Datenbank(en) nach 19c als auch die Lizenzmigration von bestehenden DB SE/SE1 Lizenzen in DB SE2 zwingende Voraussetzung.

Die Datenbankversion 19c wird im Rahmen des Premier Supports bis 31.03.2023 unterstützt. Darüber hinaus kann ein kostenpflichtiger Extended Support bis 31.03.2026 gebucht werden.

Du brauchst jetzt Unterstützung?

Gern sind unsere Spezialisten sowohl bei der Planung und Umsetzung deiner Migrationsprojekte als auch bei der Prüfung deiner Oracle Lizenzsituation behilflich. Solltest du weitere Fragen haben oder Unterstützung bei der Konzeptionierung und Umsetzung benötigen, zögere nicht, dich gleich mit uns in Verbindung zu setzen.

icon-arrow_right_medium-violet-blue.svg

Share this article

Facebook
Twitter
LinkedIn
XING
WhatsApp
Email

Der Beitrag End of Support für 11.2.0.4 und 12.2.0.1 – Jetzt dringend handeln und nach 19c migrieren! erschien zuerst auf ASPICON.

]]>