1. Migrate x86 databases to Oracle Exadata Database Service on Cloud@Customer
  2. Migrate Using Physical Migration

Migrate Using Physical Migration

These steps describe how to perform an online or offline physical migration. Before performing your physical migration, note the following.

  • The source database on the x86 server does not have to be encrypted. Zero Downtime Migration will encrypt the target database during migration.
  • A Transparent Data Encryption (TDE) wallet must be defined on the source database before migration, even if the source database is not encrypted.
  • The sys password, wallet password, database version, and patch level on the source and target databases must be the same.
  • Zero Downtime Migration will migrate container database (CDB) to CDB and non-CDB to non-CDB.

To run a physical migration with Zero Downtime Migration:

  1. Download and install Zero Downtime Migration software on a separate server. Run Zero Downtime Migration software using zdmuser.
  2. Login to your ZDM server as zdmuser.
  3. Generate an ssh key-pair.
  4. Enable passwordless ssh from zdmuser to the source x86 server (root/privilege-sudoer user) and to all VM Cluster nodes on the target Oracle Exadata Database Service on Cloud@Customer database (opc user).
  5. On the Oracle ZFS Storage Appliance (NAS), create a Network File System (NFS) Share to be used as a placeholder for the source database RMAN backups while the migration is in progress.
    The target database will be restored from the backups saved on this NFS Share.
  6. Mount the NFS Share on the same mount point on all nodes of the source and target databases. Ensure all users have read, write, and exec (rwx) permissions on both the source and target.
  7. Create a Oracle Exadata Database Service on Cloud@Customer 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, and patch level 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 has been migrated from source to target.
  8. Verify the source database is configured in Archivelog Mode. If Archivelog is not enabled, see Enable Archivelog Mode below.
  9. 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 Cloud@Customer.
  10. Create a response file for 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 Cloud@Customer database.
    • MIGRATION_METHOD: OFFLINE_PHYSICAL or ONLINE_PHYSICAL.
    • DATA_TRANSFER_MEDIUM: NFS
    • PLATFORM_TYPE: EXACC
    • BACKUP_PATH: Mount point for Network File System (NFS) Share on source and target from Step 4.
    • SHUTDOWN_SRC: TRUE
  11. Run a 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_x86_db_server \
-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_Cloud@Customer_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 \
-eval
  12. Run Zero Downtime Migration job. For example:
    zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_x86_db_server \
-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_Cloud@Customer_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
During physical online migrations, Zero Downtime Migration will configure Oracle Data Guard between the source and target to ensure the database is always online during the migration. Oracle Data Guard will synchronize any source database changes to the target database.
This completes the physical migration.

Enable Archivelog Mode

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

  1. Validate the source database is not configured in Archivelog mode.
    SQL> select log_mode from v$database;
LOG_MODE
------------
NOARCHIVELOG
  2. Configure the source database log archive destination. The following example is from a source database with DB files in a Linux file system. The LOCATION is different if DB files are stored in Oracle ASM Diskgroup.
    SQL> alter system set 
log_archive_dest_1='LOCATION=/u01/app/oracle/oradata/db_name/arc' 
scope=both;
System altered.
SQL> select destination,STATUS from v$archive_dest where status='VALID';
DESTINATION
--------------------------------------------------------------------------------
STATUS
---------
/u01/app/oracle/oradata/db_name/arc
VALID
  3. Shutdown the database, and then mount the database.
    SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started
  4. Enable Archivelog mode.
    alter database archivelog;
  5. Open the database.
    alter database open;
  6. Verify the database is in Archivelog mode.
    SQL> select destination,STATUS from v$archive_dest where statuS='VALID';
DESTINATION
--------------------------------------------------------------------------------
STATUS
---------
/u01/app/oracle/oradata/db_name/arc
VALID
SQL> select log_mode from v$database;
LOG_MODE
------------
ARCHIVELOG

Configure a Transparent Data Encryption (TDE) Keystore

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.

  1. 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>
  2. If a directory for the keystore does not already exist, create a directory for the keystore.
    mkdir -p /u01/app/oracle/admin/db_name/wallet
  3. Create a directory to store the sqlnet.ora file.
    mkdir -p $ORACLE_HOME/network/admin/
  4. Create the sqlnet.ora file in directory $ORACLE_HOME/network/admin/ with the keystore information from Step 1.
    ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
 (METHOD_DATA=(DIRECTORY=/u01/app/oracle/admin/db_name/wallet)))
  5. Create the keystore protected with a password. Keep in mind the target Oracle Exadata Database Service on Cloud@Customer 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;
  6. 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;
  7. 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;
  8. 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…
  9. Create an auto_login keystore from the keystore created in Step 5.
    SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM 
KEYSTORE '/u01/app/oracle/admin/db_name/wallet' IDENTIFIED BY 
keystore_password ;
  10. Close the keystore from Step 5.
    SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY 
keystore_password;
  11. 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