1 Introduction to Zero Downtime Migration

Learn about the problems Zero Downtime Migration can help you solve, and its architecture, requirements, and supported configurations.

The following topics contain information you need to know before you install and use Zero Downtime Migration.

About Zero Downtime Migration

Zero Downtime Migration gives you a quick and easy way to move on-premises databases and Oracle Cloud Infrastructure Classic instances to Oracle Cloud Infrastructure, Oracle Exadata Database Service on Dedicated Infrastructure, and Oracle Exadata Database Service on Cloud@Customer without incurring any significant downtime, by leveraging technologies such as Oracle Data Guard.

Zero Downtime Migration uses mechanisms such as backing up the source database to Oracle Cloud Infrastructure Object Storage, creating a standby database (with Data Guard configuration, Oracle Data Guard Maximum Performance protection mode and asynchronous (ASYNC) redo transport mode) in the target environment from the backup, synchronizing the source and target databases, and switching over to the target database as the primary database.

Zero Downtime Migration enables and allows fallback capability after database migration is complete. Upon switchover, the target database running in the Oracle Cloud Infrastructure, Exadata Cloud at Customer, or Exadata Cloud Service becomes the primary database, and the on-premises becomes the standby. If there is SQL*Net connectivity between the new primary and the new standby after the switchover, the configuration continues to synchronize data from the new primary in the Oracle Cloud Infrastructure, Exadata Cloud at Customer, or Exadata Cloud Service to the new standby on-premises. However, if there is no SQL*Net connectivity there is no synchronization from new primary in the Oracle Cloud Infrastructure, Exadata Cloud at Customer, or Exadata Cloud Service to the new standby on-premises.

Zero Downtime Migration also supports offline (backup and recovery) migration. This approach uses mechanisms such as backing up the source database to Oracle Cloud Infrastructure Object Storage and instantiating a new database from this Object Storage backup to Oracle Cloud Infrastructure, Exadata Cloud at Customer, and Exadata Cloud Service. For this migration, no SQL*Net connectivity is needed between the source and target database servers

Zero Downtime Migration is compliant with Oracle Maximum Availability Architecture (MAA) and supports Oracle Database 11g Release 2 (11.2.0.4) and later database releases. Zero Downtime Migration provides a robust, flexible, and resumable migration process that is also easy to roll back. Zero Downtime Migration uses a controlled switchover method for dynamically moving database services to the new database environment in Oracle Cloud Infrastructure, Exadata Cloud at Customer, and Exadata Cloud Service. You can perform and manage a database migration of an individual database or perform database migrations at a fleet level using Zero Downtime Migration.

The server where the Zero Downtime Migration software is installed is called the Zero Downtime Migration service host. You can run one or more database migration jobs from the Zero Downtime Migration service host.

Zero Downtime Migration Capabilities

The Zero Downtime Migration service has many benefits and is highly customizable.

  • Audit capability - All useractions are audited including actions performed by the migration job.
  • Work flow customization - Work flow actions (marked by phases) can be customized with pre-useraction and post-useraction plug-ins.
  • Job subsystem - You can perform and manage database migrations at a fleet scale.
  • Job scheduler - You can schedule your migration job to run at a future point in time.
  • Pause and resume functionality - You can pause and resume your migration job if needed, which is useful to conform to a maintenance window, for example.
  • Job rerun ability - Your migration job can be re-run (resumed) from a point of failure.
  • Job pre-check - You can run pre-checks for migration tasks to prevent errors during database migration.
  • Compliance - Zero Downtime Migration is compliant with Oracle Maximum Availability Architecture best practices and supports Oracle Database 11g Release 2 (11.2.0.4.0) and later.

Supported Migration Methods

Depending on your database source and target destination, Zero Downtime Migration supports different migration methods.

Using Zero Downtime Migration to migrate your database from an on-premises or Oracle Cloud Infrastructure Classic source to Oracle Cloud Infrastructure, Exadata Cloud Service, or Exadata Cloud at Customer involves creating a backup of the source database and restoring it to the target database, followed by an Oracle Data Guard sync and switchover of the primary role from the source database to the target database

