Zu Oracle Exadata Database Service on Dedicated Infrastructure migrieren

In diesem Abschnitt wird beschrieben, wie Sie Ihre Oracle Exadata-Workloads in Oracle Exadata Database Service on Dedicated Infrastructure migrieren und Ihre VMware-Anwendungen in Oracle Cloud VMware Solution migrieren.

Architektur

Diese Architektur zeigt eine Migration von On-Premise-Oracle Exadata-Datenbanken und VMware-Anwendungen zu Oracle Exadata Database Service on Dedicated Infrastructure und Oracle Cloud VMware Solution.

Mit Oracle Zero Downtime Migration können Sie die Datenbankmigration automatisieren und gleichzeitig bei der Migration Ihrer Daten von On Premise in die Cloud minimale Ausfallzeiten verursachen.

Migrieren Sie Ihre On-Premise-Anwendungen, die unter VMware ausgeführt werden, mit VMware-Tools wie HCX und vMotion in Oracle Cloud VMware Solution. Mit Oracle Cloud VMware Solution erhalten Sie eine vollständig automatisierte Implementierung eines softwaredefinierten VMware Data Centers (SDDC) in Ihrem OCI-Mandanten, das auf OCI-Bare-Metal-Instanzen ausgeführt wird.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur.

Beschreibung von migration-vmware-cloud-solution-exadata-dedicated-architecture.png folgt

Beschreibung der Abbildung migration-vmware-cloud-solution-exadata-dedicated-architecture.png

migrations-vmware-cloud-solution-exadata-dedicated-architecture.zip

Diese Architektur unterstützt die folgenden Komponenten:

Region
Eine Oracle Cloud Infrastructure-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Center enthält, das als Availability-Domains bezeichnet wird. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können sie voneinander trennen (innerhalb von Ländern oder sogar Kontinenten).
Virtuelles Cloud-Netzwerk (VCN) und Subnetz
Ein VCN ist ein anpassbares, Software-definiertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region einrichten können. Wie herkömmliche Data Center-Netzwerke erhalten Sie mit VCNs vollständige 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.
Oracle Exadata Database Service on Dedicated Infrastructure
Oracle Exadata Database Service on Dedicated Infrastructure stellt Oracle Exadata Database Machine als Service in einem OCI-Data Center bereit. The Oracle Exadata Database Service on Dedicated Infrastructure service can host many Oracle databases that run in one or more VM clusters that run on a single Exadata rack in an OCI region. Oracle Exadata Database Service on Dedicated Infrastructure ist eine ideale Plattform für die Datenbankkonsolidierung.
Softwaredefiniertes Data Center (SDDC) von Oracle Cloud VMware Solution
Oracle und VMware haben zusammen eine VMware-zertifizierte Software-Defined Data Center-(SDDC-)Implementierung zur Verwendung in Oracle Cloud Infrastructure entwickelt. Diese Implementierung, die als Oracle Cloud VMware Solution bezeichnet wird, hostet mit Oracle Cloud Infrastructure ein hochverfügbares VMware-SDDC. Außerdem ist eine nahtlose Migration all Ihrer On-Premise-SDDC-Workloads VMware in Oracle Cloud VMware Solution möglich. Oracle Cloud VMware Solution enthält die folgenden VMware-Komponenten:
- VMware vSphere ESXi
- VMware vSAN
- VMware vCenter
- VMware NSX-T
- VMware HCX (optional)
Bare Metal
Ein Oracle Cloud VMware Solution Software-Defined Data Center (SDDC) enthält Bare-Metal-Server, die Oracle Cloud VMware Solution hosten. Der Bare-Metal-Server unterstützt Anwendungen, die eine hohe Anzahl an Cores, einen großen Arbeitsspeicher und eine hohe Bandbreite (wie Oracle Cloud VMware Solution) erfordern. Sie können Oracle Cloud VMware Solution auf Bare-Metal-Servern bereitstellen und virtuelle Maschinen mit erheblichen Performanceverbesserungen im Vergleich zu anderen Public Clouds und On-Premise-Data Centern konfigurieren.
Servicegateway
Das Servicegateway ermöglicht den Zugriff von einem VCN auf andere Services wie Oracle Cloud Infrastructure Object Storage. Der Datenverkehr vom VCN zum Oracle-Service durchläuft die Oracle-Netzwerkfabric und nie das Internet.
Dynamisches Routinggateway (DRG)
Das DRG ist ein virtueller Router, der einen Pfad für privaten Netzwerktraffic zwischen VCNs in derselben Region zwischen einem VCN und einem Netzwerk außerhalb der Region bereitstellt, wie einem VCN in einer anderen Oracle Cloud Infrastructure-Region, einem On-Premise-Netzwerk oder einem Netzwerk in einem anderen Cloud-Provider.
FastConnect
Mit Oracle Cloud Infrastructure FastConnect können Sie ganz einfach eine dedizierte, private Verbindung zwischen Ihrem Data Center und Oracle Cloud Infrastructure erstellen. FastConnect bietet Optionen mit höherer Bandbreite und eine zuverlässigere Netzwerkerfahrung im Vergleich zu internetbasierten Verbindungen.
Dateispeicher
OCI File Storage wird während der logischen Migration verwendet, um die migrierte Datenbank aus einem Shared File System zu importieren.
Object Storage
OCI Object Storage wird für die logische und physische Migration für den temporären Speicher während der Migration verwendet.

