Migrate Using Logical Migration

These steps describe how to perform an offline logical migration. Online logical migrations require an additional server running Oracle GoldenGate, this ensures the database is always online during the migration. Before performing your offline logical migration, note the following.

  • The source database on the x86 server does not have to be encrypted. Oracle Zero Downtime Migration will encrypt the target database during migration.
  • The sys password, database version, and patch level on the source and target databases can be different.
  • The database can be upgraded during migration.
  • Zero Downtime Migration logical migrations will allow the migration of certain pluggable database (PDB) and or schemas to a pluggable database (PDB) in Oracle Exadata Database Service on Cloud@Customer.

To run an offline logical migration:

  1. Download and install Zero Downtime Migration software on a separate server. Run Zero Downtime Migration software using zdmuser.
  2. Login to your Zero Downtime Migration 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 database data dumps while the migration is in progress.
  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 target database in Oracle Exadata Database Service on Cloud@Customer using the OCI GUI or REST API. Configure the target database as follows:
    • The target database's name and version can be different from the source.
    • 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. Use the OCI GUI to create an API Key for the OCI user who owns the target Oracle Exadata Database Service on Cloud@Customer database. Take note of the user OCID, tenancy OCID, fingerprint, and OCI region. Save the corresponding private and public keys in the .pem files. This API Key will be used by Zero Downtime Migration to connect to OCI to obtain the target database information during database migration.
  9. Copy the .pem files to the Zero Downtime Migration server.
  10. Login as sys to the target Oracle Exadata Database Service on Cloud@Customer database and 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=’*’;
  11. Use Zero Downtime Migration's logical migration response file template included with Zero Downtime Migration to create a response file for the migration. Key parameters include:
    • TARGETDATABASE_OCID: OCID of the Oracle Exadata Database Service on Cloud@Customer target database.
    • MIGRATION_METHOD: OFFLINE_LOGICAL
    • DATA_TRANSFER_MEDIUM: NFS
    • TARGETDATABASE_ADMINUSERNAME: system
    • SOURCEDATABASE_ADMINUSERNAME: system
    • SOURCEDATABASE_CONNECTIONDETAILS_HOST: IP/hostname of the source x86 database server.
    • SOURCEDATABASE_CONNECTIONDETAILS_PORT: 1521
    • SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAME: Service name of the source PDB or non-container database (CDB). Use lsnrctl to find.
    • OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_TENANTID: Tenancy OCID from Step 8.
    • OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_USERID: User OCID from Step 8.
    • OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_FINGERPRINT: Fingerprint from Step 8.
    • OCIAUTHENTICATIONDETAILS_PRIVATEKEYFILE: File path to private key .pem file on ZDM server from Step 9.
    • OCIAUTHENTICATIONDETAILS_REGIONID: OCI region ID for the OCI user from Step 8.
    • TARGETDATABASE_CONECTIONDETAILS_HOST: IP/hostname of the first VM on the target Oracle Exadata Database Service on Cloud@Customer VM Cluster.
    • TARGETDATABASE_CONNECTIONDETAILS_PORT: 1521
    • TARGETDATABASE_CONNECTIONDETAILS_SERVICENAME: Service name for the target pluggable database (PDB) in the target Oracle Exadata Database Service on Cloud@Customer database. Use lsnrctl to find.
    • SOURCECONTAINERDATABASE_ADMINUSERNAME: system
    • SOURCECONTAINERDATABASE_CONNECTIONDETAILS_HOST: IP/hostname of source x86 database server.
    • SOURCECONTAINERDATABASE_CONNECTIONDETAILS_PORT: 1521
    • SOURCECONTAINERDATABASE_CONNECTIONDETAILS_SERVICENAME: Service name for the source container database on the x86 server. Use lsnrctl to find).
    • DATAPUMPSETTINGS_JOBMODE: SCHEMA
    • DATAPUMPSETTINGS_FIXINVALIDOBJECTS: TRUE
    • DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_NAME: mig
    • DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_PATH: NFS mount point from Step 6.
    • DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_NAME: mig
    • DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_PATH: NFS mount point from Step 6.
    • DATAPUMPSETTINGS_CREATEAUTHTOKEN: TRUE
    • TABLESPACEDETAILS_AUTOCREATE: TRUE
    • TABLESPACEDETAILS_USEBIGFILE: TRUE
    • TABLESPACEDETAILS_EXTENTSIZEMB: 512
    • EXCLUDEOBJECTS-1: owner:PDBADMIN
  12. Run a Zero Downtime Migration dry run migration job (-eval), to validate all pre-requisites for migration are possible. This will run the Cloud Pre-Migration Advisor Tool (CPAT) to validate the source database is suitable for migration to Oracle Exadata Database Service on Cloud@Customer using 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_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_11 \
    -eval
    After a successful dry run migration, proceed to the next step.
  13. 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_11