9 Minuten Lesezeit (1899 Worte)

Physische Online-Migration einer Oracle-Datenbank in die OCI mithilfe von Zero Downtime Migration

Donnerstag, 22. August 2024

Die Migration einer Oracle-Datenbank in die Oracle Cloud Infrastructure ist eine komplexe Herausforderung, die sorgfältige Planung und präzises Vorgehen erfordert. In diesem Blogbeitrag wird anhand von grafischen Darstellungen erläutert, wie eine physische Online-Migration mit Zero Downtime Migration durchgeführt wird, ohne die Verfügbarkeit der Datenbank zu gefährden. Anschließend wird der Befehl zur Datenbankmigration vorgestellt und dessen Funktionsweise erklärt.

Die Abbildung 1 zeigt die ersten Schritte, die zu Beginn des Migrationsprozesses stattfinden. Es wird davon ausgegangen, dass die Quelldatenbank die primäre Datenbank ist, auf die die Nutzeranwendungen zugreifen. Diese Datenbank wird auf einem lokalen Server im Rechenzentrum des Kunden betrieben. Die Zieldatenbank hingegen wird in der Cloud-Umgebung von Oracle gehostet und als OCI-Zieldatenbank-Service bezeichnet.

Ein wichtiger Schritt im Rahmen dieser Migration ist das Herunterladen und Installieren des ZDM-Tools auf einem Host-System. An dieser Stelle ist es wichtig, bestimmte Voraussetzungen zu beachten:

Es wird dringend empfohlen, für die Installation der ZDM-Software einen separaten Host zu verwenden.
Dieser Host muss mindestens über 100 GB freien Speicherplatz verfügen.
Es muss eine Verbindung zum Quell- und Zieldatenbank-Server gewährleistet sein.
Der Host für den Zero Downtime Migration Service lässt sich ausschließlich auf den folgenden Betriebssystemen konfigurieren: Oracle Linux 7 (x86-64), Oracle Linux 8 (64-Bit) auf x86-64 und Red Hat Enterprise Linux 8 (64-Bit) auf x86-64.

Wie in Abbildung 1 zu sehen ist, ist ZDM im Kunden-Rechenzentrum installiert. Bei Aktivierung von ZDM zur Durchführung der Datenbankmigration werden Verbindungen über SSH zur Quell- und Zieldatenbank sowie zur Backup-Location über HTTPS hergestellt. ZDM nutzt RMAN, um Backups der Quelldatenbank zu erstellen, welche anschließend über HTTPS-Protokolle zum Object Storage in der OCI übertragen werden. Für physische Online-Migrationen muss auch eine SQL*Net-Verbindung zwischen der Quell- und Zieldatenbank bestehen, die über SCAN oder SSH eingerichtet wird. In dieser Abbildung wurde die Verbindung über VPN oder FastConnect nicht grafisch dargestellt, um die Übersichtlichkeit nicht zu mindern. Dennoch besteht eine sichere Verbindung zwischen dem Kunden-Rechenzentrum und der OCI über VPN oder FastConnect

Abbildung 1: Physische Online-Migration: Initiale Einrichtung und Sicherung der Quell-Datenbank

Die Abbildung 2 präsentiert die nachfolgende Phase der physischen Online-Migration. Nachdem die Backups der Quelldatenbank erstellt wurden, werden die übertragenen RMAN-Backups von ZDM genutzt, um eine Standby-Datenbank in der OCI zu erstellen. Diese ist TDE aktiviert, wodurch sichergestellt wird, dass die Daten während des Transfers und in der Cloud verschlüsselt bleiben. Die RMAN Backups werden aus dem Object Storage wiederhergestellt und zur Initialisierung der Standby-Datenbank verwendet. Die initialisierte Standby-Datenbank ist zunächst nicht synchron mit der Quelldatenbank, da sie auf Basis der erstellten Backups initialisiert wurde. Es besteht keine direkte Verbindung zwischen der Primärdatenbank und der Standby-Datenbank, was bedeutet, dass sie asynchron sind und erst nachträglich synchronisiert werden müssen. Die Synchronisation der Primär- und Standby-Datenbanken, die durch ZDM durchgeführt wird, erfolgt mithilfe von Oracle Data Guard. Data Guard sorgt dafür, dass jede Änderung an der Primärdatenbank in Echtzeit oder nahezu in Echtzeit auch auf die Standby-Datenbank angewendet wird.

Abbildung 2: Physische Online-Migration: Einrichtung und Synchronisation der Standby-Datenbank

Der Migrationsprozess durchläuft verschiedene Phasen, beginnend mit der Durchführung von Vorüberprüfungen auf der Quell- und Zieldatenbank und abschließend mit der Durchführung der Aufräumarbeiten nach der Migration auf der Quell- und Zieldatenbank.

