Migrieren von Oracle-Workloads zu Azure

Im Rahmen Ihrer Journey der Cloudeinführung müssen Sie Ihre bestehenden Workloads in die Cloud migrieren. Oracle-Workloads erfordern ähnlich wie andere Workloads einen methodischen Ansatz, um eine erfolgreiche Migration sicherzustellen. Weitere Informationen zur Migrationsmethodik finden Sie unter Cloudmigration im Cloud Adoption Framework. In diesem Artikel werden die für Oracle-Workloads spezifischen Einschränkungen und Überlegungen beschrieben.

Der Oracle-Migrationsprozess

Sie sollten Ihre Infrastrukturanforderungen ständig neu bewerten, um die Leistung zu verbessern und Kosten zu senken, indem Sie den entsprechenden Diensttyp für Ihre Workload wählen. Wenn Sie beispielsweise die Verlagerung Ihrer Workload zu Oracle Database@Azure planen, sollten Sie sicherstellen, dass die von Ihnen ausgewählte SKU Ihre Anforderungen erfüllt. Ebenso müssen Sie bei der Verlagerung Ihrer Workload auf virtuelle Oracle in Azure-Computer sicherstellen, dass die Größe des virtuellen Computers (VM) Ihre Anforderungen erfüllt. Weitere Informationen finden Sie unter Kapazitätsplanung für die Migration von Oracle-Workloads zu Azure-Zielzonen.

Überprüfen Sie die Migrationsressourcen, um den Prozess der Migration von Oracle zu Azure zu definieren. Weitere Funktionen:

• Überprüfen der Kontingentgrenzen von Azure-Abonnements: Stellen Sie sicher, dass die Ziel-VM-Größen, die Sie bei der Migration von virtuellen Oracle in Azure-Computern auswählen, die Kontingentgrenzen in Ihrem Azure-Abonnement unterstützen.

• Bestimmen eines Bereitstellungsmodells: Automatisieren Sie die Bereitstellung von Lösungskomponenten so weit wie möglich durch Einsatz von Infrastructure-as-Code (IaaS), CI/CD-Pipelines (Continuous Integration und Continuous Delivery) und anderen DevOps-Methoden.

• Ermitteln von Anwendungsabhängigkeiten: Stellen Sie sicher, dass Migrationsaktivitäten nur minimal störend wirken.

• Bestimmen der Datenkapazität: Bestimmen Sie die zu migrierende Datenmenge und bewerten Sie die aktuelle verfügbare Netzwerkkonnektivitätskapazität von lokalen Umgebungen zu Azure. Anhand dieser Informationen können Sie feststellen, ob Sie die Daten direkt aus lokalen Umgebungen in Azure kopieren können. Sie brauchen eventuell eine physische Datenübertragungsanwendung wie Azure Data Box für das anfängliche Laden von Daten.

• Ermitteln von Verfügbarkeitsanforderungen: Ermitteln Sie die Anforderungen an die Verfügbarkeit der Workload, denn sie können sich auf die einsetzbaren Migrationstools auswirken.

Für Oracle Database@Azure ist Folgendes erforderlich:

• Stellen Sie sicher, dass die Oracle Database@Azure-Lösung in der Region verfügbar ist, in der Sie die Lösung bereitstellen möchten. Weitere Informationen finden Sie unter Verfügbare Regionen.

• Berücksichtigen Sie die erforderlichen Datenbankänderungen, wenn Sie von lokalen Umgebungen zu Oracle Database@Azure wechseln. Die Migration kann einige Änderungen an den Datenbanktabellenbereichen und -schemas mit sich bringen. Weitere Informationen finden Sie unter Migrieren von Oracle-Datenbanken zu Exadata Cloud Service.

Workloadspezifische Oracle-Migrationsaktivitäten

Im folgenden Abschnitt wird der Migrationsprozess ausführlicher beschrieben. Die Schritte müssen nicht unbedingt aufeinander folgen. Manche Schritte können parallel ausgeführt werden.