Bevor Sie beginnen

Bevor Sie beginnen, prüfen Sie die Versionen der Hauptkomponenten, die in diesem Setup verwendet werden, und prüfen Sie die Produktdokumentation auf eine spätere Referenz.

Anforderungen überprüfen

Stellen Sie sicher, dass die Quelldatenbank Oracle Database Version 19.18 Enterprise Edition oder höher ausführt.
Die Zieldatenbank muss Oracle Exadata Database Service on Dedicated Infrastructure X8 oder höher auf Oracle Database Version 19.18 Enterprise Edition oder höher sein.
Oracle Zero Downtime Migration muss Version 21.4 oder höher sein.
Der Zwischenspeicher muss OCI Object Storage, Oracle ZFS Storage Appliance (NAS) und OCI File Storage enthalten.

Dokumentation lesen

In diesem Lösungs-Playbook wird beschrieben, wie Sie Ihre Datenbank-Workloads migrieren. In der unten stehenden Lösung erfahren Sie, wie Sie Ihre VMware-Workloads migrieren. Die zusätzlichen Ressourcen sind hilfreich für Kontext, Details und Referenz für die Datenbankmigration.

Erfahren Sie, wie Sie die VMware-Komponenten Ihrer Workload in Oracle Cloud VMware Solution migrieren.

On-Premise-VMware-Workloads in die Cloud migrieren

Prüfen Sie die Oracle Zero Downtime Migration-Ressourcen:

Physische Migrationsressourcen prüfen:

Logische Migrationsressourcen prüfen:

Oracle Database-Ressourcen prüfen:

Erforderliche Produkte und Rollen - Info

Diese Lösung erfordert die folgenden Produkte:

Oracle Cloud Infrastructure Identity and Access Management
OCI-Computing
OCI Object Storage
OCI-Dateispeicher
Oracle Zero Downtime Migration
Oracle Exadata
Oracle Exadata Database Service on Dedicated Infrastructure

Diese Rollen sind für jedes Produkt erforderlich.

Produktname: Rolle	Erforderlich für...
Oracle Cloud Infrastructure Identity and Access Management: `OCI_user`	Authentifizierungstoken für physische Migration erstellen API-Schlüssel für logische Migration erstellen
OCI-Compute: `admin`	OCI Compute-Instanz zur Ausführung der Oracle Zero Downtime Migration-Software erstellen
OCI-Objektspeicher: `Storage Admin`	OCI Object Storage-Buckets für logische und physische Migration erstellen
OCI-Dateispeicher: `Storage Admin`	OCI-Dateispeicher für logische Migration erstellen
Oracle Zero Downtime Migration: `opc`	Erstellen Sie `zdmuser`, um die Oracle Zero Downtime Migration-Software zu installieren und auszuführen
Oracle Zero Downtime Migration: `zdmuser`	Oracle Zero Downtime Migration-Software installieren Oracle Zero Downtime Migration ausführen
Oracle Exadata: `root/sudoer user`	Mounten Sie die Netzwerkdateisystemfreigabe vom mit dem Netzwerk verbundenen Speichergerät, um die Datenbank für logische Migrationen zu exportieren Kennwortloses SSH von der virtuellen Maschine von Oracle Zero Downtime Migration aktivieren Führen Sie `sudo`-Befehle aus, um den Oracle Zero Downtime Migration-Software-Agent zu installieren Führen Sie `sudo`-Befehle aus, um eine Datenbank zu sichern oder zu exportieren
Oracle Exadata-Datenbank: `sys/system`	Daten mit Oracle Recovery Manager (RMAN) für die physische Migration sichern Data Pump ausführen, um die Datenbank für die logische Migration zu exportieren
Oracle Exadata Database Service on Dedicated Infrastructure: `Database Admin`	Oracle Exadata Database Service on Dedicated Infrastructure-Zieldatenbank erstellen
Oracle Exadata Database Service on Dedicated Infrastructure VM Cluster Nodes: `opc`	Mounten Sie die Netzwerkdateisystemfreigabe aus OCI File Storage, um die Datenbank für logische Migrationen zu importieren Kennwortloses SSH von der virtuellen Maschine von Oracle Zero Downtime Migration aktivieren Oracle Zero Downtime Migration-Software-Agent installieren Führen Sie `sudo`-Befehle aus, um die Datenbank wiederherzustellen oder zu importieren.
Oracle Exadata Database Service on Dedicated Infrastructure-Datenbank: `sys/system`	Daten mit Oracle Recovery Manager (RMAN) für physische Migrationen wiederherstellen Data Pump ausführen, um die Datenbank für die logische Migration zu importieren

Informationen zu den benötigten Informationen finden Sie unter Oracle Produkte, Lösungen und Services.

Logische und physische Migration

Oracle Zero Downtime Migration unterstützt zwei Arten von Datenbankmigrationen von Oracle Exadata zu Oracle Exadata Database Service on Dedicated Infrastructure: logische Migration und physische Migration.

