Migrate to Oracle Exadata Database Service on Dedicated Infrastructure

This section describes how to migrate your Oracle Exadata workloads to Oracle Exadata Database Service on Dedicated Infrastructure, and migrate your VMware applications to Oracle Cloud VMware Solution.

Architecture

This architecture shows a migration from on-premises Oracle Exadata databases and VMware applications to Oracle Exadata Database Service on Dedicated Infrastructure and Oracle Cloud VMware Solution.

Using Oracle Zero Downtime Migration, automate your database migration while experiencing minimal downtime when migrating your data from on-premises to the cloud.

Migrate your on-premises applications running on VMware to Oracle Cloud VMware Solution using VMware tools such as HCX and vMotion. Oracle Cloud VMware Solution gives you a fully automated implementation of a VMware software-defined data center (SDDC) within your OCI tenancy, running on OCI bare metal instances.

The following diagram illustrates this reference architecture.

Description of migrate-vmware-cloud-solution-exadata-dedicated-architecture.png follows

Description of the illustration migrate-vmware-cloud-solution-exadata-dedicated-architecture.png

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

This architecture supports the following components:

Region
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
Virtual cloud network (VCN) and subnet
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
Oracle Exadata Database Service on Dedicated Infrastructure
Oracle Exadata Database Service on Dedicated Infrastructure provides Oracle Exadata Database Machine as a service in an OCI data center. 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 is an ideal platform for database consolidation.
Oracle Cloud VMware Solution Software-Defined Data Center (SDDC)
Oracle and VMware have partnered to develop a VMware certified Software-Defined Data Center (SDDC) implementation for use within Oracle Cloud Infrastructure. This implementation, called the Oracle Cloud VMware Solution, uses Oracle Cloud Infrastructure to host a highly available VMware SDDC. It also allows seamless migration of all your on-premises VMware SDDC workloads to Oracle Cloud VMware Solution. Oracle Cloud VMware Solution contains the following VMware components:
- VMware vSphere ESXi
- VMware vSAN
- VMware vCenter
- VMware NSX-T
- VMware HCX (optional)
Bare metal
An Oracle Cloud VMware Solution Software-Defined Data Center (SDDC) contains bare metal servers hosting Oracle Cloud VMware Solution. The bare metal server supports applications that require high core counts, large amounts of memory, and high bandwidth (such as Oracle Cloud VMware Solution). You can deploy Oracle Cloud VMware Solution on bare metal servers, and configure virtual machines with significant performance improvements compared to other public clouds and on-premises data centers.
Service gateway
The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.
Dynamic routing gateway (DRG)
The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.
FastConnect
Oracle Cloud Infrastructure FastConnect provides an easy way to create a dedicated, private connection between your data center and Oracle Cloud Infrastructure. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.
File storage
OCI File Storage is used during logical migration to import the migrated database from a shared file system.
Object storage
OCI Object Storage is used for logical and physical migration for temporary storage during migration.

Before You Begin

Before you begin, check the versions of major components used in this setup, and review the product documentation for later reference.

Review Requirements

Ensure the source database is running Oracle Database version 19.18 Enterprise Edition or above.
The target database must be Oracle Exadata Database Service on Dedicated Infrastructure X8 or newer, on Oracle Database version 19.18 Enterprise Edition or above.
Oracle Zero Downtime Migration must be version 21.4 or above.
Intermediate storage must include OCI Object Storage, Oracle ZFS Storage Appliance (NAS), and OCI File Storage.

Review Documentation

This solution playbook describes how to migrate your database workloads. Refer to the solution below to learn how to migrate your VMware workloads. The additional resources are helpful for context, details, and reference for your database migration.

Learn how to migrate the VMware components of your workload to Oracle Cloud VMware Solution.

Migrate your on-premises VMware workloads to the cloud

Review Oracle Zero Downtime Migration resources:

Review physical migration resources:

Review logical migration resources:

Review Oracle Database resources:

About Required Products and Roles

