Beiträge

Migrieren ohne Downtime - ein Oracle 12.2 Feature

Migration OHNE Downtime – ein cooles Oracle 12.2 New Feature

Mit der Release 2 der Oracle Datenbank 12c bekommt der DBA eine Vielfalt neuer Funktionalitäten, die dem Datenbankadministrator die Arbeit in Zukunft um einiges erleichtern werden. Eines dieser neuen Features ist das Hot Cloning und Relocate von Pluggable Databases, das in diesem Artikel kurz näher vorgestellt wird.

Die Oracle Datenbank 12c Release 2 bringt mit der Multitenant-Architektur viele tolle Features, die man vorher nicht benutzen konnte. Zuallererst sollten wir aber die Aussage des Artikeltitels ein wenig einschränken und erläutern, welcher Themenkreis in diesem Artikel beleuchtet wird.
Eine Migration ohne Downtime ist mehr ein Wunsch als Wirklichkeit, aber mit der Version 12.2 kommen wir dem Ziel näher. Im gegenständlichen Artikel werden wir über die Möglichkeit Pluggable Databases online zu kopieren/migrieren beschreiben.

Ein Blick in die Vergangenheit

In der Version 11.2 hatte der Datenbankadministrator folgende Möglichkeiten, um eine Datenbank von einem System auf ein anderes System zu migrieren:

  • Duplicate
  • Datapump
  • Restore/Recover via RMAN
  • GoldenGate

Welchen Weg man letztendlich wählen wird, hängt ganz von der Situation und den Voraussetzungen ab. Es geht hier nicht um Cross-Platform-Migrationen oder um Migrationen zwischen Systemen mit unterschiedlicher Endianness. Jede Option verlangt gewisse Vorbereitungen und birgt auch mögliche, verborgene Gefahren mit sich, die dann erst im Zuge der Migration sichtbar werden.

Variante „Duplicate“

Bei einem Duplicate hat der Benutzer die Möglichkeit entweder direkt über SQL*Net, oder aus einem vorhandenen Backup, eine Kopie der Datenbank zu erstellen. Die Duplicate Methode ist eigentlich die einfachste, weil man hier entweder nur Firewall Freischaltungen zwischen den Servern benötigt oder man alternativ auf ein Backup, meistens von einem NFS Share oder einer Bandsicherung, zugreift. Wenn zwischen den Servern ein leistungsstarkes Netzwerk zur Verfügung steht, dann führt man am besten den Befehl DUPLICATE TARGET DATABASE TO … FROM ACTIVE DATABASE aus oder benutzt Backups die entweder in einer BACKUP LOCATION gespeichert oder aus Bandsicherungen gezogen werden.  Oracle automatisiert dabei einige Tätigkeiten die man bei Restores sonst manuell machen muss. Grundsätzlich ist es ein automatischer Restore/Recover der Quelldatenbank mit Veränderungen der Datafile Pfade und der DBID.

Variate „Datapump“

Die Variante Datapump ermöglicht dem Datenbankadministrator logische Datenbankbackups zu erstellen, auf ein neues Ziel zu übertragen und dort wieder zu importieren. Datapump bietet auch Features wie Transportable Tablespace oder Full Transportable Export. Dabei werden nur Metadaten exportiert und diese dann mit allen Datafiles kopiert und am Ziel importiert.

Variante „klassische Migration“

Bei der klassischen Migration einer Datenbank mittels RMAN Restore/Recover wird eine Datenbank auf Basis eines Backups neu aufgebaut.

Variante „GoldenGate“

Als letzte Option bleibt GoldenGate. Bei GoldenGate handelt es sich um eine kostenpflichtige Replikationssoftware, die es erlaubt nahezu Zero Downtime Migrationen durchzuführen. GoldenGate unterstützt zudem auch noch andere Datenbankanbieter wie MySQL, MS SQL und Hadoop.

Multitenant Architektur

Mit der Version 12.1 hat Oracle eine neue Datenbankarchitektur eingeführt – die Multitenant Architektur (CDB Architektur). Die Multitenant Architektur wird in Zukunft die derzeitige Non-CDB Architektur ersetzen. In der 12.1 Dokumentation findet man bereits den entsprechenden Hinweis auf die „Deprecation of Non-CDB Architecture“ für kommende Oracle Releases nach 12.2. Oracle empfiehlt hier auf die CDB Architektur zu schwenken. Multitenant ist prinzipiell eine kostenpflichtige Option zur Enterprise Edition, jedoch als Single tenant in allen Oracle Editionen enthalten.

