Oracle Cloud Infrastructure Documentation

Overview of Exadata Cloud@Customer Gen1 to Out-of-Place Cloud Upgrade to Oracle Exadata Database Service on Cloud@Customer Gen2 Infrastructure

Gen1 is the first generation of Exadata Database Service on Cloud@Customer, which is deployed in conjunction with Gen1 Oracle Cloud At Customer (OCC) as Control Plane deployed in the customer data center. Oracle Exadata Database Service on Cloud@Customer Gen2 is managed from Oracle Cloud Infrastructure (OCI) Control Plane, which runs in OCI public cloud.

Out-of-Place Cloud Upgrade to Exadata Database Service on Cloud@Customer Gen2 Infrastructure: If you are running Exadata Cloud@Customer Gen1 on X6 or X7 infrastructure, with this offering Oracle will replace Gen1 X6 or X7 infrastructure with new Gen2 Exadata Cloud@Customer Infrastructure, and provide instructions to use Oracle Zero Downtime Migration (ZDM) to migrate your databases on the Exadata Cloud@Customer Gen1 platform to Exadata Cloud@Customer Gen2 platform. Replacing your Exadata Cloud@Customer Gen1 X6 or X7 infrastructure and migrating your databases to the Exadata Cloud@Customer Gen2 platform is called an out-of-place cloud upgrade.

Parent topic: How-to Guides

Scope for Exadata Cloud@Customer Gen1 to Gen2 Out-of-Place Cloud Upgrade

  • Exadata Cloud@Customer X6 and X7 System Shapes are eligible for the out-of-place upgrade.
  • Databases on Exadata Cloud@Customer Gen1 which participate in a Data Guard configuration are supported by migration. In this case, the primary should be migrated to Exadata Cloud@Customer Gen2 using the regular procedure. Once migration is done, the Data Guard configuration should be set up on the Exadata Cloud@Customer Gen2 side using the regular Gen2 procedure.

  • Upgrade from Exadata Cloud@Customer Gen1 to Gen2 is done only when the software versions are compatible on the source and target systems.

    • Oracle Database software: The source and target must be at the same major version. For example, both the source and target must be at version 19c. However, the target can have a higher patch level than the source. For example, the patch versions can be 19.3 for the source and 19.8 for the target. The corresponding equivalence for 12.2 is, both source and the target must be at Oracle Database software version 12.2.0.1, but the patch levels can be 2019JulyRU on the source and 2020OctRU on the target.
    • Non-Container Database (CDB) to non-CDB.
    • Multitenant deployment (CDB/PDB) to Multitenant deployment (CDB/PDB).
    • Single-instance Oracle Database: After migration, single-instance database source will be converted to Oracle Real Application Clusters (Oracle RAC) database on the target.
  • Permitted differences in software versions include:
    • Oracle Grid Infrastructure
    • Exadata software
    • Guest VM operating system
    • DBaaS tools
  • Oracle Databases created on Exadata Cloud@Customer Gen1 using backend tools, dbaasapi and dbaascli, are supported as well besides Oracle Databases created using the Gen1 Console.
  • All supported versions of Oracle Database on Exadata Cloud@Customer Gen1 are supported and will be migrated to the same major version on the target. The Gen2 environment will be on the latest supported version of Exadata Cloud@Customer Gen2 for the Guest VM operating system and Oracle Grid Infrastructure.

Note that the following are not in scope for the out-of-place cloud upgrade to new Gen2 hardware:

  • Exadata Cloud@Customer Gen1 deployment using Exadata Cloud@Customer Gen1 features not yet available on Gen2 are not expected to use the upgrade procedures until the relevant feature or equivalent is available on Gen2.
  • Only Exadata Cloud@Customer upgrade is in scope as part of the procedure here. Upgrade or migration of OCC itself is not in the scope.
  • You can reverse the upgrade until both the primary and secondary hardware is at your site. Loss of data is possible depending on the application usage and cutover time. Once the Exadata Cloud@Customer Gen1 hardware is shipped back to Oracle, you cannot reverse the upgrade and you cannot revert to Exadata Cloud@Customer Gen1 as well.

Hardware and Software Required for Out-of-Place Cloud Upgrade to New Oracle Exadata Database Service on Cloud@Customer Gen2 Infrastructure

