1. Mit Oracle Zero Downtime Migration zu Oracle Database@Azure wechseln
  2. Mit Oracle Zero Downtime Migration zu Oracle Database@Azure wechseln

Mit Oracle Zero Downtime Migration zu Oracle Database@Azure wechseln

Mit Oracle Database@Azure können Sie Ihre geschäftskritischen Oracle-Datenbanken auf Oracle Exadata Database Service on Dedicated Infrastructure im Microsoft Azure-Data Center ausführen.

Profitieren Sie von der integrierten High Availability, Performance und Skalierbarkeit von Oracle Exadata Database Service und Oracle Real Application Clusters (Oracle RAC), und profitieren Sie gleichzeitig von geringer Latenz für Ihre Azure-Anwendungen.

Die Datenbankmigration in die Cloud ist in der Regel ein manueller Prozess, der mit Ausfallzeiten für Ihr Unternehmen verbunden ist. Oracle Zero Downtime Migration vereinfacht und automatisiert Oracle-Datenbankmigrationen ohne bis zu minimale Ausfallzeiten, umfasst standardmäßig die Best Practices von Oracle Maximum Availability Architecture (Oracle MAA), unterstützt Flottenmigrationen und ist unter anderem kostenlos.

Seit seiner Veröffentlichung im Jahr 2019 ist Oracle Zero Downtime Migration das vertrauenswürdige Migrationstool für Kunden weltweit für Oracle-Datenbankmigrationen zu On-Premises-Oracle Exadata-Maschinen, Oracle Exadata Database Service on Cloud@Customer und Oracle Cloud Infrastructure (OCI). Weitere Informationen zur Oracle Zero Downtime Migration finden Sie unter "Weitere Informationen".

Architektur

Diese Referenzarchitektur beschreibt Oracle Database-Migrationen von On Premise zu Oracle Exadata Database Service on Dedicated Infrastructure auf Oracle Database@Azure mit dem physischen Online-Migrationsworkflow basierend auf Oracle Data Guard und direkter Datenübertragung. Dies bietet Einfachheit, Automatisierung und Geschäftskontinuität während Ihrer Datenbankmigrationen zu Oracle Database@Azure.

Der Host des Oracle Zero Downtime Migration-Service wird auf einer separaten On-Premise-VM neben der Quelldatenbank installiert. Das Ziel Oracle Exadata Database Service on Dedicated Infrastructure wird im Azure-Data Center im virtuellen Azure-Netzwerk (VNet) in einem delegierten Subnetz an Oracle Database@Azure bereitgestellt. Das On-Premise-Data Center ist über Azure ExpressRoute oder Site-to-Site-VPN mit dem Data Center von Azure verbunden. Der physische Onlineworkflow von Oracle Zero Downtime Migration basierend auf der direkten Datenübertragung erstellt die Zieldatenbank mit dem Restore aus einer Servicemethode und vermeidet das Backup der Quelldatenbank in einem Zwischenspeicherort. Oracle Zero Downtime Migration nutzt Oracle Data Guard automatisch, um die Daten aus der On-Premise-Datenbank in die Zieldatenbank zu replizieren. Oracle Zero Downtime Migration richtet Oracle Data Guard automatisch ein, verwaltet es und bereinigt die Konfiguration nach Abschluss der Migration. Daher sind keine Kenntnisse zum Einrichten und Verwalten von Oracle Data Guard erforderlich. Nach Abschluss der Migration kann die Zieldatenbank mit dem Feature "Automatisches Backup" ein Backup der Datenbank in Oracle Database Autonomous Recovery Service erstellen.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur.


Beschreibung von oracle-db-azure-zdm.png folgt
Beschreibung der Abbildung oracle-db-azure-zdm.png

oracle-db-azure-zdm-oracle.zip