Die logische Migration verwendet eine Kombination aus Oracle Data Pump und Oracle GoldenGate, während die physische Migration eine Kombination aus Oracle Recovery Manager (RMAN) und Oracle Data Guard verwendet. In der folgenden Tabelle werden die Szenarios erläutert, in denen eine logische oder physische Migration verwendet werden soll.

Logische Migration	Physische Migration
Wird empfohlen, wenn einige integrierbare Datenbanken und/oder Schemas migriert werden.	Wird empfohlen, wenn vollständige Datenbanken migriert werden. Beispiel: Containerdatenbanken mit allen integrierbaren Datenbanken oder Lift-and-Shift.
Selektive integrierbare Datenbanken (PDBs) und/oder Schemas können migriert werden.	Containerdatenbanken werden in Containerdatenbanken migriert, und Nicht-Containerdatenbanken werden in Nicht-Containerdatenbanken migriert.
Das Kennwort `Sys` für Quelle und Ziel kann unterschiedlich sein. Datenbanknamen zwischen Quelle und Ziel können unterschiedlich sein.	`Sys`-Kennwort und Datenbankname auf Quelle und Ziel müssen identisch sein. DB_UNIQUE_NAME in Quelle und Ziel muss unterschiedlich sein.
Datenbanken können während der Migration upgegradet werden.	Datenbanken können im Rahmen der Migration nicht upgegradet werden.

Mit logischer Migration migrieren

In diesem Abschnitt wird beschrieben, wie eine logische Offlinemigration durchgeführt wird. Informationen zur Onlinemigration finden Sie im Abschnitt "Dokumentation prüfen".

Beachten Sie vor der Migration Folgendes.

Die Quelldatenbank auf Oracle Exadata muss nicht verschlüsselt werden. Oracle Zero Downtime Migration verschlüsselt die Zieldatenbank während der Migration.
Die Quell- und Zieldatenbank müssen nicht dasselbe sys-Kennwort, Wallet-Kennwort, dieselbe Datenbankversion, denselben Datenbanknamen und dieselbe Patchebene aufweisen.
Oracle Zero Downtime Migration allows migrating certain pluggable databases (PDBs) and/or schemas to pluggable databases in Oracle Exadata Database Service on Dedicated Infrastructure.
Für logische Migrationen ist ein gemeinsam genutztes Dateisystem erforderlich. Während der logischen Migration exportiert Oracle Zero Downtime Migration die Daten nicht direkt in OCI Object Storage. In der Exadata-Quelldatenbank exportiert Oracle Zero Downtime Migration Daten in ein gemeinsam verwendetes Dateisystem (entweder Netzwerkdateisystem oder Oracle Advanced Cluster File System). Exportierte Daten werden dann in OCI Object Storage hochgeladen. Oracle Zero Downtime Migration verschiebt die Datendumps dann aus OCI Object Storage in OCI File Storage. Schließlich kann Oracle Exadata Database Service on Dedicated Infrastructure die Daten über das Netzwerkdateisystem aus OCI File Storage importieren.
Oracle Exadata On Premise kann sowohl Einzelinstanz- als auch RAC-Datenbanken ausführen. Oracle Exadata Database Service on Dedicated Infrastructure führt RAC-Datenbanken aus. Während der Datenbankmigration konvertiert Oracle Zero Downtime Migration Einzelinstanzdatenbanken bei Bedarf in RAC-Datenbanken.
In Oracle Exadata On Premise ist die Verwendung von Oracle Transparent Data Encryption zur Verschlüsselung von Datenbanken optional. Bei der Migration von Datenbanken von Exadata zu Oracle Exadata Database Service on Dedicated Infrastructure wird die Oracle Exadata Database Service on Dedicated Infrastructure-Zieldatenbank immer verschlüsselt.
The following steps assume there is direct network connectivity between the Data Center where Oracle Exadata is installed, and the OCI Virtual Cloud Network where the Oracle Exadata Database Service on Dedicated Infrastructure and the Oracle Zero Downtime Migration virtual machine is configured (via FastConnect or IPSec VPN as shown in the architecture diagram).

In den folgenden Schritten wird beschrieben, wie eine logische Offlinemigration ausgeführt wird.