This solution requires the following products:

Oracle Cloud Infrastructure Identity and Access Management
OCI Compute
OCI Object Storage
OCI File Storage
Oracle Zero Downtime Migration
Oracle Exadata
Oracle Exadata Database Service on Dedicated Infrastructure

These are the roles needed for each product.

Product Name: Role	Required to...
Oracle Cloud Infrastructure Identity and Access Management: `OCI_user`	Create authentication tokens for physical migration Create API keys for logical migration
OCI Compute: `admin`	Create OCI Compute instance to run Oracle Zero Downtime Migration software
OCI Object Storage: `Storage Admin`	Create OCI Object Storage buckets for logical and physical migration
OCI File Storage: `Storage Admin`	Create OCI File Storage for logical migration
Oracle Zero Downtime Migration: `opc`	Create `zdmuser` to install and run Oracle Zero Downtime Migration software
Oracle Zero Downtime Migration: `zdmuser`	Install Oracle Zero Downtime Migration software Run Oracle Zero Downtime Migration
Oracle Exadata: `root/sudoer user`	Mount network file system share from network attached storage device to export database for logical migrations Enable passwordless ssh from Oracle Zero Downtime Migration virtual machine Run `sudo` commands to install Oracle Zero Downtime Migration software agent Run `sudo` commands to backup or export database
Oracle Exadata Database: `sys/system`	Backup data using Oracle Recovery Manager (RMAN) for physical migration Run Data Pump to export database for logical migration
Oracle Exadata Database Service on Dedicated Infrastructure: `Database Admin`	Create target Oracle Exadata Database Service on Dedicated Infrastructure database
Oracle Exadata Database Service on Dedicated Infrastructure VM Cluster Nodes: `opc`	Mount network file system share from OCI File Storage to import database for logical migrations Enable passwordless ssh from Oracle Zero Downtime Migration virtual machine Install Oracle Zero Downtime Migration software agent Run `sudo` commands to restore or import database
Oracle Exadata Database Service on Dedicated Infrastructure Database: `sys/system`	Restore data using Oracle Recovery Manager (RMAN) for physical migrations Run Data Pump to import database for logical migration

See Oracle Products, Solutions, and Services to get what you need.

About Logical and Physical Migration

Oracle Zero Downtime Migration supports two types of database migrations from Oracle Exadata to Oracle Exadata Database Service on Dedicated Infrastructure: logical migration and physical migration.

Logical migration uses a combination of Oracle Data Pump and Oracle GoldenGate, while physical migration uses a combination of Oracle Recovery Manager (RMAN) and Oracle Data Guard. The following table explains the scenarios in which a logical or physical migration should be used.

Logical Migration	Physical Migration
Recommended when a few pluggable databases and/or schemas are migrated.	Recommended when full databases are migrated. For example, container databases with all pluggable databases, or lift and shift.
Selective pluggable databases (PDBs) and/or schemas can be migrated.	Container databases will be migrated to container databases, and non-container databases will be migrated to non-container databases.
`Sys` password on the source and target can be different. Database names between the source and target can be different.	`Sys` password and database name on both the source and target should be identical. DB_UNIQUE_NAME on the source and target must be different.
Databases can be upgraded during migration.	Databases cannot be upgraded as part of migration.

Migrate Using Logical Migration

This section describes how to perform an offline logical migration. For online migration, refer to the Review Documentation section.

Before performing your migration, note the following.