Nach der Einrichtung der Zero-Downtime-Migrationsmodule auf dem Zielserver ist es jederzeit möglich, die Migration anzuhalten. Bei einer physischen Online-Migration wird empfohlen, die Migration nach der Phase ZDM_CONFIGURE_DG_SRC zu pausieren. Nach Abschluss dieser Phase wird eine Standby-Datenbank auf dem Zielsystem erstellt und die Synchronisation zwischen Quell- und Zieldatenbank erfolgt. Während die Migration pausiert ist, besteht die Möglichkeit, ein Failover zur Cloud-Datenbank durchzuführen, ohne Änderungen an der On-Premises-Datenbank vorzunehmen.

Dies ermöglicht das Testen der neuen Umgebung und das Sicherstellen, dass die Zieldatenbank ordnungsgemäß funktioniert, bevor der endgültige Switchover durchgeführt wird. Des Weiteren besteht die Möglichkeit, während dieser Zeit ein Anwendungsswitchover zur Cloud durchzuführen. Dies impliziert, dass die Anwendung zur Nutzung der neuen Zieldatenbank in der Cloud umgeschaltet wird, während die Migration temporär ausgesetzt ist. Dadurch wird ein reibungsloser Übergang gewährleistet, ohne dass die Anwendung eine längere Ausfallzeit erfährt.

In der finalen Phase der physischen Online-Migration, wie in Abbildung 3 dargestellt, erfolgt der Switchover und der Rollentausch der Datenbanken. Im Rahmen des Switchovers erfolgt eine Umschaltung der Anwendung zur Zieldatenbank in der OCI durch ZDM. Simultan findet ein Rollenwechsel der Primär- und Standby-Datenbanken statt: Die Standby-Datenbank in OCI übernimmt die Funktion der neuen Primärdatenbank, während die ursprüngliche Primärdatenbank zur Standby-Datenbank wird. Dies gewährleistet, dass die Datenbankmigration erfolgreich abgeschlossen ist und die Anwendungen ohne Unterbrechung mit der neuen Primärdatenbank arbeiten können.

Abbildung 3: Physische Online-Migration: Endgültiger Wechsel und Aktivierung der Ziel-Datenbank

Im Normalfall übernimmt somit ZDM das Switchover. Alternativ besteht die Möglichkeit, dass ZDM den Oracle Data Guard Broker einsetzt, um das Switchover zu verwalten. Damit der Broker das Switchover verwaltet, muss eine bidirektionale Netzwerkverbindung über SQLNet zwischen den beteiligten Datenbanken vorhanden sein. Zudem ist zu beachten, dass Broker-Konfigurationen nicht für Oracle Database 11.2.0.4 unterstützt werden.

Nach dem Rollentausch führt ZDM Nach-Migrations-Validierungen durch. Diese Validierungen umfassen die Überprüfung der Zieldatenbank, das Abschließen der Data Guard-Konfiguration, das Ausführen von Datapatch und die Überprüfung der erfolgreichen Migration.

Sowohl die physische Online-Migration als auch andere Migrationsmethoden erfordern eine Vorbereitung der Quell- und Zieldatenbank für die Migration. Die Datenbanken müssen verschiedene Voraussetzungen erfüllen, damit eine Migration überhaupt realisierbar ist. Welche Voraussetzungen erfüllt sein müssen und wie man die Systeme am besten für die physische Online-Migration vorbereitet, ist auf der Oracle-Dokumentationsseite zu finden.

Wenn die Quell- und Zieldatenbanken vorbereitet sind, alle Voraussetzungen für die Migration erfüllen und der ZDM-Host korrekt konfiguriert und aktiv ist, kann die Datenbankmigration gestartet werden. Der folgende Befehl führt zunächst eine Evaluierung der Datenbankmigration durch, bei der die Quelldatenbank ORCL von zdm-sourcecdb auf den Zielknoten zdm-target-db migriert wird. Dabei wird überprüft, ob alle notwendigen Authentifizierungen, Schlüssel, sudo-Befehle und Verzeichnisse korrekt eingerichtet sind. Die tatsächliche Migration wird nicht durchgeführt, sondern nur die Konfigurationsschritte evaluiert, um sicherzustellen, dass alles bereit ist. Die Ausgabe zeigt, dass alle Pre-Check-Schritte mit dem Status PRECHECK_PASSED erfolgreich bestanden wurden, was bestätigt, dass die Umgebung bereit für die Migration ist.