Review this checklist to prepare for the out-of-place cloud upgrade to new Gen2 infrastructure:

  • Setup Exadata Cloud@Customer Gen2 Environment

    A functioning base Exadata Cloud@Customer Gen2 deployment is a pre-requisite for starting any Exadata Cloud@Customer Gen1 to Gen2 out-of-place upgrade.

    For more information to setup your Gen2 Exadata Cloud@Customer, see Preparing for Exadata Cloud@Customer.

  • Setup Hardware to Migrate Oracle Databases using Oracle Zero Downtime Migration (ZDM). For more information, see Prepare a Host for Zero Downtime Migration Software Installation

  • Configure network
    • Provide network access path from the Exadata Cloud@Customer Gen1 servers and the Gen2 servers to the ZDM servers used for the upgrade.
    • Provide network access and SSH access from the ZDM server to the respective Exadata Cloud@Customer infrastructure.
    • For any client access to the target databases, ensure that a network path is available from the client host to the new Exadata Cloud@Customer Gen2 deployed databases.
  • Software
    • The upgrade will require minimum versions of the software stack so prior to the upgrade, install the appropriate version of Oracle Grid Infrastructure on the target Exadata Cloud@Customer Gen2 infrastructure.
    • Oracle Database versions supported on Exadata Cloud@Customer Gen1 will continue to be supported. On the target Gen2 infrastructure, install appropriate versions of the Oracle Database software and the one-off patches that exist in the source database.
    • Complete all requirements for ZDM servers in terms of installation, configuration, network access, and SSH access.
  • Security
    • Exadata Cloud@Customer Gen2 does not use Oracle Advanced Support Gateway Security (OASG) so cannot request OASG logs.
  • Ensure that automatic backup is not configured on the Gen2 target prior to migration.

Using Oracle Zero Downtime Migration (ZDM) to Migrate Oracle Databases

Use ZDM to migrate Oracle databases from Exadata Cloud@Customer Gen1 to Oracle Exadata Database Service on Cloud@Customer Gen2 infrastructure.

To familiarize yourself with the features of ZDM, see Setting Up Zero Downtime Migration Software. As the first step, download, install and configure ZDM on the host identified for the ZDM server.