Container Datenbank

Während es vor 12.1 nur eine 1:1-Beziehung zwischen Instanz und Datenbank gab (beim RAC ist es eine n:1-Beziehung), verändert sich das jetzt mit der Multitenant Architektur. In der Multitenant Architektur werden alle gemeinsamen Systemobjekte in eine neue, zentrale, Datenbank – die Container Datenbank (CDB) – gepackt, die alle notwendigen Funktionalitäten bereits vorinstalliert hat. Die eigentlichen Benutzerdaten befinden sich in sogenannten Pluggable Databases (PDB), die in die Containerdatenbank eingehängt werden.

In der Version 12.1 konnte man Datenbanken, die bereits als Pluggable Database definiert waren wesentlich einfacher kopieren, als noch in älteren Versionen ohne Multitenant Architektur. Man musste die Quelldatenbank lediglich in den Read Only Modus setzen und anschließend ein CREATE PLUGGABLE DATABASE Statement ausführen. Im einfachsten Fall bekommt man mit dem Kommando CREATE PLUGGABLE DATABASE ORCL2 FROM ORCL1 bereits eine lokale Kopie der Datenbank.

Mit der Multitenant Architektur bringt Oracle dem Benutzer eine Vielfalt von Features die das Provisionieren von Datenbanken leichter machen. Man bekommt eine Konsolidierungsplattform für Datenbanken in der man mit dem Ressource Manager Systemressourcen optimal zuteilen kann um wichtigeren Datenbanken mehr Performance zuzusichern. Weiters eine Automationsplattform in der man Datenbank Templates vordefinieren kann um im Anlassfall schnell PDBs zu erstellen oder klonen zu können. Das Kopieren von PDBs geht in 12.1 nicht ganz ohne Downtime ab. Im Internet findet man Artikel die ohne den Read Only Modus eine Kopie der PDBs ermöglichen, in 12.1 ist es jedoch nicht möglich PDBs online zu kopieren. Die Quelldatenbank geht hier in den Quiesce Modus, was mit einer Downtime vergleichbar ist.

Die Gegenwart – Hot Cloning und Relocate

Mit der Version 12.2 wird der Traum des DBAs jedoch endlich wahr: Die von vielen erwartete Lösung für das online kopieren von PDBs. Dieses Feature kommt in Begleitung mit einem anderen neuen Feature, den Local Undo Tablespaces. Um Datenbanken wirklich online kopieren zu können, braucht man die Container Datenbank im Local Undo Mode (und natürlich im Archivelog Mode).
Das Aktivieren des Local Undo Modes in der CDB erstellt automatisch in jeder PDB einen eigenen Undo Tablespace, welcher wiederum Voraussetzung für Flashback, PDBPITR und Hot Cloning in der PDB ist.

Um den Leser nicht weiter auf die Folter zu spannen, schauen wir uns das RELOCATE-Feature in Aktion an. Hier wird die Datenbank automatisch auf eine andere Instanz transferiert und alle DMLs und DDLs bis zum Öffnen der Pluggable Datenbank werden automatisch im Hintergrund verarbeitet, um die Datenbank konsistent zu halten.

In unserem Szenario haben wir 2 virtuelle Maschinen, ora01 und ora02 mit  Version 12.2.0.1 Enterprise Edition installiert, die ora01 verwaltet die cdb1 und ora02 die cdb2.

Beide Datenbanken sind im gleichen Netz, als Storage benutzen wir ASM, das erleichtert auch die Namenskonvention für die Datafiles. Diese Funktionalität (mit und ohne RELOCATE) funktioniert auch in der 12.2 SE2.

Um keine Lizenzverletzung zu begehen, denken Sie daran, dass in einer CDB nur eine Benutzer PDB existieren darf. Mehrere Benutzer PDBs verlangen die Multitenant Option und damit Enterprise Edition.

 

sys@cdb1 SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 ORCL                           MOUNTED

sys@cdb1 SQL> alter pluggable database orcl open ;
Pluggable database altered.

sys@cdb2 SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO

Um die Datenbank auf die neue Maschine zu transferieren, sind ein paar Vorbereitungen nötig. Zuerst ist ein Common User anzulegen, der die notwendigen Privilegien bekommt. Ein in der Dokumentation offensichtlich entdeckter Fehler wird am Ende des Beispiels beschrieben.

sys@cdb1 SQL> create user c##dba identified by oracle container=all ;
User created.

sys@cdb1 SQL> grant create session, create pluggable database to c##dba container=all ;
Grant succeeded.

sys@cdb1 SQL> grant sysoper to c##dba container=all ;
Grant succeeded.

Um die PDB zu erreichen, brauchen wir einen Connect-Descriptor, der die Datenbank identifiziert. In unserem Beispiel werden wir den Alias CDB1 in der tnsnames.ora der CDB2 anlegen.

CDB1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ora01)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = cdb1)
    )
  )

Als vorletzte Voraussetzung brauchen wir einen Public Database Link von der CDB2 in die CDB1.

 

sys@cdb2 SQL> create public database link cdb1 
connect to c##dba identified by oracle using 'cdb1' ;
Database link created.

Nachdem wir alle Voraussetzungen erfüllt haben, können wir die Datenbank auf die CDB2 migrieren. Diese Tätigkeit erledigt man mit einem Kommando auf der CDB2:

sys@cdb2 SQL> create pluggable database orcl from orcl@cdb1 relocate ;
Pluggable database created.

Nach dem Erstellen der PDB bleibt die neue PDB in der CDB2 im Zustand MOUNTED. Ohne den Zusatz RELOCATE würden wir einen Hot Clone der PDB „orcl“ erstellen. Um die Near Zero Downtime Migration zu zeigen, erstellen wir in der PDB „orcl“ auf CDB1, die immer noch im Read Write Modus ist, einen neuen Benutzer und eine Tabelle.

sys@cdb1 SQL> alter session set container=orcl ;
Session altered.

sys@cdb1 SQL> create tablespace data ;
Tablespace created.

sys@cdb1 SQL> create user psorger identified by oracle default tablespace data quota unlimited on data;
User created.

sys@cdb1 SQL> grant connect, resource to psorger ;
Grant succeeded.

sys@cdb1 SQL> create table PSORGER.EMP as select level id from dual connect by level<=10 ;
Table created.

Nachdem wir die Tabelle erstellt haben, können wir die neue PDB in der CDB2 öffnen.
Mit dem folgenden Kommando wird die PDB auf CDB1 gelöscht und die PDB auf CDB2 im Read Write Modus geöffnet.

sys@cdb2 SQL> alter pluggable database orcl open ;
 Pluggable database altered.

sys@cdb2 SQL> alter session set container=orcl ;
 Session altered.

sys@cdb2 SQL> select count(*) from psorger.emp ;

COUNT(*)
 ----------
 10

Nach dem Öffnen der neuen PDB sehen wir, dass alle DML/DDL Statements erfolgreich übertragen wurden.

Um den Fehler in der Dokumentation zu beschreiben werden wir dem C##DBA die Rolle SYSOPER entziehen und SYSDBA vergeben. Mit dieser Rolle vergibt man eigentlich Superprivilegien und logischerweise erwarten wir, dass das funktioniert.

sys@cdb1 SQL> revoke sysoper from C##DBA container=all ;
Revoke succeeded.

sys@cdb1 SQL> grant sysdba to C##DBA container=all ;
Grant succeeded.

sys@cdb2 SQL> select sysdate from dual@cdb1 ;

SYSDATE
---------
09-MAY-17

sys@cdb2 SQL> create pluggable database orcl from orcl@cdb1 ;
Pluggable database created.

sys@cdb2 SQL> create pluggable database orcl1 from orcl@cdb1 relocate ;
create pluggable database orcl1 from orcl@cdb1 relocate
*
ERROR at line 1:
ORA-17628: Oracle error 1031 returned by remote Oracle server
ORA-01031: insufficient privileges

Wie wir hier sehen ist ein Online Clone der Datenbank möglich, aber beim Relocate bekommt der C##DBA mit SYSDBA Privilegien dennoch einen insufficient Privileges Fehler.
Es scheint, dass man dieses Verhalten als einen Bug entweder in der Dokumentation oder in der Software bezeichnen kann.
In der Zukunft werden wir es bestimmt erfahren. 🙂