• Bewerten der Quell- und Zielsystemversionen: Bewerten Sie, ob die lokalen Betriebssystemversionen, Anwendungs- und Datenbankversionen mit den Versionen übereinstimmen, die sie in Azure verwenden möchten.

  • Wenn Sie eine oder mehrere Ressourcen aktualisieren müssen, sollten Sie sie vor der Migration aktualisieren, damit der Migrationsprozess nicht kompliziert wird.

  • Wenn Ihre lokale Datenbank auf einem Large-Endian-Betriebssystem ausgeführt wird, z. B. Oracle Solaris, IBM Advanced Interactive Executive (AIX) oder Hewlett Packard Unix (HP-UX), umfasst der Prozess der Datenbankmigration eine Endian-Konvertierung. Azure unterstützt nur Little-Endian-Betriebssysteme. Aus Sicht der Tools beschränkt diese Unterstützung die Anzahl der Optionen, wenn es darum geht, welches Tool für die Migration verwendet werden soll. Nicht verwendet werden können insbesondere Oracle Data Guard, Azure Migrate und Modernize oder eine andere Dateikopiermethode. Zu den Migrationsmethoden, die mit der Endian-Konvertierung kompatibel sind, gehören Oracle DataPump Export, Oracle Data Pump Import, Oracle Cross Platform Transportable Tablespaces (XTTS) oder Hilfsprogramme zur Datenreplikation wie Oracle GoldenGate, Quest SharePlex und Striim.

  • Lokale Anwendungsserver können je nach Anforderungen und Kompatibilität modernisiert oder migriert werden. Weitere Informationen finden Sie unter Cloudeinführungsszenarien.

• Bewerten der Anforderungen an die Verfügbarkeit der Workload während des Migrationsprozesses: Wenn Sie die Ausfallzeit der Workload minimieren müssen, sind Migrationsmethoden wie die Funktionen DataPump Export, Data Pump Import oder Azure Migrate und Modernize gegebenenfalls nicht geeignet. In diesem Fall können Sie nach dem folgenden dreistufigen Prozess vorgehen:

  • Verwenden Sie den Oracle Recovery Manager (RMAN), um die gesamte Datenbank zu sichern und dann in Azure wiederherzustellen. Nehmen Sie bei Bedarf eine Endian-Konvertierung über XTTS vor. Dadurch ergibt sich eine Datenbank, die eine Kopie der lokalen Quelldatenbank zu einem bestimmten Zeitpunkt ist. Weitere Informationen finden Sie unter Transport von Daten über Plattformen hinweg.

  • Verwenden Sie Oracle Data Guard, um die neu wiederhergestellte Datenbank in Azure mit der Quelldatenbank zu synchronisieren, wenn beide Quellen das Little-Endian-Format haben. Wenn die Migration eine Konvertierung von Big-Endian nach Little-Endian erfordert, können Sie Data Guard nicht verwenden. Verwenden Sie stattdessen ein SQL-basiertes Hilfsprogramm zur Datenreplikation wie Oracle GoldenGate, Quest SharePlex oder Striim, um die neu wiederhergestellte Datenbank in Azure mit der Quelldatenbank zu synchronisieren.

  • Wenn Sie die Zieldatenbank in Azure mit der lokalen Quelldatenbank synchronisiert haben, können Sie ein Cutover planen. Ein Cutover schaltet die lokale Quelldatenbank ab und überträgt die letzten Transaktionen in die Zieldatenbank in Azure. Anschließend können Sie die Zieldatenbank in Azure als neue Quelldatenbank öffnen. Ein Cutover dauert je nach verwendeter Synchronisierungsmethode nur wenige Minuten.

  • Je nach der für Anwendungsdienste gewählten Migrationsmethode müssen Sie gegebenenfalls mehrere Aufgaben im Anwendungsdienst ausführen, bevor Sie die Anwendung vollständig zu Azure migrieren.

  • Ziehen Sie den Einsatz der Oracle-Migration ohne Downtime (ZDM) für den Migrationsprozess in Erwägung. Weitere Informationen finden Sie unter Migration ohne Downtime.

• Prüfen der erforderlichen Lizenzen: Je nach Migrationstool erfordert Ihre Datenbank möglicherweise verschiedene Lizenzen. Beispiel:

  • Oracle Data Guard erfordert die Oracle Database Enterprise Edition.

  • Oracle GoldenGate erfordert Oracle GoldenGate-Lizenzen.

  Weitere Informationen zur Oracle-Lizenzierung in Azure finden Sie unter Lizenzieren von Oracle-Software in der Cloud Computing-Umgebung.

Nächster Schritt

Oracle Database-Migration zu Azure