Microsoft Azure stellt die folgenden Komponenten bereit:

  • Azure-VNIC

    Die Services in Azure-Data Centern weisen physische Netzwerkkarten (NICs) auf. Instanzen virtueller Maschinen kommunizieren über virtuelle NICs (VNICs), die mit den physischen NICs verknüpft sind. Jede Instanz verfügt über eine primäre VNIC, die während des Starts automatisch erstellt und angehängt wird und während der Lebensdauer der Instanz verfügbar ist.

  • Virtuelles Azure-Netzwerkgateway

    Azure Virtual Network Gateway ist ein Service, der sichere, standortübergreifende Konnektivität zwischen einem virtuellen Azure-Netzwerk und einem On-Premise-Netzwerk herstellt. Damit können Sie ein Hybridnetzwerk erstellen, das Ihr Data Center und Azure umfasst.

  • Delegiertes Azure-Subnetz

    Subnetzdelegierung ist die Fähigkeit von Microsoft, einen verwalteten Dienst, insbesondere einen Platform-as-a-Service, direkt in Ihr virtuelles Netzwerk einzuspeisen. Das bedeutet, dass Sie ein Subnetz als Home für einen externen verwalteten Service in Ihrem virtuellen Netzwerk festlegen oder delegieren können. Mit anderen Worten, dieser externe Service wird als virtuelle Netzwerkressource fungieren, obwohl es sich technisch um einen externen Platform-as-a-Service-Service handelt.

  • Virtuelles Azure-Netzwerk

    Das virtuelle Azure-Netzwerk (VNet) ist der grundlegende Baustein für Ihr privates Netzwerk in Azure. Mit VNet können viele Azure-Ressourcen, wie virtuelle Azure-Maschinen, sicher miteinander, mit dem Internet und On-Premise-Netzwerken kommunizieren.

Oracle Cloud Infrastructure stellt die folgenden Komponenten bereit:

  • Region

    Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält, das als Availability-Domain bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie trennen (über Länder oder sogar Kontinente).

  • Virtuelles Cloud-Netzwerk (VCN) und Subnetze

    Ein VCN ist ein anpassbares, benutzerdefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie traditionelle Data Center-Netzwerke erhalten Sie mit VCNs Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere sich nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

  • On-Premise-Netzwerk

    Dieses Netzwerk ist das lokale Netzwerk, das von Ihrer Organisation verwendet wird. Es ist eine der Speichen der Topologie.

  • Servicegateway

    Das Servicegateway ermöglicht den Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Traffic vom VCN zum Oracle-Service durchläuft die Oracle-Netzwerkstruktur und nicht das Internet.

  • Data Guard

    Oracle Data Guard und Oracle Active Data Guard stellen ein umfassendes Set von Services bereit, mit denen Sie eine oder mehrere Standbydatenbanken erstellen, verwalten, verwalten und überwachen und Oracle-Produktionsdatenbanken unterbrechungsfrei verfügbar bleiben können. Oracle Data Guard verwaltet diese Standbydatenbanken mit In-Memory-Replikation als Kopien der Produktionsdatenbank. Wenn die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht verfügbar ist, kann Oracle Data Guard jede Standbydatenbank in die Produktionsrolle umschalten, wodurch die Ausfallzeit im Zusammenhang mit dem Ausfall minimiert wird. Oracle Active Data Guard bietet die zusätzliche Möglichkeit, Workloads, die hauptsächlich gelesen werden, in Standbydatenbanken auszulagern, und bietet außerdem erweiterte Datenschutzfunktionen.

  • Exadata Database Service

    Mit Oracle Exadata Database Service können Sie die Vorteile von Exadata in der Cloud nutzen. Sie können flexible Exadata X9M-Systeme bereitstellen, mit denen Sie dem System Datenbank-Compute-Server und Storage Server je nach Bedarf hinzufügen können. Exadata X9M-Systeme bieten RDMA-über-Converged-Ethernet-(RoCE-)Networking für Module mit hoher Bandbreite und geringer Latenz, persistente Arbeitsspeicher (PMEM) und intelligente Exadata-Software. Sie können Exadata X9M-Systeme mit einer Ausprägung bereitstellen, die einem X9M-System mit Quarter-Rack entspricht. Anschließend können Sie Datenbank- und Speicherserver nach dem Provisioning jederzeit hinzufügen.

    Oracle Exadata Database Service on Dedicated Infrastructure bietet Oracle Exadata Database Machine als Service in einem Oracle Cloud Infrastructure-(OCI-)Data-Center. Die Oracle Exadata Database Service on Dedicated Infrastructure-Instanz ist ein Virtual-Machine-(VM-)Cluster, das sich auf Exadata-Racks in einer OCI-Region befindet.

    Oracle Exadata Database Service on Cloud@Customer stellt Oracle Exadata Database Service bereit, das in Ihrem Data Center gehostet wird.

  • Host des Migrationsservice ohne Ausfallzeit

    Der Host des Oracle Zero Downtime Migration-Service muss ein dediziertes System sein, kann aber für andere Zwecke gemeinsam verwendet werden.

    Die Oracle Zero Downtime Migration-Software erfordert einen eigenständigen Oracle Linux-Host, der auf einer der folgenden Plattformen ausgeführt wird: Oracle Linux 7, Oracle Linux 8 oder Red Hat Enterprise Linux 8.

    Der Host des Oracle Zero Downtime Migration-Service muss eine Verbindung zu den Quell- und Zieldatenbankservern herstellen können. Solange die Konnektivität gewährleistet ist, kann sich der Servicehost überall befinden.

  • Oracle Database Autonomous Recovery Service

    Oracle Database Autonomous Recovery Service ist ein Oracle Cloud-Service, der Oracle-Datenbanken schützt. Mit der Backupautomatisierung und den erweiterten Datenschutzfunktionen für OCI-Datenbanken können Sie alle Backupverarbeitungs- und Speicheranforderungen an Oracle Database Autonomous Recovery Service auslagern, wodurch die Kosten für die Backupinfrastruktur und der manuelle Administrationsaufwand entfallen.