Erstellen Sie in der OCI-Konsole eine Compute-Instanz in demselben VCN, in dem die Oracle Exadata Database Service on Dedicated Infrastructure-Zieldatenbank konfiguriert wird.
Bei dieser Compute-Instanz kann es sich um eine beliebige Ausprägungen mit mindestens zwei OCPUs und 16 GB RAM handeln, auf der das Oracle Linux 7.9-Betriebssystem ausgeführt wird. Mit dieser virtuellen Maschine wird die Oracle Zero Downtime Migration-Software ausgeführt.
Befolgen Sie die Oracle Zero Downtime Migration-Installationsdokumentation im Abschnitt "Dokumentation prüfen", um die Oracle Zero Downtime Migration 21.4-Software auf der OCI-Compute-Instanz herunterzuladen und zu installieren.
Führen Sie die Oracle Zero Downtime Migration-Software als zdmuser aus.
Melden Sie sich als zdmuser bei der Compute-Instanz an, auf der Oracle Zero Downtime Migration-Software ausgeführt wird, und generieren Sie ein SSH-Schlüsselpaar. Enable passwordless ssh from the zdmuser account to all nodes on the source Exadata database (root, privilege-sudoer user), and to all VM cluster nodes on the target Oracle Exadata Database Service on Dedicated Infrastructure database opc user account.
Stellen Sie sicher, dass die Oracle Zero Downtime Migration-VM mit den Quelldatenbankhosts mit Hostname und IP-Adresse kommunizieren kann. Prüfen Sie Folgendes:
- Ändern Sie gegebenenfalls den VCN-DNS-Resolver oder die Datei /etc/hosts in der Oracle Zero Downtime Migration-VM.
- Stellen Sie sicher, dass eine Sicherheitsregel vorhanden ist, mit der die Oracle Zero Downtime Migration-VM eine Verbindung zur Quelldatenbank auf dem Standard-Listener-Port 1521 und dem SSH-Port 22 herstellen kann.
- Ensure the Oracle Zero Downtime Migration VM can reach the target Oracle Exadata Database Service on Dedicated Infrastructure hosts on the default listener port 1521 and ssh port 22.
Erstellen Sie in Oracle ZFS Storage Appliance oder einem netzwerkgebundenen Speichergerät eine Netzwerkdateisystemfreigabe, die während der Migration als Platzhalter für die Datenbankdaten-Dumps verwendet werden soll.
Mounten Sie die Netzwerkdateisystemfreigabe auf allen Knoten der Exadata-Datenbank.
Stellen Sie sicher, dass alle Benutzer über Lese-, Schreib-, Ausführungs-(rwx-)Berechtigungen verfügen. Notieren Sie sich den Einhängepunkt.
Erstellen Sie in der OCI-Konsole einen OCI-Dateispeicher.
Notieren Sie sich das Mountziel, den Export und die IP-Adresse. Die IP-Adresse wird standardmäßig im Backupnetzwerk von Oracle Exadata Database Service on Dedicated Infrastructure verwendet.
Verwenden Sie die IP-Adresse, und exportieren Sie diese aus Schritt 7, um diesen Dateispeicher über das Netzwerkdateisystem auf allen Knoten des VM-Clusters Oracle Exadata Database Service on Dedicated Infrastructure zu mounten.
Stellen Sie sicher, dass das virtuelle Cloud-Netzwerk eine Sicherheits-Policy enthält, mit der das Netzwerkdateisystemprotokoll im Backupnetzwerk Oracle Exadata Database Service on Dedicated Infrastructure zulässig ist. Notieren Sie sich den Mount Point.
Erstellen Sie eine Oracle Exadata Database Service on Dedicated Infrastructure mit der OCI-Konsole oder der REST-API. Konfigurieren Sie die Datenbank wie folgt:
- Die neue Zieldatenbank kann einen anderen Namen haben als die Quelldatenbank.
- Die neue Datenbank kann eine neuere Version als die Quelldatenbank sein.
- Geben Sie ein Kennwort für den Benutzer admin an. Notieren Sie sich das Passwort.
- Wählen Sie kein Backupziel aus, oder aktivieren Sie automatische Backups während der Datenbankerstellung. Diese Einstellungen können nach der Datenbankmigration aktiviert werden.
Notieren Sie sich die Datenbank-OCID, nachdem die Datenbank erstellt wurde.
Erstellen Sie in der OCI-Konsole einen OCI Object Storage-Bucket, falls dieser noch nicht vorhanden ist.
Notieren Sie sich die Swift-URL, den Object Storage-Namespace und den Bucket-Namen.
Use the OCI console, to create an API key for the OCI user who owns the target Oracle Exadata Database Service on Dedicated Infrastructure database and also has permissions to upload data to the OCI Object Storage bucket created in step 10.
Notieren Sie sich die Benutzer-OCID, die Mandanten-OCID, den Fingerprint und die OCI-Region. Speichern Sie die entsprechenden privaten und öffentlichen Schlüssel in PEM-Dateien. Dieser API-Schlüssel wird von Oracle Zero Downtime Migration verwendet, um eine Verbindung zu OCI herzustellen, um Informationen zur Zieldatenbank während der Datenbankmigration abzurufen und Datendumps in OCI Object Storage hochzuladen.
Kopieren Sie die PEM-Dateien aus dem vorherigen Schritt in die Oracle Zero Downtime Migration-VM.
Melden Sie sich als Benutzer sys bei der Exadata-Quelldatenbank an, um sicherzustellen, dass der Parameter Streams_Pool_Size auf mindestens 2G gesetzt ist. Beispiel:
```
SQL>show parameter streams_pool_size;
SQL>alter system set streams_pool_size=2G scope=both SID=’*’;                  
```
Verwenden Sie die in der Zero Downtime Migration enthaltene Vorlage für die logische Migrationsantwortdatei von Oracle Zero Downtime Migration, um eine Antwortdatei für die Migration zu erstellen. Wichtige Parameter sind:
- TARGETDATABASE_OCID: OCID der Oracle Exadata Database Service on Dedicated Infrastructure-Zieldatenbank.
- MIGRATION_METHOD: OFFLINE_LOGICAL
- DATA_TRANSFER_MEDIUM: OSS
- TARGETDATABASE_ADMINUSERNAME: system
- SOURCEDATABASE_ADMINUSERNAME: system
- SOURCEDATABASE_CONNECTIONDETAILS_HOST: IP/Hostname des ersten Knotens in der Exadata-Quelldatenbank.
- SOURCEDATABASE_CONNECTIONDETAILS_PORT: 1521
- SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAME: Servicename der Quell-PDB oder Nicht-Containerdatenbank (Nicht-CDB). Verwenden Sie lsnrctl, um zu suchen.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_TENANTID: Mandanten-OCID aus Schritt 11.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_USERID: Benutzer-OCID aus Schritt 11.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_FINGERPRINT: Fingerprint aus Schritt 11.
- OCIAUTHENTICATIONDETAILS_PRIVATEKEYFILE: Dateipfad zur PEM-Private-Key-Datei auf dem Oracle Zero Downtime Migration-Server aus Schritt 12.
- OCIAUTHENTICATIONDETAILS_REGIONID: OCI-Regions-ID für den OCI-Benutzer aus Schritt 11.
- TARGETDATABASE_CONNECTIONDETAILS_PORT: 1521
- TARGETDATABASE_CONNECTIONDETAILS_SERVICENAME: Servicename für die integrierbare Zieldatenbank in der Zieldatenbank. Verwenden Sie lsnrctl, um zu suchen.
- SOURCECONTAINERDATABASE_ADMINUSERNAME: system
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_HOST: IP/Hostname des ersten Knotens in der Exadata-Quelldatenbank.
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_PORT: 1521
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_SERVICENAME: Servicename für die Quellcontainerdatenbank in der Exadata-Datenbank. Verwenden Sie lsnrctl, um zu suchen).
- DATAPUMPSETTINGS_JOBMODE: SCHEMA
- DATAPUMPSETTINGS_FIXINVALIDOBJECTS: TRUE
- DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_NAME: mig
- DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_PATH: Einhängepunkt des Netzwerkdateisystems aus Schritt 6.
- DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_NAME: mig.
- DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_PATH: Einhängepunkt des Netzwerkdateisystems aus Schritt 8.
- DATAPUMPSETTINGS_CREATEAUTHTOKEN: TRUE
- DATAPUMPSETTINGS_DATAPUMPPARAMETERS_IMPORTPARALLELISMDEGREE: 4
- DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXPORTPARALLELISMDEGREE: 4
- DATAPUMPSETTINGS_DATABUCKET_NAMESPACE: OCI Object Storage-Namespace aus Schritt 10.
- DATAPUMPSETTINGS_DATABUCKET_BUCKETNAME: Bucket-Name des OCI Object Storage aus Schritt 10.
- TABLESPACEDETAILS_AUTOCREATE: TRUE
- TABLESPACEDETAILS_USEBIGFILE: TRUE
- TABLESPACEDETAILS_EXTENTSIZEMB: 512
- EXCLUDEOBJECTS-1: owner:PDBADMIN
Führen Sie einen Oracle Zero Downtime Migration-Trockenlaufmigrationsjob (-eval) aus, um zu prüfen, ob alle Voraussetzungen für die Migration möglich sind. This runs the Cloud Pre-Migration Advisor Tool (CPAT) to validate the source database is suitable for migration to Oracle Exadata Database Service on Dedicated Infrastructure using Oracle Zero Downtime Migration logical migration. Beheben Sie Probleme, die von CPAT gemeldet wurden, bevor Sie fortfahren. Beispiel:
```
zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user:root_or_sudoer_user \
-srcarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_14 \
-eval
```
Dieser Befehl fordert das Kennwort des Benutzers sys für die Quell- und Zieldatenbank an.