Um diesen Artikel abzurunden, möchte ich noch die neuen Features der Oracle Public Cloud erwähnen.

Ein neues Feature, der direkte SQL*Net Zugang in die Cloud, erleichtert ab 12.2 die Migration von On-Premise Datenbanken in die Cloud und zurück. Mit diesen zwei neuen Features bekommt der Benutzer die Möglichkeit sehr einfach in die Cloud zu wechseln, dort etwa Performance-Tests durchzuführen und dann die Datenbank wieder zurück ins eigene Rechenzentrum zu verschieben.

Gerade das ist ein Feature, das bei anderen Cloud-Anbietern aktuell kaum zu finden ist!

Ablöse Oracle Warehouse Builder OWB durch Oracle Data Integrator ODI

Ab der Oracle 12c R2 ist der Betrieb vom Oracle Warehouse Builder (OWB) nicht mehr lizenziert.

Das von Oracle verlautbarte Statement of Direction lautet: Future database releases beyond Oracle Database 12c Release 1 will not be certified with OWB 11.2. Oracle Warehouse Builder“

Für die Oracle 12c R1 EE Datenbank endet der Premier Support mit Juli 2018, sodass der zertifizierte Betrieb des OWB noch bis Mitte 2018 gesichert ist.

Aus strategischen Überlegungen ist jetzt der richtige Zeitpunkt um den Umstieg ohne Zeitdruck zu planen und Migrationsprojekte rechtzeitig auf Schiene zu bringen.

Oracle Warehouse Builder OWB

Ansicht Oracle Warehouse Builder OWB

Für die Migration sind folgende Szenarien möglich:

  • Oracle Data Integrator
  • Custom PL/SQL
  • Open Source ETL Tools
  • 3rd Party ETL Tools

Die Vorteile und Nachteile der einzelen Szenarien im Detail:

Migration via Oracle Data Integrator ODI

Vorteile:

  • Ein Migrationstool ist im OWB im letzten Patchset für 11.2.0.3 und 11.2.0.4 enthalten und migriert einen Großteil der Mappings vom OWB zu ODI
  • Seit Version 12c ist der flowbasierte Ansatz der Modellierungsweise dem OWB sehr ähnlich
  • Durch das Knowledge Module System (ähnlich einem Plug-in) ist der ODI sehr erweiterbar
  • Eine große Menge an vorgefertigten Knowledge Modules ist bereits vorhanden (uA. auch ein Knowledge Modul für Big Data )
  • Set Based Ansatz mit Nutzung aller Features von Oracle Datenbanken
  • Metamodellbasierender Ansatz
  • Standard Datenqualitätsprüfung integriert

Nachteile:

  • Für den Oracle Data Ingegrator fallen Lizenzkosten kann
  • Eine 100% Migration ohne manuellen Zusatzaufwand ist nicht möglich
  • Der ODI ist ein neues Tool mit entsprechendem Lernaufwand

 Ansicht des Oracle Data Integrator ODI

Ansicht Oracle Data Integrator ODI

Migration via Custom PL/SQL

Vorteile:

  • Alle notwendigen SQL Statements sind aus dem OWB Mappings extrahierbar
  • Set Based Ansatz mit Nutzung aller Features von Oracle Datenbanken möglich
  • Vorhandenes Knowhow der Mitarbeiter nutzbar
  • Unabhängigkeit von ETL Tools

Nachteile:

  • Kein metamodellbasierender Ansatz
  • ETL Gerüst muss selbst entwickelt werden
  • Erweiterbarkeit ist sehr aufwendig (z.B. Richtung Big Data oder anderen Quellen)
  • Große Abhängigkeit von Oracle Datenbank

 

Migration via Open Source ETL Tools

Vorteile:

  • Keine Lizenzkosten (Achtung: viele Open Source Tools sind in der Community Version in der Funktion sehr stark eingeschränkt)
  • Unabhängigkeit von Oracle
  • Metamodellbasierender Ansatz

Nachteile:

  • Set Based Verarbeitung oft nur mit Tricks anwendbar und viele Features  wie zB. Lineage sind nicht verwendbar
  • Eventuell ist ein starker Middleware Server zusätzlich zu den Datenbankservern notwendig
  • Neues Tool mit entsprechendem Lernaufwand
  • Enterprise Version von Open Source ETL Tools sind meistens mit Lizenzkosten verbunden