Zero Downtime Migration supports various migration methods, based on your chosen backup medium. The backup medium can be Oracle Cloud Infrastructure Object Storage, Zero Data Loss Recovery Appliance, or NFS storage.

When migrating a database to Oracle Cloud Infrastructure or Exadata Cloud Service, Object Storage is supported as the backup medium. Migration to an Exadata Cloud at Customer target can use Object Storage, Zero Data Loss Recovery Appliance, or NFS as the backup medium.

If you back up the database to Object Storage or to an NFS mount, then the Zero Downtime Migration service initiates the source database backup and restores it to Oracle Cloud Infrastructure, Exadata Cloud at Customer, and Exadata Cloud Service. The backup medium should be accessible from both the source and target environments. When backing up to Object Storage, the Zero Downtime Migration service host uses an SSH connection to the source and target database servers to install and configure the backup module software necessary to back up to and restore from Object Storage. The backup from the source database to Object Storage takes place over an RMAN channel.

If Zero Data Loss Recovery Appliance is chosen as backup medium, then you must ensure that the Zero Data Loss Recovery Appliance has a valid backup of the source database, because Zero Downtime Migration does not initiate a backup to Zero Data Loss Recovery Appliance as part of the workflow.

You must also ensure that all instances of the database are up before initiating a backup to Zero Data Loss Recovery Appliance. The duplicate database operation might fail if the backup is initiated when an instance is down.

The Zero Downtime Migration service accesses the backup in Zero Data Loss Recovery Appliance and restores it to Exadata Cloud at Customer. The Zero Data Loss Recovery Appliance access credentials and wallet location are mandatory input arguments, so that Zero Downtime Migration can handle the Zero Data Loss Recovery Appliance wallet setup at the target database.

Any transfer of redo stream between the source and the target database server, in either direction, takes place over a SQL*Net link.

Supported Migration Paths

Zero Downtime Migration supports a variety of migration paths to the Oracle Cloud Infrastructure, Exadata Cloud Service, and Exadata Cloud at Customer.

The following topics discuss supported migration paths:

Migrating an On-Premises Database to Oracle Cloud Infrastructure

You can migrate an Oracle on-premises database to Oracle Cloud Infrastructure (either virtual machine or bare metal) with Zero Downtime Migration.

Zero Downtime Migration requires that you use Oracle Cloud Infrastructure Object Storage service as the intermediate backup medium to migrate on-premises databases to Oracle Cloud Infrastructure.

Migrating an On-Premises Database to Oracle Exadata Cloud at Customer

You can migrate on-premises databases to Oracle Exadata Cloud at Customer environments with Zero Downtime Migration.

Zero Downtime Migration requires that you use Object Storage Service (OSS), Zero Data Loss Recovery Appliance (ZDLRA), or a Network File System (NFS) as the intermediate backup medium to migrate on-premises databases to Oracle Exadata Cloud at Customer environments.

Migrating an Oracle Cloud Infrastructure Classic Database to Oracle Cloud Infrastructure

You can migrate a database in Oracle Cloud Infrastructure Classic to the Oracle Cloud Infrastructure (either virtual machine or bare metal) with Zero Downtime Migration.

Zero Downtime Migration requires that you use Oracle Cloud Infrastructure Object Storage service as the intermediate backup medium to migrate a database in Oracle Cloud Infrastructure Classic to the Oracle Cloud Infrastructure.

Migrating an On-Premises Database to Exadata Cloud Service

You can migrate an Oracle on-premises database to Exadata Cloud Service with Zero Downtime Migration.

Zero Downtime Migration requires that you use Oracle Cloud Infrastructure Object Storage service as the intermediate backup medium to migrate on-premises databases to Oracle Cloud Infrastructure.

Supported Configurations

Learn about the configurations and deployments supported by Zero Downtime Migration in this release.

Zero Downtime Migration currently supports the platforms, database architectures, and database versions discussed in the following topics.