Fahren Sie nach einer erfolgreichen Migration mit dem nächsten Schritt fort.

Führen Sie nach der erfolgreichen Migration eines Testlaufs den Job Oracle Zero Downtime Migration aus. Beispiel:

zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user:root_or_sudoer_user \
-srcarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_14

Dieser Befehl fordert das Kennwort des Benutzers sys für die Quell- und Zieldatenbank an.

Mit physischer Migration migrieren

In diesem Abschnitt wird beschrieben, wie Sie eine physische Offlinemigration durchführen. Informationen zur Onlinemigration finden Sie im Abschnitt "Dokumentation prüfen".

Beachten Sie Folgendes, bevor Sie die physische Migration ausführen.

In Oracle Database 19.16 gibt es einen neuen Parameter für die Verwaltung der Tablespace-Verschlüsselung. Dieser Parameter kann zu Konflikten bei physischen Migrationen führen. Weitere Informationen finden Sie im Abschnitt "Dokumentation prüfen" unter "Tablespace-Verschlüsselungsverwaltung".
Oracle Exadata On Premise kann sowohl Einzelinstanz- als auch RAC-Datenbanken ausführen. Oracle Exadata Database Service on Dedicated Infrastructure führt RAC-Datenbanken aus. Während der Datenbankmigration konvertiert Oracle Zero Downtime Migration Einzelinstanzdatenbanken bei Bedarf in RAC-Datenbanken.
Ein Transparent Data Encryption-(TDE-)Wallet muss vor der Migration in der Quelldatenbank definiert werden, auch wenn die Quelldatenbank nicht verschlüsselt ist.
In Oracle Exadata On Premise ist die Verwendung von Oracle Transparent Data Encryption zur Verschlüsselung von Datenbanken optional. Bei der Migration von Datenbanken von Exadata zu Oracle Exadata Database Service on Dedicated Infrastructure wird die Oracle Exadata Database Service on Dedicated Infrastructure-Zieldatenbank immer verschlüsselt.
The following steps assume there is direct network connectivity between the Data Center where Exadata is installed, and the OCI Virtual Cloud Network where the Oracle Exadata Database Service on Dedicated Infrastructure and the Oracle Zero Downtime Migration virtual machine is configured (via FastConnect or IPSec VPN as shown in the architecture diagram).
Die Quelldatenbank auf Oracle Exadata muss nicht verschlüsselt werden. Oracle Zero Downtime Migration verschlüsselt die Zieldatenbank während der Migration.
Kennwort, Wallet-Kennwort, Datenbankversion und Patchebene sys in der Quell- und Zieldatenbank müssen identisch sein.
Oracle Zero Downtime Migration migriert Containerdatenbank (CDB) zu CDB und Nicht-CDB zu einer Nicht-CDB.
Oracle Zero Downtime Migration verwendet Oracle Database Backup Cloud Service, um ein Backup der Exadata-Quelldatenbank in OCI Object Storage zu erstellen. Oracle Zero Downtime Migration stellt dann die Zieldatenbank aus diesem Backup wieder her.