[zdmuser@zdm-host ~]$ $ZDM_HOME/bin/zdmcli migrate database -sourcesid ORCL -sourcenode zdm-sourcedb -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/ssh-key-2024-06-03.key -srcarg3 sudo_location:/usr/bin/sudo -targetnode zdm-target-db -backupuser "iatco.mihaela04@gmail.com" -rsp /home/zdmuser/physical_online.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/ssh-key-2024-06-03.key -tgtarg3 sudo_location:/usr/bin/sudo -targethome /u01/app/oracle/product/19.0.0.0/dbhome_1 \-eval 

zdm-host.sub06031222070.zdmvcn.oraclevcn.com: Audit ID: 299 
Enter source database ORCL SYS password: 
Enter user "iatco.mihaela04@gmail.com" password: 
zdm-host: 2024-06-13T09:33:59.216Z : Processing response file ... 
Operation "zdmcli migrate database" scheduled with the job ID "31". 
[zdmuser@zdm-host ~]$ $ZDM_HOME/bin/zdmcli query job -jobid 31 
Current status: SUCCEEDED 
Result file path: "/home/zdmuser/zdmbase/chkbase/scheduled/job-31-2024-06-13-09:34:11.log" 
Metrics file path: "/home/zdmuser/zdmbase/chkbase/scheduled/job-31-2024-06-13-09:34:11.json" 
Job execution start time: 2024-06-13 09:34:11 
Job execution end time: 2024-06-13 09:37:06 
Job execution elapsed time: 2 minutes 55 seconds 
ZDM_GET_SRC_INFO ........... PRECHECK_PASSED 
ZDM_GET_TGT_INFO ........... PRECHECK_PASSED 
ZDM_PRECHECKS_SRC .......... PRECHECK_PASSED 
ZDM_PRECHECKS_TGT .......... PRECHECK_PASSED 
ZDM_SETUP_SRC .............. PRECHECK_PASSED 
ZDM_SETUP_TGT .............. PRECHECK_PASSED 
ZDM_PREUSERACTIONS ......... PRECHECK_PASSED 
ZDM_PREUSERACTIONS_TGT ..... PRECHECK_PASSED 
ZDM_OBC_INST_SRC ........... PRECHECK_PASSED 
ZDM_OBC_INST_TGT ........... PRECHECK_PASSED 
ZDM_VALIDATE_SRC ........... PRECHECK_PASSED 
ZDM_VALIDATE_TGT ........... PRECHECK_PASSED 
ZDM_POSTUSERACTIONS ........ PRECHECK_PASSED 
ZDM_POSTUSERACTIONS_TGT .... PRECHECK_PASSED 
ZDM_CLEANUP_SRC ............ PRECHECK_PASSED 
ZDM_CLEANUP_TGT ............ PRECHECK_PASSED

Im nächsten Schritt kann die tatsächliche Migration gestartet werden. Hierzu wird derselbe Befehl wie im obigen Beispiel verwendet, allerdings ohne den Parameter -eval, da dieser nur für die Evaluierung genutzt wurde. Dieses Mal wird die vollständige Migration ausgeführt. Wie bereits in diesem Blogartikel erwähnt, erlaubt ZDM das Pausieren des Migrationsprozesses in jeder Phase, einschließlich der Phase vor dem Rollentausch und Switchover. Um den Migrationsprozess anzuhalten, muss beim Ausführen des Migrationsbefehls der Parameter -pauseafter mit der gewünschten Phase angegeben werden, in diesem Fall ZDM_CONFIGURE_DG_SRC, wie unten gezeigt.

[zdmuser@zdm-host ~]$ $ZDM_HOME/bin/zdmcli migrate database -sourcesid ORCL -sourcenode zdm-sourcedb -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/zdmuser/ssh-key-2024-06-03.key -srcarg3 sudo_location:/usr/bin/sudo -targetnode zdm-target-db -backupuser "iatco.mihaela04@gmail.com" -rsp /home/zdmuser/physical_online.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/ssh-key-2024-06-03.key -tgtarg3 sudo_location:/usr/bin/sudo -targethome /u01/app/oracle/product/19.0.0.0/dbhome_1 -pauseafter ZDM_CONFIGURE_DG_SR

Nun werden alle Phasen der Migration dargestellt, wobei die tatsächliche Migration mehr Phasen umfasst als die Evaluierung. Dies liegt daran, dass die Evaluierung nur die Voraussetzungen und Konfigurationen überprüft, während die tatsächliche Migration zusätzliche Schritte wie Backups, Datenübertragung, Data Guard-Konfiguration, Switchover und Aufräumarbeiten beinhaltet.

