Die Migration von Datenbanken in die Cloud eröffnet neue Möglichkeiten für Performance und Skalierbarkeit. Dieser Beitrag behandelt die Migration einer Oracle 19c Non-CDB-Datenbank in eine Container-Datenbank (CDB) in der Oracle Cloud Infrastructure (OCI). Der Prozess wird Schritt für Schritt im Oracle Enterprise Manager (OEM) unter Verwendung der Migration Workbench erläutert, wobei die wichtigsten Voraussetzungen, Konfigurationen und Validierungen im Fokus stehen. 

Migrationsmöglichkeiten

Grundsätzlich gibt es zwei Möglichkeiten, eine Oracle-Datenbank mithilfe der Migration Bench in die OCI zu migrieren:

• Data Pump

• Transportable Tablespaces (TTS)
  

Die Migration kann entweder in einer Multi-Phasen-Migration oder, bei kleineren Datenbanken, in einer Single-Phase-Migration durchgeführt werden:

• Multi-Phasen-Migration: Diese Methode wird häufig bei größeren Datenbanken eingesetzt. Die Abbildung 1 zeigt den Ablauf einer Multi-Phasen-TTS Migration von einer Quell-Datenbank zu einer Ziel-Datenbank. In mehreren Schritten werden Backups der Tablespaces und Metadaten erstellt und zur Ziel-Datenbank übertragen. Die Migration beginnt mit einem vollständigen Backup, gefolgt von inkrementellen Backups, die nur die seit dem letzten Backup erfolgten Änderungen enthalten. Während des letzten Schritts (Cutover-Phase) wird die Quell-Datenbank in den Read-Only-Modus versetzt, um die letzten inkrementellen Daten und ein Metadaten-Backup zu erstellen. Dies ist der einzige Zeitpunkt, an dem eine minimale Ausfallzeit für die Migration erforderlich ist. Anschließend werden die Daten in die Ziel-Datenbank, hier als Pluggable Database, migriert, und der Cutover-Prozess wird abgeschlossen.
  
• Single-Phase-Migration: Diese Methode eignet sich für kleinere Datenbanken. Hier wird ein einziges vollständiges Backup erstellt, und die gesamte Migration erfolgt in einem Schritt, ohne dass inkrementelle Backups notwendig sind. Dadurch ist der Prozess einfacher, aber es kann zu einer etwas längeren Ausfallzeit kommen, da die gesamte Datenbank in einem Schritt migriert wird. 

Voraussetzungen

• Eine der Voraussetzungen für die Migration ist, dass sowohl die Quell- als auch die Ziel-Datenbank im OEM sichtbar sein müssen. Dazu müssen die Management Agents auf beiden Datenbanken installiert und korrekt eingerichtet sein.
• Selbstverständlich wird eine Ziel-Datenbank in der OCI benötigt, die entweder eine Exadata, eine Autonomous Database oder ein Base Database Service (DBCS) sein kann. In unserem Fall wird die Quell-Datenbank in einer DBCS-Umgebung migriert.
• Automatic Storage Management (ASM) muss erstellt und konfiguriert werden, da es während der Migration für die effiziente Verwaltung und Verteilung der Datenbankdateien sorgt. Es optimiert die Leistung und stellt sicher, dass die Daten auf der Ziel-Datenbank korrekt und sicher gespeichert werden.
• Ein Wallet im Autologin-Modus für beide Datenbanken ist erforderlich und das Passwort muss bekannt sein, um es später eingeben zu können.
• Die Datenbanken müssen sich im Archivelog-Modus befinden.
• Die Zugangsdaten (Credentials) der Datenbanken müssen unter Setup → Sicherheit → Benannte Zugangsdaten hinterlegt werden.
• Während der Migration müssen sich die Tablespaces im Online-Modus befinden. Read-Only Tablespaces werden erst in der finalen Phase der Migration in den Read-Only-Modus versetzt, um die letzten inkrementellen Backups zu erstellen.

Der Migrationsprozess

Um den Migrationsprozess zu starten, meldet man sich in OEM an und wählt im oberen Menü Enterprise, dann Migration und Konsolidierung → Datenbank Migrationsworkbench aus. Dort kann man eine Migrationsaktivität starten und wird zu dem Fenster aus Abbildung 2 geführt. In diesem Fenster werden der Name der Migrationsaktivität und der Migrationstyp festgelegt, in diesem Fall die vollständige Datenbankmigration. Es können jedoch auch einzelne Schemata und Tablespaces migriert werden. Danach werden die Quell-Datenbank und die Ziel-Datenbank ausgewählt. Wenn man in eine Container-Datenbank migriert, wie es hier der Fall ist, besteht die Möglichkeit, eine neue PDB in dem jeweiligen Container zu erstellen, in die die Quell-Datenbank später migriert wird. 