In den folgenden Schritten wird beschrieben, wie Sie eine physische Offlinemigration durchführen.

Erstellen Sie in der OCI-Konsole eine Compute-Instanz in demselben Subnetz, in dem die Zieldatenbank konfiguriert wird.
Bei dieser Compute-Instanz kann es sich um eine beliebige Ausprägungen mit mindestens zwei OCPUs und 16 GB RAM handeln, auf der das Oracle Linux 7.9-Betriebssystem ausgeführt wird. Mit dieser virtuellen Maschine wird die Oracle Zero Downtime Migration-Software ausgeführt.
Befolgen Sie die Oracle Zero Downtime Migration-Installationsdokumentation im Abschnitt "Dokumentation prüfen", um die Oracle Zero Downtime Migration 21.4-Software auf der OCI-Compute-Instanz herunterzuladen und zu installieren.
Führen Sie die Oracle Zero Downtime Migration-Software als zdmuser aus.
Melden Sie sich als zdmuser bei der Compute-Instanz an, auf der die Oracle Zero Downtime Migration-Software ausgeführt wird, und generieren Sie ein SSH-Schlüsselpaar. Aktivieren Sie das passwortlose SSH vom zdmuser-Account für alle Knoten in der Exadata-Quelldatenbank (root, privilege-sudoer user) und für alle VM-Clusterknoten im opc user-Account der Zieldatenbank.
Stellen Sie sicher, dass die Oracle Zero Downtime Migration-VM mit den Quelldatenbankhosts mit Hostname und IP-Adresse kommunizieren kann. Prüfen Sie Folgendes:
- Ändern Sie gegebenenfalls den VCN-DNS-Resolver oder die Datei /etc/hosts in der Oracle Zero Downtime Migration-VM.
- Stellen Sie sicher, dass eine Sicherheitsregel vorhanden ist, mit der die Oracle Zero Downtime Migration-VM eine Verbindung zur Quelldatenbank auf dem Standard-Listener-Port 1521 und dem SSH-Port 22 herstellen kann.
- Stellen Sie sicher, dass die Oracle Zero Downtime Migration-VM die Zieldatenbankhosts auf dem Standard-Listener-Port 1521 und dem SSH-Port 22 erreichen kann.
Erstellen Sie in der OCI-Konsole einen OCI Object Storage-Bucket, falls dieser noch nicht vorhanden ist.
Notieren Sie sich die Swift-URL, den Object Storage-Namespace und den Bucket-Namen.
In the OCI console, create an authentication token for the OCI_user uploading data to the OCI Object Storage bucket.
Beachten Sie das Token. Es wird nicht erneut angezeigt.
Stellen Sie sicher, dass mit Sicherheits-Policys OCI_user Daten in den OCI Object Storage-Bucket hochgeladen werden können.
Create an Oracle Exadata Database Service on Dedicated Infrastructure target database using the OCI GUI or REST API. Konfigurieren Sie die Zieldatenbank wie folgt:
- Die Ziel- und Quelldatenbanken müssen dieselben Namen, aber unterschiedliche DB_UNIQUE_NAME aufweisen.
- The sys password, wallet password, database version, patch level, and timezone file version on the source and target databases must be the same.
- Wählen Sie kein Backupziel aus, oder aktivieren Sie automatische Backups. Diese Einstellungen können nach der Migration der Datenbank aktiviert werden.
Prüfen Sie, ob die Quelldatenbank im Archivelog-Modus konfiguriert ist. Wenn Archivelog nicht aktiviert ist, finden Sie weitere Informationen unter Archivelog-Modus aktivieren.
Wenn die Quelldatenbank nicht verschlüsselt ist, finden Sie unten unter Transparent Data Encryption-(TDE-)Keystore konfigurieren. Daten müssen nicht verschlüsselt werden, nur der TDE-Keystore ist für die physische Migration erforderlich. Stellen Sie sicher, dass das Keystore-(Wallet-)Kennwort mit dem Kennwort sys/wallet übereinstimmt, mit dem die Zieldatenbank in Oracle Exadata Database Service on Dedicated Infrastructure erstellt wird.
Erstellen Sie eine Antwortdatei für Oracle Zero Downtime Migration, um die Migration auszuführen. Zu den wichtigsten Parametern gehören:
- TGT_DB_UNIQUE_NAME: Database unique name for the target Oracle Exadata Database Service on Dedicated Infrastructure database.
- MIGRATION_METHOD: OFFLINE_PHYSICAL oder ONLINE_PHYSICAL.
- DATA_TRANSFER_MEDIUM: OSS
- PLATFORM_TYPE: EXACS
- HOST: Die Swift-URL für den OCI Object Storage-Namespace aus Schritt 5 im Format: https://swiftobjectstorage.<region>.oraclecloud.com/v1/<namespace>>. Beispiel:
```
https://switfobjectstorage.us-phoenix-1.oraclecloud.com/v1/axwytvijqqld
```
- OPC_CONTAINER: Bucket-Name des OCI Object Storage aus Schritt 4.
- SHUTDOWN_SRC: TRUE