The source database on Oracle Exadata does not have to be encrypted. Oracle Zero Downtime Migration will encrypt the target database during migration.
The source and target databases do not have to have the same sys password, wallet password, database version, database name, and patch level.
Oracle Zero Downtime Migration allows migrating certain pluggable databases (PDBs) and/or schemas to pluggable databases in Oracle Exadata Database Service on Dedicated Infrastructure.
A shared file system is required for logical migrations. During logical migration, Oracle Zero Downtime Migration will not export the data directly to OCI Object Storage. On the source Exadata database, Oracle Zero Downtime Migration exports data to a shared file system (either network file system or Oracle Advanced Cluster File System). Exported data is then uploaded to OCI Object Storage. Oracle Zero Downtime Migration then moves the data dumps from OCI Object Storage to OCI File Storage. Finally, then Oracle Exadata Database Service on Dedicated Infrastructure can import the data from OCI File Storage via network file system.
Oracle Exadata on-premises can run both single-instance and RAC databases. Oracle Exadata Database Service on Dedicated Infrastructure runs RAC databases. During database migration, Oracle Zero Downtime Migration converts single-instance to RAC databases when required.
In on-premises Oracle Exadata, the use of Oracle Transparent Data Encryption to encrypt databases is optional. When migrating databases from Exadata to Oracle Exadata Database Service on Dedicated Infrastructure, the target Oracle Exadata Database Service on Dedicated Infrastructure database will always be encrypted.
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).

The following steps describe how to perform an offline logical migration.

In the OCI console, create a compute instance in the same VCN where the target Oracle Exadata Database Service on Dedicated Infrastructure database will be configured.
This compute instance can be any shape, with at least two OCPUs and 16GB of RAM, running the Oracle Linux 7.9 operating system. This virtual machine will be used to run the Oracle Zero Downtime Migration software.
Follow the Oracle Zero Downtime Migration installation documentation from the Review Documentation section to download and install Oracle Zero Downtime Migration 21.4 software on the OCI compute instance.
Run Oracle Zero Downtime Migration software as the zdmuser.
Log in as the zdmuser to the compute instance running Oracle Zero Downtime Migration software, and generate an ssh key-pair. 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.
Ensure the Oracle Zero Downtime Migration VM can communicate with the source database hosts using hostname and IP address. Verify the following:
- Modify the VCN DNS resolver, or the /etc/hosts file in the Oracle Zero Downtime Migration VM if necessary.
- Verify there is a security rule that allows the Oracle Zero Downtime Migration VM to connect to the source database on the default listener port 1521 and ssh port 22.
- 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.
On the Oracle ZFS Storage Appliance, or network attached storage device, create a network file system share to be used as a placeholder for the database data dumps while the migration progresses.
Mount the network file system share on all nodes of the Exadata database.
Ensure all users have read, write, exec (rwx) permissions. Take note of the mount point.
In the OCI console, create an OCI File Storage.
Note the mount target, export, and IP address. The IP address by default is on the Oracle Exadata Database Service on Dedicated Infrastructure backup network.
Use the IP address and export from step 7 to mount this file storage via network file system on all nodes of the Oracle Exadata Database Service on Dedicated Infrastructure VM cluster.
Ensure the Virtual Cloud Network includes a security policy to allow the network file system protocol on the Oracle Exadata Database Service on Dedicated Infrastructure backup network. Note the mount point.
Create a target Oracle Exadata Database Service on Dedicated Infrastructure database using the OCI console or REST API. Configure the database as follows:
- The new target database can have a different name than the source database.
- The new database can be a newer version than the source database.
- Provide a password for the admin user. Take note of the password.
- Do not select a backup destination or enable automatic backups during database creation. These settings can be enabled after the database migration.
Note the database OCID after the database is created.
In the OCI console, create an OCI Object Storage bucket if one does not already exist.
Note the Swift URL, object storage namespace, and bucket name.
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.
Note the user OCID, tenancy OCID, fingerprint, and OCI region. Save the corresponding private and public keys on PEM files. This API key will be used by Oracle Zero Downtime Migration to connect to OCI to obtain target database information during database migration and to upload data dumps to OCI Object Storage.
Copy the PEM files from the previous step to the Oracle Zero Downtime Migration VM.

Log in as the sys user to the source Exadata database to ensure the parameter Streams_Pool_Size is set to at least 2G, for example:

SQL>show parameter streams_pool_size;
SQL>alter system set streams_pool_size=2G scope=both SID=’*’;