Als nächstes werden die Informationen zu den Zugangsdaten und weiteren Einstellungen für die Migration festgelegt. Auf der linken Seite (siehe Abbildung 3) werden die Datenbank-Credentials und Host-Credentials für die Quell-Datenbank angegeben. Rechts daneben werden die notwendigen Credentials für die Ziel-Datenbank, einschließlich des ASM-Credentials, festgelegt. Außerdem werden das Source Work Directory und das Destination Work Directory definiert, also die Verzeichnisse, in denen die Migration durchgeführt wird. Zusätzlich müssen ein Destination Storage Directory sowie das Encryption Password für die Verschlüsselung der migrierten Daten angegeben werden. 

​Im nächsten Schritt werden die Migrationsdetails festgelegt (siehe Abbildung 4). Es werden die Tablespaces ausgewählt, die migriert werden sollen, wie in diesem Fall NIO_TABLESPACE und USERS. Zudem wird die Migrationsphase definiert, wobei zwischen der reinen Backup-Erstellung und der vollständigen Migration gewählt werden kann. Der Unterschied liegt darin, dass beim Backup nur eine Sicherung erstellt wird, während die vollständige Migration die Datenübertragung abschließt. Im Abschnitt Compare Performance besteht die Möglichkeit, die Datenbankleistung nach der Migration zu vergleichen, indem ein neues SQL Tuning Set (STS) erstellt oder ein bestehendes verwendet wird. Zusätzlich können benutzerdefinierte Skripte hochgeladen werden, falls während der Migration bestimmte Aktionen ausgeführt werden sollen.

Im letzten Schritt könnte die Migration sofort gestartet werden, jedoch ist es sinnvoll, zunächst eine Validierung aller wichtigen Parameter für die Migration durchzuführen. Genau dies wird in Abbildung 5 dargestellt. Insgesamt werden 22 Pre-Checks durchgeführt, um sicherzustellen, dass sowohl die Quell-Datenbank als auch die Ziel-Datenbank korrekt konfiguriert sind und die Migration reibungslos verlaufen kann. Da alle Checks erfolgreich bestanden wurden, ist die Umgebung nun bereit für die Migration. Nach Abschluss der Validierung kann die Migration durch Klicken auf die Schaltfläche Submit gestartet werden.  

Es ist möglich die Migration entweder sofort zu starten oder sie für einen späteren Zeitpunkt zu planen. Sobald die Migration gestartet wird, öffnet sich ein Fenster, in dem die einzelnen Schritte verfolgt werden können (siehe Abbildung 6), wie z. B. die Sicherung der Quelldatenbank, die Vorbereitung der Zieldatenbank etc. Zudem lässt sich sofort erkennen, an welcher Stelle ein Problem aufgetreten ist, falls dies der Fall sein sollte. Sobald alle Schritte ohne Fehler abgeschlossen sind, ist die Migration erfolgreich beendet.  

Fazit

Die Migration einer Oracle 19c Non-CDB-Datenbank in eine CDB in der OCI mithilfe der TTS-Methode und des Oracle Enterprise Managers stellt eine effiziente und zuverlässige Lösung dar, um komplexe Datenbankumgebungen in die Cloud zu übertragen. Durch den Einsatz von inkrementellen Backups und sorgfältigen Pre-Checks wird sichergestellt, dass die Datenbank konsistent bleibt und die Ausfallzeiten auf ein Minimum reduziert werden. Der Prozess von der Auswahl der Quell- und Ziel-Datenbanken bis zur abschließenden Validierung zeigt die umfassenden Möglichkeiten, die Oracle mit der Migration Workbench bietet. Mit der richtigen Vorbereitung und einem strukturierten Vorgehen kann die Migration reibungslos ablaufen und den Weg für eine erfolgreiche Nutzung der Cloud-Infrastruktur eröffnen.

Habt ihr Fragen zur Migration eurer Oracle-Datenbank in die OCI oder benötigt ihr Unterstützung bei der Umsetzung? Zögert nicht, euch bei uns zu melden – wir unterstützen euch gerne bei eurem Migrationsprojekt! 

Seminarempfehlung