Führen Sie einen Oracle Zero Downtime Migration-Trockenlaufmigrationsjob (-eval) aus, um zu prüfen, ob alle Voraussetzungen für die Migration möglich sind. Beispiel:

zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user: root_or_sudoer_user \
-srcarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_10 \
-backupuser “OCI_user_id_for_user_allowed_to_upload_data_to_OCI_object_storage_bucket”
-eval

Dieser Befehl fordert zwei Passwörter an. Das erste Kennwort ist das sys-Kennwort für die Quelldatenbank. Das zweite Kennwort ist das OCI_user-Kennwort für den Benutzer, der Daten in den OCI Object Storage-Bucket hochlädt. Geben Sie hier nicht das Benutzerkennwort ein, sondern das Authentifizierungstoken aus Schritt 6.

Fahren Sie nach einem erfolgreichen Trockenlauf mit dem nächsten Schritt fort.

Führen Sie den Job Oracle Zero Downtime Migration aus. Beispiel:

zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user: root_or_sudoer_user \
-srcarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_10 \
-backupuser “OCI_user_id_for_user_allowed_to_upload_data_to_OCI_object_storage_bucket”

Die physische Offlinemigration ist abgeschlossen.

Archivelog-Modus aktivieren

Der Archivelog-Modus muss in der Quelldatenbank für physische Oracle Zero Downtime Migration-Migrationen aktiviert sein. In diesen Schritten wird beschrieben, wie der Archivelog-Modus in der Quelldatenbank konfiguriert wird.

Prüfen Sie, ob die Quelldatenbank im Archivelog-Modus nicht konfiguriert ist.
```
SQL> select log_mode from v$database;
LOG_MODE
------------
NOARCHIVELOG
```

Konfigurieren Sie das Logarchivierungsziel der Quelldatenbank. Da diese Konfiguration für eine in Exadata ausgeführte Datenbank gilt, muss das Archivelog-Ziel die Oracle RECO ASM-Datenträgergruppe sein.

SQL> alter system set log_archive_dest_1='LOCATION=+RECOC1' scope=both SID='*';
System altered.
SQL> select destination,STATUS from v$archive_dest where statuS='VALID';
DESTINATION
--------------------------------------------------------------------------------
STATUS
---------
+RECOC1
VALID

Fahren Sie die Datenbank herunter.
```
$ srvctl stop database -d db_name
```
Mounten Sie die Datenbank auf dem ersten Knoten.
```
SQL> startup mount;
ORACLE instance started.
```
Aktivieren Sie den Archivelog-Modus.
```
alter database archivelog;
```
Öffnen Sie die Datenbank.
```
alter database open;
```

Prüfen Sie, ob sich die Datenbank im Archivelog-Modus befindet.

SQL> select log_mode from v$database;
LOG_MODE
------------
ARCHIVELOG
SQL> select destination,STATUS from v$archive_dest where status='VALID';
DESTINATION
--------------------------------------------------------------------------------
STATUS
---------
+RECOC1
VALID

Starten Sie die Datenbank auf dem zweiten Knoten neu.

$ srvctl start instance -d db_name -n hostname_node2

Prüfen Sie, ob sich die integrierbaren Datenbanken auf beiden Knoten im Modus "Offen", "Lesen" und "Schreiben" befinden. Wenn die integrierbaren Datenbanken nicht geöffnet sind, öffnen Sie die integrierbaren Datenbanken auf beiden Knoten, und speichern Sie den Status.
```
SQL> Alter pluggabale database pdb_name open instances=all;
SQL>Alter pluggable database pdb_name save state instances=all;
```

Transparent Data Encryption (TDE)-Keystore konfigurieren

