create mobile friendly website
Oracle DB Migration auf 12c

Migration von Oracle-Datenbanken

Endlich auf 12c!

Im Juli 2013 gab Oracle die generelle Verfügbarkeit der Datenbankversion 12c bekannt. Heute,  zwei Jahre später, laufen immer noch viele produktive Datenbanken mit der Version 11 und die verantwortlichen Entscheider stehen mehr denn je vor der Frage: Welches ist die beste Methode, um meine Datenbank von Version 11 nach 12 zu migrieren? Denn eins ist sicher: Der erweiterte, kostenfreie Support für die Version 11.2.0.4 wird am 30. Januar 2016 enden. Deshalb gilt dieses Datum für viele als letztmöglicher Tag einer Migration nach 12c. Eine generelle Empfehlung - wie auch eine „beste“ Migrationsmethode - gibt es allerdings nicht. Jede Datenbank und somit auch ihre Migration ist individuell. Im folgenden Artikel betrachten wir die verschiedenen Migrationsmethoden etwas näher, die sich hinsichtlich Art, Migrationszeit und administrativem Aufwand deutlich unterscheiden.

Welche Vorteile bringt generell ein Upgrade auf 12c?

  • Die neuen Funktionalitäten dieser Version können genutzt werden.
  • Lösungen und Fixes für Bugs sind in der aktuellen Version enthalten.
  • Einsatz aktueller Software Releases ist i.d.R. vorteilhaft.
  • Unterstützung durch Oracle Support ist besser.

Ein Upgrade auf die Version 12 ist entweder direkt in einem Schritt von einer aktuellen Datenbankversion oder indirekt durch eine Migration möglich.
Direkte Upgrades auf 12c sind von den folgenden Oracle-Datenbankversionen möglich (siehe auch Abbildung 1):

  • 10.2.0.5
  • 11.1.0.7
  • 11.2.0.2 und höher

Alle anderen Datenbankversionen erfordern einen Zwischen­schritt, in dem zunächst eine Migration auf eine oben genannte Version erfolgen muss.

Folgende Upgrade-Methoden möchten wir im weiteren Verlauf dieses Artikels näher erläutern:

  • Upgrade auf der Kommandozeilenebene oder mit dem Database Upgrade Assistant (DBUA)
  • Full Transportable Export/Import
  • Traditioneller Export/Import exp/imp
  • Data Pump expdp/impdp
  • Upgrade mithilfe von Replikationsmechanismen
  • Upgrade mittels Rolling Upgrade (Data Guard)

Kommandozeilen-Upgrade oder DBUA?

Upgrades per Kommandozeile oder DBUA sind die schnellste Variante, um eine Datenbank auf eine neue Version zu aktualisieren. Die niedrigste Version der Quelldatenbank für solch ein Upgrade ist 10.2.0.5. Die beiden Upgrade-Varianten unterscheiden sich dahingehend, dass der DBUA eine grafische Oberfläche bietet, mit welcher der Upgrade-Prozess Schritt für Schritt durchgeführt werden kann. Beim Upgrade per Kommandozeile werden nach­einander die gleichen Skripte aufgerufen, die auch der DBUA implizit aufruft. Diese Variante ist etwas komplexer als das menügeführte Upgrade mit dem DBUA, da hier der Datenbankadministrator selbst für die richtige Reihenfolge und Abarbeitung der Skripte verantwortlich ist. Es eröffnet ihm aber die Möglichkeit, unabhängig von einer grafischen
Darstellung System-Upgrades durchzuführen.

Bei diesen beiden Varianten spricht man von einer In-Place-Migration, da für diesen Migrationsweg keine neue Datenbank erstellt oder kopiert werden muss. Das Upgrade wird direkt auf der Quelldatenbank durchgeführt.

Mit Version 12 hält das neue Kommandozeilenwerkzeug catctl.pl Einzug in den Upgrade-Prozess und ersetzt das bekannte Skript catupgrd.sql. Mit dem neuen
Werkzeug ist es möglich, den Upgrade-Prozess zu
parallelisieren, was ein schnelleres Upgrade ermöglicht und damit eine kürzere Ausfallzeit verursacht. Der voreingestellte Parallelitätsgrad entspricht der Anzahl der CPUs. Dieser Wert kann im DBUA oder innerhalb der Skripte individuell angepasst werden.