Migrationsworkflows für Oracle Zero Downtime Migration

Hinweis:

Für jedes aufgelistete Migrationsworklfow finden Sie weitere Details unter "Weitere Informationen".

Sie können die folgenden Workflows ausführen, um Ihre Oracle Database in Oracle Exadata Database Service on Dedicated Infrastructure auf Oracle Database@Azure zu migrieren.

  • Physische Onlinemigration

    Der physische Onlinemigrationsworkflow unterstützt Migrationen zwischen denselben Datenbankversionen und Plattformen. Es verwendet die direkte Datenübertragung und die Methode "aus Service wiederherstellen", um die Zieldatenbank zu erstellen. Dabei wird explizit vermieden, dass die Quelldatenbank an einem Zwischenspeicherort gesichert wird. Oracle Data Guard hält die Quell- und Zieldatenbank synchron, um eine minimale Ausfallzeitmigration zu erreichen.

  • Physische Offlinemigration

    Der Workflow für die physische Offlinemigration unterstützt Migrationen zwischen denselben Datenbankversionen und Plattformen. Die Zieldatenbank wird mit Recovery Manager-(RMAN-)Backup und -Restore erstellt. Der Azure Files-Service stellt eine NFS-Dateifreigabe zum Speichern der RMAN-Backupdateien bereit.

  • Logische Onlinemigration

    Der logische Onlinemigrationsworkflow unterstützt Migrationen zwischen derselben und verschiedenen Datenbankversionen und Plattformen. Die Zieldatenbank wird mit Oracle Data Pump-Export und -Import erstellt. Der Azure Files-Service stellt eine NFS-Dateifreigabe zum Speichern der Data Pump-Dumpdateien bereit. OCI GoldenGate hält die Quell- und Zieldatenbank synchron, um eine minimale Ausfallzeitmigration zu erreichen.

  • Logische Offline-Migration

    Der logische Offline-Migrationsworkflow unterstützt Migrationen zwischen derselben und verschiedenen Datenbankversionen und Plattformen. Die Zieldatenbank wird mit Oracle Data Pump-Export und -Import erstellt. Der Azure Files-Service stellt eine NFS-Dateifreigabe zum Speichern der Data Pump-Dumpdateien bereit.