Migration mit 3rd Party ETL Tools

Vorteile:

  • Unabhängigkeit von Oracle
  • Metamodellbasierender Ansatz

Nachteile:

  • In der Regel hohe Lizenzkosten
  • Oft starke Middleware Server zusätzlich zu den Datenbankservern notwendig
  • Neues Tool mit entsprechendem Lernaufwand

Lizenzierung des Oracle Data Integrator ODI

  • Lizenzprozessor: Corefaktor (=0,5 bei Intel) * Anzahl der Cores des Servers der Datenbank, auf der Transformationsprozesse laufen.
  • CPU-Lizenzierung: es müssen nur die Lizenzprozessoren der Datenbank lizenziert werden, auf der die Transformationsprozesse laufen.
    D.h. wenn die Extraktionsprozesse die Daten 1:1 von der Quelle ins Ziel verschieben, muss die Quelle nicht lizenziert werden und es muss nur der Server der DWH-Datenbank betrachtet werden.
  • NUP-Lizenzierung: mindestens 25 User pro Lizenzprozessor; als Benutzer zählen diejenigen, die Transaktionsprozesse starten oder darauf zugreifen (d.h. sicher weit unter 25).

Gegenüberstellung der Migrations Varianten

  3rd Party Open Source ODI Custom PL/SQL
Metadatengetrieben Ja Ja Ja  
Erweiterbarkeit ? ? Ja  
Datenqualitätsprüfung ? ? Ja  
Skalierbarkeit ? ? Ja  
Investitionssicherheit Ja ? Ja  
Big Data Ready ? ? Ja  
Lizenzkostenfrei   Ja   Ja
Kosten SE1 vs SE2 Oracle Datenbank Lizenzen

Sparen Sie bis zu 66 Prozent bei der Oracle DB Lizenzierung

Oracle Standard Edition One (SE1) Datenbank Lizenzen können so wie SE Lizenzen EINS zu EINS auf SE2 Lizenzen migriert werden! Sie sparen daher beim Kauf von SE1 Prozessor Lizenzen und der späteren Migration auf SE2 circa 66 Prozent der Lizenzkosten, welche beim Kauf von SE Lizenzen bzw. bei neuen SE2 Lizenzen anfallen würden.

Bei der Migration von SE1 auf SE2 erhöhen sich die laufenden Supportkosten um lediglich 20% gegenüber den ursprünglichen SE1 Support Kosten. Sie können also auch bei den laufenden Kosten jetzt noch ein sehr hohes Einsparungspotential erzielen.

Lizenzmigration SE1 auf SE2

  • SE1 auf SE2 ist eine 1:1 Migration (genauso wie SE auf SE2 auch eine 1:1 Migration ist)
  • Es fallen keine Kosten für die Lizenzmigration an
  • Der laufende Support für die zu migrierenden SE1 Lizenzen erhöht sich um 20%
  • Neuer Vertrag mit Anerkennung der SE2 Lizenzregeln ist notwendig

Bei der Migration von SE1 zu SE2 ist zu beachten:

  • Neue Minima Regelung 10 NUP / Server
  • eventuell NUP Nachkauf zur Einhaltung der Minima notwendig

Wichtiger Tipp:

Nur noch bis zum 30.11.2015 kann man SE und SE1 Lizenzen kaufen!

  • Jetzt noch SE1 Lizenzen kaufen, wenn man in naher Zukunft SE2 Lizenzen braucht => 66% Kostenersparnis
  • SE1 Kunden sollten Ihre Lizenz Minimas noch vor dem 30.11 für SE2 richtig stellen
  • Jetzt noch SE kaufen macht keinen Sinn mehr

 

Kontaktieren Sie uns jetzt, wir informieren Sie gerne über alle weiteren Details.

 

 

Oracle 12c - Profitieren durch migrieren

Business Breakfast Oracle 12c: Profitieren durch migrieren

Mitte Oktober fand wieder unsere schon traditionelle Herbst Business Breakfast Veranstaltung quer durch Österreich statt. Diesmal unter dem Titel „Oracle 12c. Profitieren durch migrieren. So geht´s“.