Eine weitere Verbesserung erfuhr der Upgrade-Prozess durch Einführung des Pre-Upgrade-Information-Werkzeuges preupgrd.sql, welches das bekannte Skript  utlu<nnn>i.sql ersetzt. Dieses Hilfsmittel ist in der Lage, die Pre-Upgrade-Checks entsprechend zu interpretieren und daraus pre/post-Upgrade-Skripte mit Lösungen für die aktuell gefundenen Probleme zu erstellen. Bisher war der DBA dafür selbst verantwortlich.

Sollte aus irgendeinem Grund der Upgrade-Prozess per DBUA abbrechen, kann dieser Prozess auf Kommandozeilenebene zu Ende geführt werden. Voraussetzung dafür ist, dass zwischenzeitlich kein Datenbank-Restore durchgeführt wurde.

Die beiden oben genannten Varianten erlauben allerdings keine Migration in einem Schritt von der vorhandenen Non-CDB-Quelldatenbank in eine 12c Pluggable-Datenbank. Sollte zukünftig die Multitenant-Architektur verwendet werden, so ist unter Umständen eine der nachfolgenden
Migrationsmethoden empfehlenswerter.

Full Transportable Export/Import

Transportable Tablespaces sind eine schnelle Methode, um ganze Tablespaces zwischen Datenbanken zu kopieren.
Schnell ist sie deshalb, weil die Datendateien der
Tablespaces physikalisch kopiert werden, ohne dass eine logische Interpretation der Daten selbst durchgeführt werden muss.

Die Methode Full Transportable Export/Import kombiniert und vereinfacht dies durch Nutzung der Funktionalität der Transportable Tablespace in Kombination mit einem Datapump Export. Dieser Export enthält alle notwendigen System-, User- und Applikationsmetadaten, die für die Datenbankmigration benötigt werden. Damit muss sich der Nutzer nicht mehr um das Übertragen der notwendigen Metadaten kümmern. Voraussetzung für die Nutzung dieser Methode ist die Version 11.2.0.3 oder höher der Quelldatenbank.

Folgende Schritte sind notwendig, um eine Datenbank mit dieser Methode auf die Version 12 zu migrieren:

  • Erstellen einer leeren Oracle 12c Datenbank als Non-CDB oder Pluggable-Datenbank
  • Exportieren der 11.2.0.3 (oder höher) Datenbank mit den folgenden Parametern:
    FULL=Y
    TRANSPORTABLE=ALWAYS
    VERSION=12
  • Kopieren der Datendateien in ihre korrekten Ziel­verzeichnisse. Wenn zwischen unterschiedlichen Plattformen gewechselt wird (Endian-Format), müssen die Datendateien vorher mit dem Befehl RMAN CONVERT oder DBMS_FILE_TRANSFER konvertiert werden.
  • Importieren in die 12c Datenbank mit den Parametern:
    FULL=Y TRANSPORT_DATAFILES=<DF001.DBF>,<DF003.DBF>,<DF003.DBF>,...

Da die neue Zieldatenbank auch eine Pluggable-Datenbank sein kann, ist es mit dieser Methode möglich, schnell und in einem Schritt von einer 11.2.0.3 (oder höher)
Non-CDB hin zu einer Pluggable-Datenbank zu migrieren.

Traditioneller Export/Import (exp/imp)

Seit der Oracle-Version 5 gibt es die beiden Export/Import
Utilities exp/imp zum Entladen/Beladen von Daten aus/in Datenbanken. Sie arbeiten als Client-Anwendung. Beim Entladen werden die Daten standardmäßig in eine sogenannte Dump-Datei im Dateisystem geschrieben. Unter
Zuhilfenahme von Pipes war es möglich, die Dump-
Datei beim Export zu komprimieren oder auch gleich wieder in eine andere Datenbank zu importieren. Mit der Veröffentlichung des Nachfolgewerkzeuges Datapump in Version 10.1 werden neue Funktionalitäten nur noch für
Datapump implementiert. Somit unterstützt der traditionelle Export/Import heute viele neue Datenbankerweiterungen nicht. Allerdings ist er die einzige Methode, um Daten aus
Datenbanken kleiner Version 10.1 in eine höhere Version zu migrieren.

Datapump (expdp/impdp)