Use Oracle Zero Downtime Migration's logical migration response file template included with Zero Downtime Migration to create a response file for the migration. Key parameters are:
- TARGETDATABASE_OCID: OCID of the Oracle Exadata Database Service on Dedicated Infrastructure target database.
- MIGRATION_METHOD: OFFLINE_LOGICAL
- DATA_TRANSFER_MEDIUM: OSS
- TARGETDATABASE_ADMINUSERNAME: system
- SOURCEDATABASE_ADMINUSERNAME: system
- SOURCEDATABASE_CONNECTIONDETAILS_HOST: IP/hostname of the first node on the source Exadata database.
- SOURCEDATABASE_CONNECTIONDETAILS_PORT: 1521
- SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAME: Service name of the source PDB or non-container database (non-CDB). Use lsnrctl to find.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_TENANTID: Tenancy OCID from step 11.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_USERID: User OCID from step 11.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_FINGERPRINT: Fingerprint from step 11.
- OCIAUTHENTICATIONDETAILS_PRIVATEKEYFILE: File path to private key PEM file on the Oracle Zero Downtime Migration server from step 12.
- OCIAUTHENTICATIONDETAILS_REGIONID: OCI region ID for the OCI user from step 11.
- TARGETDATABASE_CONNECTIONDETAILS_PORT: 1521
- TARGETDATABASE_CONNECTIONDETAILS_SERVICENAME: Service name for the target pluggable database in the target database. Use lsnrctl to find.
- SOURCECONTAINERDATABASE_ADMINUSERNAME: system
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_HOST: IP/hostname of the first node on the source Exadata database.
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_PORT: 1521
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_SERVICENAME: Service name for the source container database in Exadata database. Use lsnrctl to find).
- DATAPUMPSETTINGS_JOBMODE: SCHEMA
- DATAPUMPSETTINGS_FIXINVALIDOBJECTS: TRUE
- DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_NAME: mig
- DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_PATH: Network file system mount point from step 6.
- DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_NAME: mig.
- DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_PATH: Network file system mount point from step 8.
- DATAPUMPSETTINGS_CREATEAUTHTOKEN: TRUE
- DATAPUMPSETTINGS_DATAPUMPPARAMETERS_IMPORTPARALLELISMDEGREE: 4
- DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXPORTPARALLELISMDEGREE: 4
- DATAPUMPSETTINGS_DATABUCKET_NAMESPACE: OCI Object Storage namespace from step 10.
- DATAPUMPSETTINGS_DATABUCKET_BUCKETNAME: OCI Object Storage bucket name from step 10.
- TABLESPACEDETAILS_AUTOCREATE: TRUE
- TABLESPACEDETAILS_USEBIGFILE: TRUE
- TABLESPACEDETAILS_EXTENTSIZEMB: 512
- EXCLUDEOBJECTS-1: owner:PDBADMIN
Run an Oracle Zero Downtime Migration dry run migration job (-eval), to validate all prerequisites for migration are possible. 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. Address issues reported by CPAT before continuing. For example:
```
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
```
This command asks for the sys user's password of the source and target databases.

After a successful dry run migration, proceed to the next step.

After a dry run migration is successful, run the Oracle Zero Downtime Migration job. For example:

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

This command asks for the sys user's password of the source and target databases.

Migrate Using Physical Migration

This section describes how to perform an offline physical migration. For online migration, refer to the Review Documentation section.

Before performing your physical migration, note the following.