[zdmuser@zdm-host ~]$ $ZDM_HOME/bin/zdmcli query job -jobid 32 
Job ID: 32 
User: zdmuser 
Client: zdm-host 
Job Type: "MIGRATE" 
Current status: PAUSED 
…… 
ZDM_GET_SRC_INFO .............. COMPLETED 
ZDM_GET_TGT_INFO .............. COMPLETED 
ZDM_PRECHECKS_SRC ............. COMPLETED 
ZDM_PRECHECKS_TGT ............. COMPLETED 
ZDM_SETUP_SRC ................. COMPLETED 
ZDM_SETUP_TGT ................. COMPLETED 
ZDM_PREUSERACTIONS ............ COMPLETED 
ZDM_PREUSERACTIONS_TGT ........ COMPLETED 
ZDM_OBC_INST_SRC .............. COMPLETED 
ZDM_OBC_INST_TGT .............. COMPLETED 
ZDM_VALIDATE_SRC .............. COMPLETED 
ZDM_VALIDATE_TGT .............. COMPLETED 
ZDM_BACKUP_FULL_SRC ........... COMPLETED 
ZDM_BACKUP_INCREMENTAL_SRC .... COMPLETED 
ZDM_DISCOVER_SRC .............. COMPLETED 
ZDM_COPYFILES ................. COMPLETED 
ZDM_PREPARE_TGT ............... COMPLETED 
ZDM_SETUP_TDE_TGT ............. COMPLETED 
ZDM_CLONE_TGT ................. COMPLETED 
ZDM_FINALIZE_TGT .............. COMPLETED 
ZDM_CONFIGURE_DG_SRC .......... COMPLETED 
ZDM_SWITCHOVER_SRC ............ PENDING 
ZDM_SWITCHOVER_TGT ............ PENDING 
ZDM_POST_DATABASE_OPEN_TGT .... PENDING 
ZDM_DATAPATCH_TGT ............. PENDING 
ZDM_SHUTDOWN_SRC .............. PENDING 
ZDM_POST_MIGRATE_TGT .......... PENDING 
ZDM_POSTUSERACTIONS ........... PENDING 
ZDM_POSTUSERACTIONS_TGT ....... PENDING 
ZDM_CLEANUP_SRC ............... PENDING 
ZDM_CLEANUP_TGT ............... PENDING

Es ist zu beachten, dass der aktuelle Auftragsstatus jetzt im PAUSED-Status ist und der Fortschritt nach Abschluss der Phase ZDM_CONFIGURE_DG_SRC gestoppt wurde.

Wenn man die Datenbankrollen überprüft, wird festgestellt, dass die Quelldatenbank die primäre Datenbank und die Zieldatenbank die physische Standby-Datenbank ist. In dieser Phase werden alle Änderungen in der Quelldatenbank automatisch mit der Zieldatenbank synchronisiert. Der Migrationsauftrag setzt fort, sobald die Nutzeranwendungen bereit sind.

  -------------------Quell-Datenbanksystem-------------------[oracle@zdm-sourcedb ~]$ sqlplus / as sysdba 
SQL> select database_role from v$database; 
DATABASE_ROLE 
---------------- 
PRIMARY 
 
 -------------------Ziel-Datenbanksystem-------------------[oracle@target ~]$ sqlplus / as sysdba 
SQL> select database_role from v$database; 
DATABASE_ROLE 
---------------- 
PHYSICAL STANDBY

Der Migrationsprozess, der im vorherigen Schritt pausiert wurde, kann wieder aufgenommen werden.

[zdmuser@zdm-host ~]$ $ZDM_HOME/bin/zdmcli resume job -jobid 32

Nach dem Fortsetzen des Migrationsprozesses werden alle Phasen abgeschlossen. Sobald der gesamte Prozess erfolgreich beendet ist, werden die Rollen der Datenbanken erneut überprüft. Dabei wird festgestellt, dass die Quelldatenbank jetzt die Standby-Datenbank ist und die Zieldatenbank die primäre Datenbank. Damit ist die Migration erfolgreich abgeschlossen und das System ist bereit für den produktiven Betrieb in der neuen Umgebung.

 -------------------Quell-Datenbanksystem-------------------[oracle@zdm-sourcedb ~]$ sqlplus / as sysdba 
SQL> select database_role from v$database; 
DATABASE_ROLE 
---------------- 
PHYSICAL STANDBY 
 
 -------------------Ziel-Datenbanksystem-------------------[oracle@target ~]$ sqlplus / as sysdba 
SQL> select database_role from v$database; 
DATABASE_ROLE 
---------------- 
PRIMARY

Fazit

Zusammenfassend zeigt der Beitrag, dass die Migration von Oracle-Datenbanken in die Cloud mit Zero Downtime Migration reibungslos und ohne Unterbrechungen erfolgen kann. Unternehmen können ihre Datenbanken sicher in die OCI migrieren und dabei sowohl die Datenverfügbarkeit als auch die Integrität bewahren. Dieser Ansatz minimiert Risiken und maximiert die Effizienz während des Migrationsprozesses. So wird der Übergang in die Cloud zu einer planbaren und kontrollierten Maßnahme.