Datapump wurde mit Oracle Database 10g Release 1 (10.1) eingeführt und ist nicht nur eine Erweiterung des traditionellen Exports/Imports. Es ist ein serverseitiges Werkzeug, das von Grund auf neu erstellt wurde. Datapump liest die Daten per Direct Path Data Access unter Umgehung des SQL-Layer direkt aus den Datenblöcken von der Festplatte und erreicht damit einen Geschwindigkeitsvorteil gegenüber den traditionellen Instrumenten. Datapump ist sehr flexibel und wird oft als Migrationsmethode auf neue Datenbankversionen eingesetzt. Nach­folgend werden einige Funktionen genannt, die Datapump zum Mittel der Wahl bei Migrationen machen könnten:

  • Durch Angabe eines Parallelitätsgrades werden mehrere parallele Datapump Export/Import Jobs gestartet, was die Gesamtzeit des Exports/Imports verkürzt.
  • Daten können über einen Datenbank-Link in einem Schritt exportiert/importiert werden (Parameter: NETWORK_LINK). Dabei wird keine Dump-Datei auf dem Server erstellt.
  • Die Transportable-Funktionalität wird unterstützt (Transportable Tablespaces / Full Transportable Export/Import).

Die obige Aufzählung der Datapump-Parameter ist nur eine Teilmenge der verfügbaren Methoden, verdeutlicht aber die Möglichkeiten von Datapump und die flexible Nutzbarkeit. Mit Datapump kann man schnell und sehr fein granular
Daten exportieren/importieren. Damit lassen sich die
Datapump-Funktionen expdp und impdp sehr gut für eine
Datenmigration auf eine neue Versionen einsetzen.

Upgrade mithilfe von Replikationsmechanismen

Replikationsmechanismen übertragen und speichern den Inhalt einer Datenbank oder Teile davon auf einem oder mehreren anderen Systemen.

Nachfolgend sollen die Tools Golden Gate, CDC
Infosphere und Shareplex betrachtet werden. Das hauseigene Produkt von Oracle, Streams, wurde 2009 mit der Übernahme des Unternehmens Golden Gate durch das gleichnamige Produkt ersetzt.

Die Funktions- und Arbeitsweisen der drei Werkzeuge sind ähnlich. Sie werden daher im Folgenden zusammengefasst und den vorherigen Migrationsmethoden gegenübergestellt. Replikationen können mehrdimensional erfolgen. Zur Vereinfachung betrachten wir hier eine Datenreplika­tion von einer Quell- auf eine Zieldatenbank.

Um die Replikation zu nutzen, müssen die Replikationswerkzeuge zunächst auf dem Quell- und Zielserver installiert werden. Anschließend muss eine Konfiguration angelegt werden, die beschreibt, welche Daten von der Quelle zum Ziel übertragen werden sollen.

Bevor die regelmäßige, automatische Datenübertragung von der Quell- zur Zieldatenbank erfolgen kann, müssen die Daten einmalig synchronisiert werden.

Nach dem Start der Replikationsprozesse gibt es auf der Quelldatenbank einen sogenannten Capture-Prozess, der aus den Online-Redolog-Dateien die Transaktionen für die Tabellen entsprechend der Konfiguration mitliest und in eine lokale Datei schreibt. Der Inhalt dieser Datei wird durch Replikationsprozesse in eine Datei auf dem Zielserver übertragen. Ein weiterer Replikationsprozess auf dem Zielsystem liest diese Datei aus, generiert das entsprechende SQL-Statement und wendet dieses gegen die Zieldatenbank an. Da dieser Datentransfer von Quell- zu
Zieldatenbank nahezu in Echtzeit erfolgt, sind die Daten auf beiden Systemen quasi immer identisch.

Wenn in unserem Beispiel die Zieldatenbank eine 12c Datenbank ist und die Quelldatenbank eine Version < 12
besitzt, so wird durch die Datenreplikation eine neue 12c Datenbank mit Daten der Quelldatenbank aufgebaut. Für ein Umschalten von der „alten“ Quelldatenbank auf die neue 12c Datenbank wäre nur ein Connect gegen die neue Datenbank nötig, was z.B. automatisch mit einem geänderten tnsnames.ora-Eintrag erreicht werden kann.