You can perform the following Oracle Zero Downtime Migration migration workflows to migrate your Oracle Database to Oracle Autonomous Database Serverless on Oracle Database@Azure.

  • Logische Onlinemigration

    Der logische Onlinemigrationsworkflow unterstützt Migrationen zwischen derselben und verschiedenen Datenbankversionen und Plattformen. Die Zieldatenbank wird mit Oracle Data Pump-Export und -Import erstellt. Der Azure Files-Service stellt eine NFS-Dateifreigabe zum Speichern der Data Pump-Dumpdateien bereit. OCI GoldenGate hält die Quell- und Zieldatenbank synchron, um eine minimale Ausfallzeitmigration zu erreichen.

  • Logische Offline-Migration

    Der logische Offline-Migrationsworkflow unterstützt Migrationen zwischen derselben und verschiedenen Datenbankversionen und Plattformen. Die Zieldatenbank wird mit Oracle Data Pump-Export und -Import erstellt. Der Azure Files-Service stellt eine NFS-Dateifreigabe zum Speichern der Data Pump-Dumpdateien bereit.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt. Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.
  • Laden Sie die neueste Oracle Zero Downtime Migration-Softwareversion von My Oracle Support (MOS) herunter, indem Sie auf der Registerkarte Patches und Updates nach Patch-Nummer 33509650 suchen.
  • Installieren Sie den Host des Oracle Zero Downtime Migration-Service On Premise neben der Quelldatenbank.
  • Stellen Sie sicher, dass der Host des Oracle Zero Downtime Migration-Service über mindestens 100 GB freien Speicher verfügt.
  • Stellen Sie über ein Site-to-Site-VPN oder Azure ExpressRoute eine sichere und private Netzwerkkonnektivität zwischen On Premise und Azure sicher.
  • Stellen Sie je nach Datenbankgröße einen ausreichenden Netzwerkdurchsatz von Ihrem On-Premise-Netzwerk zu Azure sicher.

Hinweise

Beachten Sie beim Deployment dieser Referenzarchitektur die folgenden Punkte.

  • Die Zieldatenbank muss:
    • Bereitstellung mit Oracle Cloud-Tools, ohne automatische Backups zu aktivieren.
    • Sie verfügen über eine Zeitzonendateiversion, die mit der Quelldatenbank identisch oder höher ist.
  • Die Quell- und Zieldatenbank müssen:
    • Haben denselben Datenbanknamen (DB_NAME).
    • Verwenden Sie unterschiedliche eindeutige Datenbanknamen (DB_UNIQUE_NAME).
    • Verwenden Sie ein Server Parameter File (SPFILE).
    • Verwenden Sie denselben Zeichensatz.
    • Sie müssen denselben Verschlüsselungsalgorithmus in der Datei sqlnet.ora definieren.
    • Verwenden Sie dieselbe Hauptversion (z. B. 19c). Die Zieldatenbank kann jedoch eine höhere Patchebene aufweisen (Beispiel: Quelle bei 19.21 und Ziel bei 19.22). Wenn sich die Zieldatenbank auf einer höheren Patchebene als die Quelldatenbank befindet, führt Oracle Zero Downtime Migration Datapatch automatisch im Rahmen der Migration aus.
  • Das Kennwort des SYS-Benutzeraccounts muss in der Quell- und Zieldatenbank identisch sein.
  • Der Initialisierungsparameter der COMPATIBLE-Datenbank muss in der Quell- und Zieldatenbank identisch sein.
  • Für Oracle Database 12c Release 2 und höher muss das TDE-Wallet in der Quelle vorhanden sein, und der Wallet-Status muss den Status OPEN aufweisen. Die Quelldatenbank muss nicht unbedingt verschlüsselt werden, aber ein TDE-Wallet muss konfiguriert werden.
  • Für Oracle Zero Downtime Migration muss der SSH-Schlüssel auf dem Host des Oracle Zero Downtime Migration-Service im RSA-Format vorliegen (in Oracle Linux 8 ist der Standardwert OPENSSH).

Mehr erfahren

Erfahren Sie mehr über die Services in dieser Architektur.

Prüfen Sie diese zusätzlichen Ressourcen:

Danksagungen

  • Autoren: Sinan Petrus Toma, Ricardo Gonzalez, Thomas Van Buggenhout
  • Beitragende: Emiel Ramakers, Wei Han, John Sulyok