There's a new parameter for tablespace encryption management in Oracle Database 19.16. This parameter may cause conflicts for physical migrations. Review Tablespace Encryption Management in the Review Documentation section for more information.
Oracle Exadata on-premises can run both single-instance and RAC databases. Oracle Exadata Database Service on Dedicated Infrastructure runs RAC databases. During database migration, Oracle Zero Downtime Migration converts single-instance to RAC databases when required.
A Transparent Data Encryption (TDE) wallet must be defined on the source database before migration, even if the source database is not encrypted.
In on-premises Oracle Exadata, the use of Oracle Transparent Data Encryption to encrypt databases is optional. When migrating databases from Exadata to Oracle Exadata Database Service on Dedicated Infrastructure, the target Oracle Exadata Database Service on Dedicated Infrastructure database will always be encrypted.
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).
The source database on Oracle Exadata does not have to be encrypted. Oracle Zero Downtime Migration will encrypt the target database during migration.
The sys password, wallet password, database version, and patch level on the source and target databases must be the same.
Oracle Zero Downtime Migration will migrate container database (CDB) to CDB and non-CDB to non-CDB.
Oracle Zero Downtime Migration uses Oracle Database Backup Cloud Service to backup the source Exadata database to OCI Object Storage. Oracle Zero Downtime Migration then restores the target database from this backup.

The following steps describe how to perform an offline physical migration.

In the OCI console, create a compute instance in the same subnet where the target database will be configured.
This compute instance can be any shape, with at least two OCPUs and 16GB of RAM, running the Oracle Linux 7.9 operating system. This virtual machine will be used to run the Oracle Zero Downtime Migration software.
Follow the Oracle Zero Downtime Migration installation documentation from the Review Documentation section to download and install Oracle Zero Downtime Migration 21.4 software on the OCI compute instance.
Run Oracle Zero Downtime Migration software as the zdmuser.
Log in as the zdmuser to the compute instance running the Oracle Zero Downtime Migration software, and generate an ssh key-pair. 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 database opc user account.
Ensure the Oracle Zero Downtime Migration VM can communicate with the source database hosts using hostname and IP address. Verify the following:
- Modify the VCN DNS resolver, or the /etc/hosts file in the Oracle Zero Downtime Migration VM if necessary.
- Verify there is a security rule that allows the Oracle Zero Downtime Migration VM to connect to the source database on the default listener port 1521 and ssh port 22.
- Ensure the Oracle Zero Downtime Migration VM can reach the target database hosts on the default listener port 1521 and ssh port 22.
In the OCI console, create an OCI Object Storage bucket if one does not already exist.
Note the Swift URL, object storage namespace, and bucket name.
In the OCI console, create an authentication token for the OCI_user uploading data to the OCI Object Storage bucket.
Note the token, it will not be displayed again.
Ensure security policies allow the OCI_user to upload data to the OCI Object Storage bucket.
Create an Oracle Exadata Database Service on Dedicated Infrastructure target database using the OCI GUI or REST API. Configure the target database as follows:
- The target and source databases must have the same names, but different DB_UNIQUE_NAME.
- The sys password, wallet password, database version, patch level, and timezone file version on the source and target databases must be the same.
- Do not select a Backup Destination or enable Automatic Backups. These settings can be enabled after the database is migrated.
Verify the source database is configured in Archivelog Mode. If Archivelog is not enabled, see Enable Archivelog Mode below.
If the source database is not encrypted, see Configure a Transparent Data Encryption (TDE) Keystore below. Data does not need to be encrypted, only the TDE keystore is required for the physical migration. Make sure the keystore (wallet) password is the same as the sys/wallet password used to create the target database in Oracle Exadata Database Service on Dedicated Infrastructure.
Create a response file for Oracle Zero Downtime Migration to run the migration. Key parameters include:
- TGT_DB_UNIQUE_NAME: Database unique name for the target Oracle Exadata Database Service on Dedicated Infrastructure database.
- MIGRATION_METHOD: OFFLINE_PHYSICAL or ONLINE_PHYSICAL.
- DATA_TRANSFER_MEDIUM: OSS
- PLATFORM_TYPE: EXACS
- HOST: The Swift URL for the OCI Object Storage namespace from step 5 in the format: https://swiftobjectstorage.<region>.oraclecloud.com/v1/<namespace>>. For example:
```
https://switfobjectstorage.us-phoenix-1.oraclecloud.com/v1/axwytvijqqld
```
- OPC_CONTAINER: OCI Object Storage bucket name from step 4.
- SHUTDOWN_SRC: TRUE