Im Vergleich zu allen vorher genannten Upgrade-Methoden ist die Umschaltzeit in diesem Beispiel von der alten auf die neue Version extrem kurz, im Idealfall gleich null und transparent für die Anwendungen. Deshalb spricht man bei
Upgrades mittels den Replikationsverfahren oftmals auch von Zero Downtime Database Upgrades. Nicht zu vergessen sind an dieser Stelle allerdings der erhöhte administrative Aufwand für das Managen der Replikationssoftware, die finanzielle Mehrbelastung durch den Erwerb der
Replikationslizenzen, wie auch der zusätzliche Platz und Ressourcenbedarf für die neue Zieldatenbank.

Upgrade mittels Rolling Upgrade (Data Guard)

Abschließend soll noch die Methode des Rolling Upgrade erwähnt werden. Mittlerweile gibt es hierfür zwei Varianten. Klassisch ist die bekannte Methode über einen Logical Data Guard. Neu ist mit Oracle 12c die Verwendung des Package dbms_rolling in Kombination mit Active Data Guard.

Migrationsplan

Nach der Evaluierung aller möglichen Migrationsmethoden
und den jeweiligen Anforderungen gilt es, die geeignete Migra­tionsmethode auszuwählen und einen Migrationsplan zu erarbeiten.

Folgende Punkte sollten dafür berücksichtigt werden:

  • Anforderungen evaluieren und mit allen betroffenen Teams abstimmen
  • bevorzugte Migrationsmethode definieren
  • Zeitfenster für die Tests/Migration bestimmen
  • Schnittstellen und beteiligte Komponenten analysieren
  • klären, ob zusätzlich zur Datenbankmigration Komponenten wie Server oder Storage geändert werden sollen
  • klären, ob zusätzlich zur Datenbankmigration das Layout oder Datenformat (Zeichensatz, Verschlüsselung, Partitionierungsmethode, Komprimierung, …) geändert werden soll
  • klären, ob die Datenbank in eine Pluggable-Datenbank überführt werden soll

Fazit

Oracle-Version 12 bietet eine Reihe von Verbesserungen und Automatismen für den Umstieg auf die neue Version.
Die hier genannten Migrationsmethoden unterscheiden sich hinsichtlich Aufwand, Komplexität, Downtime und Schnelligkeit. Um das Zusammenspiel aller Komponenten zu gewährleisten, erfordert jede Migration eine gründliche Planungs- und Testphase, bevor die migrierte Datenbank produktiv zum Einsatz kommt.

Bei der Vorbereitung, Analyse, Planung und Durchführung Ihrer Datenbankmigration nach Oracle 12c unterstützen wir Sie gerne.

Thomas Kitzmann
()

 

ORDIX aktuell

ORDIX sucht Nachwuchs auf der hobit 2017
Mit der hobit 2017 hat die ORDIX AG vom 24. bis 26.01.2017 das erste Mal an der Darmstädter Ausbildungsmesse teilgenomme...
Weiterlesen ...
Lesestoff zum Weihnachtsfest: ORDIX®   news 2/2016
​Die aktuelle ORDIX® news 2/2016 hält zum Ende des Jahres wieder interessante Artikel rund um die IT bereit. Ob Big Data...
Weiterlesen ...
ORDIX auf der DOAG Konferenz und beim Schulungstag
Gefüllte Zuhörerplätze bei unseren Vorträgen und höchste Teilnehmerzahlen beim Schulungstag zeugen vom Erfolg und der Be...
Weiterlesen ...

Kostenloses Kundenmagazin

Abbildungen

Die vollständigen Artikel mit allen Abbildungen finden Sie im blätterbaren PDF.
Eine Übersicht über alle Artikel sowie das PDF zum Download finden Sie im Inhaltsverzeichnis.

Impressum

Impressum der ORDIX® news 2/2015

Links

[1] ORDIX® news Artikel 4/2013
„Neuerungen in der Oracle Database 12c (Teil II): Multitenant-Architektur – eine Datenreise durch Raum und Zeit“
[2] Seminarempfehlung:
Oracle 12c Neuheiten

Quellen

[Q1] ORDIX® news Artikel 2/2011
„Oracle Golden Gate – Über eine Brücke musst du gehen!“
[Q2] ORDIX 12c Neuheiten, Seminar- unterlagen, Version 12.1 (15.04.15)
[Q3] Internet Webseite von Dell: Produkt Shareplex

Bildnachweis

© istockphoto.com | mikdam | goldfish jumping out of the water