Der breite Bogen der spannenden Vortragsthemen stieß auf so großes Interesse,  dass sowohl in Bregenz, Salzburg, Linz als auch in Wien die Auslastungsgrenze der Seminarräume erreicht wurde.

Ein Umstand, der uns natürlich sehr freut!

Nur in Innsbruck hätte die Location noch ein paar zusätzliche Teilnehmer erlaubt. Wir arbeiten daran, dass wir auch in Tirol in Zukunft noch mehr Gäste begrüßen können 😉

 

Business Breakfast Oracle 12c Profitieren durch migrieren

 

Die Vorträge

Im ersten Vortrag wurden die neuen Features der aktuellen Oracle 12.1.0.2 Release vorgestellt. Als Beta Tester konnte DBConcepts schon viele Erfahrungen bei diversen Migrationsprojekten sammeln und über viele spannende Details berichten. Weitere Themen der Veranstaltung waren:

  • Welche Überlegungen für eine Migration wichtig und richtig sind und was das Ende des Oracle Premier Support für Oracle 11g bedeutet.
  • Welche Basis Funktionalitäten der Datenbank in zukünftigen Releases nicht mehr enthalten sind und welche anderen Möglichkeiten sich dazu ergeben.
  • Welche neuen Features in der neuen Oracle 12c Release inkludiert sind und wie man davon ohne zusätzliche Lizenzkosten profitieren kann.
  • Bei welchen Szenarien und Voraussetzungen „Database as a Service“ und „Private Cloud“ wirklich Sinn machen.
  • Ob die neue In-Memory Option der 12c Enterprise Edition die hoch gesteckten Erwartungen erfüllen kann.

Im Anschluss an diesen Vortrag wurde über lizenztechnische Änderungen im Umfeld des Oracle Enterprise Managers und über diverse Ankündigungen hinsichtlich nicht mehr unterstützter Funktionalitäten in zukünftigen Releases berichtet.

Der Vortrag zum Thema Oracle Lizenzierung konnte den Teilnehmern einen Überblick über die wichtigsten Änderungen und Stolpersteine im Umfeld der Oracle Lizenzierung mit der Oracle 12c Datenbank bieten, sowie Informationen und aktuelle Neuigkeiten zum Thema Oracle in VMware >=5.1 Cluster Umgebungen.

Nach einer kurzen Pause mit entsprechender Stärkung wurde SharePlex als eine Datenreplikationslösung für Oracle Datenbanken vorgestellt.

Eine Lösung, die sich besonders durch folgende Merkmale auszeichnet:

  • Leistungsfähigkeit. SharePlex ist für hohe Transaktionslast und geringe Latenzzeit ausgelegt.
  • Zuverlässigkeit. SharePlex vergleicht die zu ändernden Daten auf der Zielseite vor Ausführung der Datenänderung und alarmiert bei Out-of-sync-Situationen. Das patentierte Compare-Repair-Verfahren, das ohne Zusatzkosten im Produkt enthalten ist, ermöglicht die Behebung von Synchronisationsfehlern, ohne dass der gesamte Datenbestand erneut aufgesetzt werden muss.
  • Einfache Installation und Bedienung. SharePlex lässt sich in wenigen Minuten installieren, und die Konfiguration der zu replizierenden Objekte ist extrem einfach und flexibel.
  • Flexibilität. SharePlex kann sowohl für Oracle Enterprise Edition als auch Standard Edition verwendet werden. Darüber hinaus werden alle aktuellen Oracle-Versionen unterstützt, und die Replikation ist möglich zwischen verschiedenen Versionen.
  • Günstiger Preis. Nicht nur der grundsätzliche Preisunterschied zu anderen Lösungen macht sich deutlich bemerkbar. Für Oracle SE gilt ein geringerer Preis als EE, und darüber hinaus kann SharePlex für Migrationsprojekt für einen begrenzten Zeitraum lizensiert werden.

Im letzten Vortag wurde der Themenbogen mit aktuellen Informationen zu Oracle Hardware Lösungen abgerundet. Anhand einiger Beispiel konnte aufgezeigt werden, wie die Migration auf Oracle 12c Datenbank mit Einsatz von Oracle Hardware reibungsfrei durchgeführt wird und gleichzeitig Optimierungen bei den Lizenzkosten erzielt werden können.