Run an Oracle Zero Downtime Migration dry run migration job (-eval), to validate all pre-requisites for migration are possible. For example:

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

This command asks for two passwords. The first password is the sys password for the source database. The second password is the OCI_user password for the user uploading data to the OCI Object Storage bucket. Do not enter the user password here, instead, enter the authentication token from step 6.

After a successful dry run, proceed to the next step.

Run Oracle Zero Downtime Migration job. For example:

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”

The offline physical migration is complete.

Enable Archivelog Mode

Archivelog mode must be enabled on the source database for Oracle Zero Downtime Migration physical migrations. These steps will describe how to configure Archivelog mode on the source database.

Validate the source database is not configured in Archivelog mode.

SQL> select log_mode from v$database;
LOG_MODE
------------
NOARCHIVELOG

Configure the source database log archive destination. Since this configuration is for a database running in Exadata, the Archivelog destination must be the Oracle RECO ASM diskgroup.

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

Shutdown the database.
```
$ srvctl stop database -d db_name
```
Start mounting the database on the first node.
```
SQL> startup mount;
ORACLE instance started.
```
Enable Archivelog mode.
```
alter database archivelog;
```
Open the database.
```
alter database open;
```

Verify the database is in Archivelog mode.

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

Restart the database on the second node.

$ srvctl start instance -d db_name -n hostname_node2

Verify the pluggable databases are in open, read, write mode on both nodes. If the pluggable databases are not open, open the pluggable databases on both nodes and save the state.
```
SQL> Alter pluggabale database pdb_name open instances=all;
SQL>Alter pluggable database pdb_name save state instances=all;
```

Configure a Transparent Data Encryption (TDE) Keystore

Oracle Zero Downtime Migration physical migrations require an auto_login TDE encryption keystore/wallet (even if the source database is not encrypted). This keystore must be configured with the same password as the target database keystore. These steps describe how to configure a keystore on the source database.

Check if there is a default keystore location configured for the database.

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>

This output shows there is no keystore or wallet configured.

Set the variable TNS_ADMIN for the oracle user on both Exadata nodes.
```
$ORACLE_HOME/network/admin/db_name
```
Create a directory to store the sqlnet.ora file on both Exadata nodes pointed by TNS_ADMIN.
```
mkdir -p $ORACLE_HOME/network/admin/db_name
```

Create the sqlnet.ora file in the directory pointed by TNS_ADMIN with the following contents on both Exadata nodes.

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
 (METHOD_DATA=(DIRECTORY=/u01/app/oracle/admin/db_name/wallet)))

Create a directory to store the keystore or wallet at the location pointed by sqlnet.ora on both Exadata nodes.
```
$mkdir -p $/u01/app/oracle/admin/db_name/wallet
```
On the first node, create the keystore protected with a password.
The target database keystore must also be configured with this password.
```
SQL>administer key management create keystore '/u01/app/oracle/admin/db_name/wallet' identified by keystore_password;
```
On the first node, open the keystore.
If the source database is a non-CDB, then remove container = ALL.
```
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password container = ALL;
```

Create a backup for the keystore.

If the source database is a non-CDB, then remove container = ALL.

SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY keystore_password with backup container = ALL;

Verify the keystore was created and backed up.

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…

Create an auto_login keystore from the keystore created in step 7.

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

Close the keystore from step 7.

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

Verify the auto_login keystore is still open.

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

Create wallet files from node 1 to node 2.

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

Restart the database on both Exadata nodes.

$ 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

Verify the auto_login wallet is open on both nodes.

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>

Verify the pluggable databases are in open, read, write mode on both nodes. If pluggable databases are not open, open the pluggable databases on both nodes and save the state.
```
SQL> Alter pluggabale database pdb_name open instances=all;
SQL>Alter pluggable database pdb_name save state instances=all;
```