Supported Platforms

Zero Downtime Migration supports the following platforms for the service host and the migration source and target database servers.

Zero Downtime Migration Service Host - Supported Platforms

The Zero Downtime Migration service host can be configured on Oracle Linux 7 or later releases.

You can deploy the Zero Downtime Migration service on a standalone server on-premises or on a standalone Linux server (bare metal or virtual machine) in the Oracle Cloud. Oracle Linux is the supported platform for the Zero Downtime Migration service node.

Note that the Zero Downtime Migration service host can be shared with other applications for other purposes; however, no Oracle Grid Infrastructure instance should be running on the Zero Downtime Migration service host.

Source and Target Database Servers - Supported Platforms

Linux-x86-64 is the supported platform for migration source and target database servers.

Supported Database Versions for Migration

Zero Downtime Migration supports most Oracle Database versions available on Oracle Cloud Infrastructure, Exadata Cloud at Customer, and Exadata Cloud Service.

The following Oracle Database versions can be migrated using Zero Downtime Migration.

  • Oracle Database 11g Release 2 (11.2.0.4)
  • Oracle Database 12c Release 1 (12.1.0.2)
  • Oracle Database 12c Release 2 (12.2.0.1)
  • Oracle Database 18 Release 3 (18.3)
  • All subsequent Oracle Database releases

Because Zero Downtime Migration leverages Oracle Data Guard, you must have the same operating system and database version on both source and target.

Note:

Zero Downtime Migration does not support cross-edition migration. Zero Downtime Migration cannot be used to migrate an Enterprise edition database to a Standard edition database, and vice versa.

Supported Database Architectures for Migration

Zero Downtime Migration supports Oracle Database Single-Instance, Oracle RAC One Node, and Oracle Real Application Clusters (RAC) databases.

Zero Downtime Migration supports the following database architecture implementations.

  • Oracle Database Single-Instance, which can be migrated to a single-instance or Oracle RAC database target
  • Oracle RAC One Node, which can be migrated to an Oracle RAC database target
  • Oracle RAC, which can be migrated to an Oracle RAC database target

Supported Backup Locations

Zero Downtime Migration supports the best performing and most popular backup mediums.

Depending on your target environment, Zero Downtime Migration supports the following backup mediums.

  • Object Storage Service (OSS)
  • Zero Data Loss Recovery Appliance (ZDLRA)
  • External Backup Location (NFS)

Refer to the product documentation for your chosen backup medium for information about creating backups and object stores.

Zero Downtime Migration Security Provisions

Zero Downtime Migration permissions and ownership of files and directories, and handling of configurations for security features, are equivalent to those of Oracle Database.

Zero Downtime Migration installs in a location, named ZDM_HOME, that is structured similarly to the Oracle home directory, ORACLE_HOME, for Oracle Database. The permissions and ownership of files and directories in the ZDM_HOME follow the same conventions as that of a database ORACLE_HOME.

Zero Downtime Migration also creates a base directory structure for storing Zero Downtime Migration configuration files, logs, and other artifacts, named ZDM_BASE, that is similar to an Oracle base directory, ORACLE_BASE, that is associated with an Oracle home. The structure, owners, and permissions of directories and files in ZDM_BASE are similar to that of an ORACLE_BASE.

You do not need to do any additional steps to ensure security the of the Zero Downtime Migration configuration because the Zero Downtime Migration configuration is designed to be secure out of the box.

Zero Downtime Migration is configured to accept JMX connections only from the local host, and to listen on the loopback address for HTTP connections. Zero Downtime Migration operations can only be performed by the operating system user that installed the product.

SSH connectivity from the Zero Downtime Migration host to the on premise source node and the cloud target node is required. You must provide the SSH key file location as an input for a migration job, and the existence of this file is expected for the duration of the migration job. You must manage the security of the directories and files where these key files are located.

You can modify the communication ports when there is a port conflict with another application. Note that access to these ports are configured only from within the Zero Downtime Migration host. You can change the RMI and HTTP port properties in the file $ORACLE_BASE/crsdata/<hostname>/rhp/conf/standalone_config.properties.