Für physische Oracle Zero Downtime Migration-Migrationen ist ein auto_login-TDE-Verschlüsselungs-Keystore/-Wallet erforderlich (auch wenn die Quelldatenbank nicht verschlüsselt ist). Dieser Keystore muss mit demselben Kennwort wie der Zieldatenbank-Keystore konfiguriert werden. In diesen Schritten wird beschrieben, wie Sie einen Keystore in der Quelldatenbank konfigurieren.

Prüfen Sie, ob ein Standard-Keystore-Speicherort für die Datenbank konfiguriert ist.

SQL> select * from v$encryption_wallet;
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
/u01/app/oracle/admin/db_name/wallet
NOT_AVAILABLE UNKNOWN SINGLE NONE UNDEFINED
1
SQL>

In dieser Ausgabe wird angezeigt, dass kein Keystore oder Wallet konfiguriert ist.

Legen Sie die Variable TNS_ADMIN für den Benutzer oracle auf beiden Exadata-Knoten fest.
```
$ORACLE_HOME/network/admin/db_name
```
Erstellen Sie ein Verzeichnis, um die Datei sqlnet.ora auf beiden Exadata-Knoten zu speichern, die mit TNS_ADMIN zeigen.
```
mkdir -p $ORACLE_HOME/network/admin/db_name
```
Erstellen Sie die Datei sqlnet.ora in dem Verzeichnis, auf das TNS_ADMIN zeigt, mit dem folgenden Inhalt auf beiden Exadata-Knoten.
```
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
 (METHOD_DATA=(DIRECTORY=/u01/app/oracle/admin/db_name/wallet)))
```
Erstellen Sie ein Verzeichnis, um den Keystore oder das Wallet in dem Speicherort zu speichern, auf den sqlnet.ora auf beiden Exadata-Knoten zeigt.
```
$mkdir -p $/u01/app/oracle/admin/db_name/wallet
```
Erstellen Sie auf dem ersten Knoten den Keystore, der mit einem Kennwort geschützt ist.
Der Zieldatenbank-Keystore muss ebenfalls mit diesem Kennwort konfiguriert werden.
```
SQL>administer key management create keystore '/u01/app/oracle/admin/db_name/wallet' identified by keystore_password;
```
Öffnen Sie auf dem ersten Knoten den Keystore.
Wenn die Quelldatenbank eine Nicht-CDB ist, entfernen Sie container = ALL.
```
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password container = ALL;
```
Erstellen Sie ein Backup für den Keystore.
Wenn die Quelldatenbank eine Nicht-CDB ist, entfernen Sie container = ALL.
```
SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY keystore_password with backup container = ALL;
```

Prüfen Sie, ob der Keystore erstellt und gesichert wurde.

SQL> SELECT * FROM v$encryption_keys;
Snip…
ACTIVATING_PDBNAME
--------------------------------------------------------------------------------
ACTIVATING_PDBID ACTIVATING_PDBUID ACTIVATING_PDBGUID CON_ID
---------------- ----------------- -------------------------------- ----------
ATOlrcGaa0/iv/dFeRSkNSIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--------------------------------------------------------------------------------
ACTIVATING_PDBID ACTIVATING_PDBUID ACTIVATING_PDBGUID CON_ID
---------------- ----------------- -------------------------------- ----------
db_name
ACTIVATING_PDBID ACTIVATING_PDBUID ACTIVATING_PDBGUID CON_ID
---------------- ----------------- -------------------------------- ----------
1 86B637B62FDF7A65E053F706E80A27CA
Snip…

Erstellen Sie einen auto_login-Keystore aus dem Keystore, der in Schritt 7 erstellt wurde.

SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '/u01/app/oracle/admin/db_name/wallet' IDENTIFIED BY keystore_password ;

Schließen Sie den Keystore aus Schritt 7.

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY keystore_password;

Stellen Sie sicher, dass der auto_login-Keystore noch geöffnet ist.

SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
/u01/app/oracle/admin/db_name/wallet
OPEN AUTOLOGIN SINGLE NONE NO

Erstellen Sie Wallet-Dateien von Knoten 1 bis Knoten 2.

cd /u01/app/oracle/admin/db_name/wallet.
scp * node_2:/u01/app/oracle/admin/db_name/wallet

Starten Sie die Datenbank auf beiden Exadata-Knoten neu.

$ srvctl stop database -d db_name
$ srvctl start database -d db_name
$ srvctl status database -d db_name
Instance db_name1 is running on node node_1
Instance db_name2 is running on node node_2

Stellen Sie sicher, dass das Wallet auto_login auf beiden Knoten geöffnet ist.

SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
/u01/app/oracle/admin/db_name/wallet/
OPEN AUTOLOGIN SINGLE NONE NO
1
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
OPEN AUTOLOGIN SINGLE UNITED NO
2
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
OPEN_NO_MASTER_KEY AUTOLOGIN SINGLE UNITED UNDEFINED
3
SQL>

Prüfen Sie, ob sich die integrierbaren Datenbanken auf beiden Knoten im Modus "Offen", "Lesen" und "Schreiben" befinden. Wenn keine integrierbaren Datenbanken geöffnet sind, öffnen Sie die integrierbaren Datenbanken auf beiden Knoten, und speichern Sie den Status.
```
SQL> Alter pluggabale database pdb_name open instances=all;
SQL>Alter pluggable database pdb_name save state instances=all;
```