Zero Downtime Migration supports both online and offline (backup and recovery) migration. For Exadata Cloud@Customer upgrade from Gen1 to Gen2, it is recommended to use ZDM Physical Migration. Specifically, it is recommended to use Online Migration with Direct Data Transfer (online physical migration (MIGRATION_METHOD=ONLINE_PHYSICAL) using direct data transfer (DATA_TRANSFER_MEDIUM=DIRECT). Online Migration with Direct Data Transfer is available with Zero Downtime Migration 21.2 and supports direct data transfer for the physical migration methodology. This new feature allows users to avoid using an intermediate store for backups (normally NFS or the OCI Object Storage). ZDM leverages either active database duplication (for 11.2 databases) or restore from service (for 12+ databases). You can use this method to do migrate your Exadata Cloud@Customer Gen1 databases to Exadata Cloud@Customer Gen2. Examples of the command-line and response files are provided below for reference.

For more information, see:

  • Introduction to Zero Downtime Migration
  • Preparing for Database Migration
  • Migrating Your Database with Zero Downtime Migration

Example 5-4 Active Duplicate

zdmcli migrate database -sourcedb z19tgt1 -sourcenode scaqae03client01vm06 -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/giusr/.ssh/id_gen1vm -srcarg3 sudo_location:/usr/bin/sudo -targetnode tgt1 -rsp /home/giusr/activeduplicate_zdm_online_19c.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/giusr/.ssh/dbaas_sshkey.priv -tgtarg3 sudo_location:/usr/bin/sudo -schedule NOW -tdekeystorepasswd
ZDM_GET_SRC_INFO .............. COMPLETED
ZDM_GET_TGT_INFO .............. COMPLETED
ZDM_PRECHECKS_SRC ............. COMPLETED
ZDM_PRECHECKS_TGT ............. COMPLETED
ZDM_SETUP_SRC ................. COMPLETED
ZDM_SETUP_TGT ................. COMPLETED
ZDM_PREUSERACTIONS ............ COMPLETED
ZDM_PREUSERACTIONS_TGT ........ COMPLETED
ZDM_VALIDATE_SRC .............. COMPLETED
ZDM_VALIDATE_TGT .............. COMPLETED
ZDM_DISCOVER_SRC .............. COMPLETED
ZDM_COPYFILES ................. COMPLETED
ZDM_PREPARE_TGT ............... COMPLETED
ZDM_SETUP_TDE_TGT ............. COMPLETED
ZDM_DUPLICATE_TGT ............. COMPLETED
ZDM_FINALIZE_TGT .............. COMPLETED
ZDM_CONFIGURE_DG_SRC .......... COMPLETED
ZDM_SWITCHOVER_SRC ............ COMPLETED
ZDM_SWITCHOVER_TGT ............ COMPLETED
ZDM_POST_DATABASE_OPEN_TGT .... COMPLETED
ZDM_DATAPATCH_TGT ............. COMPLETED
ZDM_MANIFEST_TO_CLOUD ......... COMPLETED
ZDM_POST_MIGRATE_TGT .......... COMPLETED
ZDM_POSTUSERACTIONS ........... COMPLETED
ZDM_POSTUSERACTIONS_TGT ....... COMPLETED
ZDM_CLEANUP_SRC ............... COMPLETED
ZDM_CLEANUP_TGT ............... COMPLETED

Example 5-5 Active Duplicate Response File

TGT_DB_UNIQUE_NAME=z19tgt1_uniq2
MIGRATION_METHOD=ONLINE_PHYSICAL
DATA_TRANSFER_MEDIUM=DIRECT
PLATFORM_TYPE=EXACC
SRC_HTTP_PROXY_URL=
SRC_HTTP_PROXY_PORT=
SRC_CONFIG_LOCATION=
SRC_BASTION_HOST_IP=
SRC_BASTION_PORT=
SRC_BASTION_USER=
SRC_BASTION_IDENTITY_FILE=
SRC_HOST_IP=
SRC_TIMEZONE=
SRC_OSS_PROXY_HOST=
SRC_OSS_PROXY_PORT=
SRC_SSH_RETRY_TIMEOUT=
SRC_PDB_NAME=
SRC_DB_LISTENER_PORT=
TGT_HTTP_PROXY_URL=
TGT_HTTP_PROXY_PORT=
TGT_CONFIG_LOCATION=
TGT_BASTION_HOST_IP=
TGT_BASTION_PORT=
TGT_BASTION_USER=
TGT_BASTION_IDENTITY_FILE=
TGT_HOST_IP=
TGT_SSH_TUNNEL_PORT=
TGT_SSH_RETRY_TIMEOUT=
TGT_OSS_PROXY_HOST=
TGT_OSS_PROXY_PORT=
TGT_DATADG=
TGT_REDODG=
TGT_RECODG=
TGT_DATAACFS=
TGT_REDOACFS=
TGT_RECOACFS=
BACKUP_PATH=
HOST=
OPC_CONTAINER=
SRC_ZDLRA_WALLET_LOC=
TGT_ZDLRA_WALLET_LOC=
ZDLRA_CRED_ALIAS=
NONCDBTOPDB_CONVERSION=FALSE
NONCDBTOPDB_SWITCHOVER=TRUE
SKIP_FALLBACK=TRUE
TGT_RETAIN_DB_UNIQUE_NAME=
TGT_SKIP_DATAPATCH=FALSE
MAX_DATAPATCH_DURATION_MINS=
DATAPATCH_WITH_ONE_INSTANCE_RUNNING=
SHUTDOWN_SRC=
SKIP_SRC_SERVICE_RETENTION=
SRC_RMAN_CHANNELS=6
TGT_RMAN_CHANNELS=16
ZDM_LOG_OSS_PAR_URL=
ZDM_BACKUP_FULL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_INCREMENTAL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_DIFFERENTIAL_SRC_MONITORING_INTERVAL=10
ZDM_CLONE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RESTORE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RECOVER_TGT_MONITORING_INTERVAL=10
ZDM_BACKUP_RETENTION_WINDOW=
ZDM_BACKUP_TAG=
ZDM_USE_EXISTING_BACKUP=
ZDM_OPC_RETRY_WAIT_TIME=
ZDM_OPC_RETRY_COUNT=
ZDM_SRC_TNS_ADMIN=
ZDM_CURL_LOCATION=
ZDM_USE_EXISTING_UNDO_SIZE=
ZDM_SKIP_DG_CONFIG_CLEANUP=
ZDM_RMAN_COMPRESSION_ALGORITHM=LOW
ZDM_SRC_DB_RESTORE_SERVICE_NAME=
ZDM_RMAN_DIRECT_METHOD=ACTIVE_DUPLICATE

Example 5-6 Restore from Service

zdmcli migrate database -sourcedb z12tgt1s -sourcenode scaqae03client01vm06 -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/giusr/.ssh/id_gen1vm -srcarg3 sudo_location:/usr/bin/sudo -targetnode tgt1 -rsp /home/giusr/dir_zdm_online_121_sidb.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/giusr/.ssh/dbaas_sshkey.priv-tgtarg3 sudo_location:/usr/bin/sudo -schedule NOW -tdekeystorepasswd"
ZDM_GET_SRC_INFO .............. COMPLETED
ZDM_GET_TGT_INFO .............. COMPLETED
ZDM_PRECHECKS_SRC ............. COMPLETED
ZDM_PRECHECKS_TGT ............. COMPLETED
ZDM_SETUP_SRC ................. COMPLETED
ZDM_SETUP_TGT ................. COMPLETED
ZDM_PREUSERACTIONS ............ COMPLETED
ZDM_PREUSERACTIONS_TGT ........ COMPLETED
ZDM_VALIDATE_SRC .............. COMPLETED
ZDM_VALIDATE_TGT .............. COMPLETED
ZDM_DISCOVER_SRC .............. COMPLETED
ZDM_COPYFILES ................. COMPLETED
ZDM_PREPARE_TGT ............... COMPLETED
ZDM_SETUP_TDE_TGT ............. COMPLETED
ZDM_RESTORE_TGT ............... COMPLETED
ZDM_RECOVER_TGT ............... COMPLETED
ZDM_FINALIZE_TGT .............. COMPLETED
ZDM_CONFIGURE_DG_SRC .......... COMPLETED
ZDM_SWITCHOVER_SRC ............ COMPLETED
ZDM_SWITCHOVER_TGT ............ COMPLETED
ZDM_POST_DATABASE_OPEN_TGT .... COMPLETED
ZDM_DATAPATCH_TGT ............. COMPLETED
ZDM_MANIFEST_TO_CLOUD ......... COMPLETED
ZDM_POST_MIGRATE_TGT .......... COMPLETED
ZDM_POSTUSERACTIONS ........... COMPLETED
ZDM_POSTUSERACTIONS_TGT ....... COMPLETED
ZDM_CLEANUP_SRC ............... COMPLETED
ZDM_CLEANUP_TGT ............... COMPLETED

Example 5-7 Restore from Service Response File

TGT_DB_UNIQUE_NAME=z12tgt1s_uniq
MIGRATION_METHOD=ONLINE_PHYSICAL
DATA_TRANSFER_MEDIUM=DIRECT
PLATFORM_TYPE=EXACC
SRC_HTTP_PROXY_URL=
SRC_HTTP_PROXY_PORT=
SRC_CONFIG_LOCATION=
SRC_BASTION_HOST_IP=
SRC_BASTION_PORT=
SRC_BASTION_USER=
SRC_BASTION_IDENTITY_FILE=
SRC_HOST_IP=
SRC_TIMEZONE=
SRC_OSS_PROXY_HOST=
SRC_OSS_PROXY_PORT=
SRC_SSH_RETRY_TIMEOUT=
SRC_PDB_NAME=
SRC_DB_LISTENER_PORT=
TGT_HTTP_PROXY_URL=
TGT_HTTP_PROXY_PORT=
TGT_CONFIG_LOCATION=
TGT_BASTION_HOST_IP=
TGT_BASTION_PORT=
TGT_BASTION_USER=
TGT_BASTION_IDENTITY_FILE=
TGT_HOST_IP=
TGT_SSH_TUNNEL_PORT=
TGT_SSH_RETRY_TIMEOUT=
TGT_OSS_PROXY_HOST=
TGT_OSS_PROXY_PORT=
TGT_DATADG=
TGT_REDODG=
TGT_RECODG=
TGT_DATAACFS=
TGT_REDOACFS=
TGT_RECOACFS=
BACKUP_PATH=
HOST=
OPC_CONTAINER=
SRC_ZDLRA_WALLET_LOC=
TGT_ZDLRA_WALLET_LOC=
ZDLRA_CRED_ALIAS=
NONCDBTOPDB_CONVERSION=FALSE
NONCDBTOPDB_SWITCHOVER=TRUE
SKIP_FALLBACK=TRUE
TGT_RETAIN_DB_UNIQUE_NAME=
TGT_SKIP_DATAPATCH=FALSE
MAX_DATAPATCH_DURATION_MINS=
DATAPATCH_WITH_ONE_INSTANCE_RUNNING=
SHUTDOWN_SRC=
SKIP_SRC_SERVICE_RETENTION=
SRC_RMAN_CHANNELS=6
TGT_RMAN_CHANNELS=16
ZDM_LOG_OSS_PAR_URL=
ZDM_BACKUP_FULL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_INCREMENTAL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_DIFFERENTIAL_SRC_MONITORING_INTERVAL=10
ZDM_CLONE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RESTORE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RECOVER_TGT_MONITORING_INTERVAL=10
ZDM_BACKUP_RETENTION_WINDOW=
ZDM_BACKUP_TAG=
ZDM_USE_EXISTING_BACKUP=
ZDM_OPC_RETRY_WAIT_TIME=
ZDM_OPC_RETRY_COUNT=
ZDM_SRC_TNS_ADMIN=
ZDM_CURL_LOCATION=
ZDM_USE_EXISTING_UNDO_SIZE=
ZDM_SKIP_DG_CONFIG_CLEANUP=
ZDM_RMAN_COMPRESSION_ALGORITHM=LOW
ZDM_SRC_DB_RESTORE_SERVICE_NAME=
ZDM_RMAN_DIRECT_METHOD=

During Out-of-Place Cloud Upgrade to New Oracle Exadata Database Service on Cloud@Customer Gen2 Infrastructure

Monitoring: Oracle will monitor the Oracle Exadata Database Service on Cloud@Customer Gen2 installation from the beginning of the installation just like a regular Gen2 install.

Backups: Backups are done from the Exadata Cloud@Customer Gen1 VM cluster and they will continue to work during the upgrade. Post-migration to Oracle Exadata Database Service on Cloud@Customer Gen2, backups to the Gen1 Oracle Cloud At Customer (OCC) Object Storage Service (OSS) is not allowed and you must use supported backup methods for Oracle Exadata Database Service on Cloud@Customer Gen2.

Post Out-of-Place Cloud Upgrade to New Oracle Exadata Database Service on Cloud@Customer Gen2 Infrastructure

The upgrade will move your resources into Oracle Exadata Database Service on Cloud@Customer Gen 2 Cloud Control Plane and onto the new generation hardware.

Use the Gen2 OCI Console to manage your Oracle Exadata Database Service on Cloud@Customer Gen2 infrastructure, clusters, databases, and users/groups.

The software stack is upgraded to newer versions, for example, as follows:

  • Exadata software: 19.x or later
  • Oracle Grid Infrastructure: 19c
  • Guest VM operating system: Oracle Linux 7
  • DBaaS Tools: 20.x
  • CSI: You will have a new CSI for your Cloud account.
Note

The software stack will be upgraded to the latest versions at that point in time when you perform Out-of-Place Cloud Upgrade to New Gen2 Hardware.

Patching: The infrastructure patching process and notification are different in Gen2. For more information, see Maintaining an Exadata Cloud@Customer System.

Note

Post-migration to Exadata Cloud@Customer Gen2, Oracle recommends using supported backup methods for Exadata Cloud@Customer Gen2. It's your responsibility to manually manage any backups to the Gen1 Oracle Cloud At Customer (OCC) Object Storage Service (OSS), and Oracle does not offer it through the OCI Console, API, or CLI.

Best Practices for Out-of-Place Cloud Upgrade to New Oracle Exadata Database Service on Cloud@Customer Gen2 Infrastructure

For the purpose of the upgrade, the recommended tool to use is Oracle Zero Downtime Migration (ZDM).

Some recommended best practices in the context of ZDM's usage for the Gen1 to Gen2 upgrade are:

  • While all methods of Physical migration are supported, it is recommended to use Online Migration with Direct Data Transfer.
    Note

    It is not recommended to use either Gen1 Oracle Cloud At Customer OSS or OCI Object Storage for this migration.
  • Set ZDM_RMAN_COMPRESSION_ALGORITHM to LOW.
  • The target database Oracle Home must be at the same patch level or at a higher patch level as the source.
  • The target database Oracle Home must have all the one-off patches as the source Oracle Home.
  • Perform a validation run before the actual run.
  • For a CDB source database, it is required to have all the PDBs on the source to be online.