The properties are:

  • RMI port - oracle.jwc.rmi.port=8895
  • HTTP port - oracle.jwc.http.port=8896

Bounce the Zero Downtime Migration server after changing the properties.

When Zero Downtime Migration operations require passwords, prompts are given for password entry. Passwords are encrypted and stored in the Zero Downtime Migration database. Provided passwords are not expected to change for the duration of a migration job.

From an operation perspective, Zero Downtime Migration follows the guidelines in Oracle Database Security Guide for handling source and target database configurations for migration, such as Oracle Wallets, Transparent Data Encryption, and so on.

Zero Downtime Migration Database Server Access

The Zero Downtime Migration service host needs to access the source and target database servers during a database migration.

To perform the migration, the Zero Downtime Migration service host requires either root user or SSH key-based access to one of the source database servers, and the Zero Downtime Migration service host requires SSH key-based access to one of the target database servers. If you are migrating an Oracle RAC database, providing access to one of the Oracle RAC nodes is adequate. The Zero Downtime Migration service host copies the software needed for migration to the source and target servers and cleans it up at the end of the operation.

An SSH private key is required to establish SSH connections. This generated key must not use a passphrase. You can create and add a new SSH key to your existing deployment using the Oracle Cloud Service Console.

Target Placeholder Database Environment

Zero Downtime Migration requires that a placeholder database target environment be configured using Oracle Cloud Infrastructure Console, and the placeholder database should exist in open mode.

You have complete control over the configuration of the placeholder database target environment, so you can set up and configure it as required for your needs. The Zero Downtime Migration service host restores the source database to this placeholder database target environment. Note that the placeholder database must be set up with the same database version as the source database and the same or higher patch level as the source database.

The database parameters for the target database, including SGA parameters, should be set as needed. These settings are maintained during the migration, and the migrated database runs with this same configuration. Any modifications to database parameters can be performed after the migration.

If the target database environment is at a higher patch level than the source database, you must run the datapatch utility on the target database as a post-migration task. For example, if your source database is at Oct 2018 PSU/BP and the target is at Jan 2019 PSU/BP), you must run the datapatch utility.

The SYS password specified should match that of source database.

The name of the provisioned database must match one of the following patterns, based on the target platform.

  • For Exadata Cloud at Customer or Exadata Cloud Service targets, Zero Downtime Migration drops the placeholder database and recreates a database in the target environment with the same db_name as that of source database, using the backup and the db_unique_name parameter specified in the response file parameter, TGT_DB_UNIQUE_NAME. The target database db_unique_name parameter value must be unique to ensure that Oracle Data Guard can identify the target as a different database from the on-premises primary database. Therefore, the value specified in TGT_DB_UNIQUE_NAME should be different from that of source database's db_unique_name.
  • For virtual machine or bare metal targets, when using the Oracle Data Guard migration method, create the target database with a different db_name from that of the source database. This value must be specified as the parameter TGT_DB_UNIQUE_NAME in the response file. During standby creation, Zero Downtime Migration replaces the placeholder database data files with the data files restored from the object store backup. Zero Downtime Migration updates the db_name of the target to be the same as that of the source.

Once the migration is complete, the target database is accessible using Oracle Database Cloud Service console, and you can manage the database with SRVCTL commands using the db_unique_name value for the target database.

Any modifications to database parameters can be performed after the migration.

Zero Downtime Migration Operational Phases

The Zero Downtime Migration service defines the migration process in units of operational phases.

Zero Downtime Migration auto computes the migration workflow using defined operational phases based on configured input parameters, such as the target platform, backup medium, and so on. You can customize the workflow by inserting custom plug-ins on each of the operational phases. The Zero Downtime Migration service lets you pause and resume the migration workflow at any chosen operational phase.

Migration workflow-associated phases for a given operation can be listed. Phases that are performed on the source database server are listed with a _SRC suffix, and the phases associated with the target database server are listed with a _TGT suffix.