1 Introduction to Zero Downtime Migration

Learn about how Zero Downtime Migration works, and its requirements and supported configurations.

About Zero Downtime Migration

With Zero Downtime Migration, you can migrate Oracle databases from on premises, Oracle Cloud Infrastructure Classic, or from one Oracle Cloud Infrastructure region to another. You can move your databases to co-managed or Autonomous Database services in the cloud, or any Exadata Database Machine in the cloud or on premises.

Zero Downtime Migration provides a robust, flexible, and resumable migration process that is also easy to roll back. Zero Downtime Migration integrates Oracle Maximum Availability Architecture (MAA) and supports Oracle Database 11g Release 2 (11.2.0.4) and later database releases.

You can perform and manage a database migration of an individual database or perform database migrations at a fleet level. Leveraging technologies such as Oracle Data Guard, Oracle Recovery Manager (RMAN), Oracle GoldenGate, and Oracle Data Pump, you can migrate databases online or offline.

The Zero Downtime Migration software is a service with a command line interface that you install and run on a host that you provision. 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

  • Audit capability - All custom user actions are audited including actions performed by the migration job.
  • Work flow customization - You can customize the migration work flow (marked by operational phases) with your own scripts, which can be run before or after any phase in the work flow.
  • 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 termination - You can terminate a running migration job, rather than waiting for it to complete.
  • 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.

Migration Methods

Zero Downtime Migration supports both online and offline migration, and can perform both physical and logical migrations. Consider the following advantages of each migration method to choose which one is right for your needs.

  • Online migration methods incur zero or minimal downtime (typically less than 15 minutes) and can leverage either physical or logical migration methods.

  • Offline migration methods will incur downtime on the source database as part of the migration process. It can leverage either physical or logical migration methods.

    Note that the only available method for migrating Oracle Database Standard Edition is the offline migration method.

  • Physical migration methods:

    • Use Oracle Data Guard and RMAN to perform migrations

    • Allow you to convert a non-multitenant (non-CDB) source database to a multitenant (CDB) target database

  • Logical migration methods:

    • Use Oracle Data Pump and, for online migrations, Oracle GoldenGate Microservices

    • Include integration with the Cloud Premigration Advisor Tool (CPAT), which a) warns you about any features used by your database that aren't supported in the target cloud environment, and b) makes suggestions for remedial changes and/or parameters to use for the Data Pump export and import operations

The migration methods are described in the following topics.

Physical Migrations with Zero Downtime Migration

Online and offline physical migrations using Zero Downtime Migration are described in the following topics:

Physical Online Migration

Zero Downtime Migration harnesses Oracle Data Guard to perform an online physical migration.

A Zero Downtime Migration online physical migration does the following:

  • Backs up the source database to the specified data transfer medium
  • Instantiates a standby database from this backup to the target environment
  • Configures Data Guard with Maximum Performance protection mode and asynchronous (ASYNC) redo transport mode
  • Synchronizes the source and target databases
  • Switches over to the target database as the new primary database with minimum downtime

Upon switchover, the target database becomes the primary database, and the source database 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 (ship redo) from the new primary to the new standby source database. This configuration makes it possible to perform a rollback with minimal downtime, if you need to switch the primary back to the original source database.

However, if there is no SQL*Net connectivity between the new primary and the new standby after the switchover, there is no data synchronization (ship redo) from the new primary to the new standby on the source database. With this configuration you cannot fall back to the original source database.

Note that Transparent Data Encryption (TDE) is enabled on Oracle databases in the Oracle Cloud by default. Zero Downtime Migration handles the encryption of your target database, even if TDE is not enabled on the source Oracle database. However, once the switchover phase of the migration has taken place, the redo logs that the new primary database in the Oracle Cloud sends to the new standby database (the source) are encrypted. Therefore, if you decide to switch back and role swap again, making the source database the primary again and the database in the Oracle Cloud the standby, the source database will not be able to read the newly encrypted changed blocks applied by the redo logs unless TDE is enabled on the source database.

Physical Offline Migration

Zero Downtime Migration can perform a backup and restore operation to achieve an offline physical migration.

A Zero Downtime Migration offline physical migration does the following:

  • Backs up the source database to the specified data transfer medium
  • Instantiates a new database from this backup to the target environment

The offline migration method is similar to cloning a database. The target database has no relationship to the source, so there is no data synchronization or fallback capability. No SQL*Net connectivity is needed between the source and target database servers.

Supported Physical Migration Paths

Zero Downtime Migration supports a variety of physical migration paths.

  • 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.

    In this scenario, Oracle Cloud Infrastructure Object Storage service is the supported intermediate data transfer medium for storing backups.

  • 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.

    In this scenario, Object Storage Service (OSS), Zero Data Loss Recovery Appliance (ZDLRA), or a Network File System (NFS) are the supported data transfer media for storing backups.

  • 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.

    In this scenario, Oracle Cloud Infrastructure Object Storage service is the supported intermediate data transfer medium for storing backups.

  • On-Premises Database to Exadata Cloud Service

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

    In this scenario, Oracle Cloud Infrastructure Object Storage service is the supported intermediate data transfer medium for storing backups.

  • Oracle Cloud Infrastructure Database to Another Oracle Cloud Infrastructure Region

    You can migrate a database from one Oracle Cloud Infrastructure region to another Oracle Cloud Infrastructure region with Zero Downtime Migration. For example, you can move a database from the phoenix region to the frankfurt or ashburn region.

    In this scenario, Oracle Cloud Infrastructure Object Storage service is the supported intermediate data transfer medium for storing backups.

  • On-Premises Database to On-Premises Exadata Database Machine

    You can migrate on-premises databases to Oracle Exadata Database Machine with Zero Downtime Migration.

    In this scenario, Zero Data Loss Recovery Appliance (ZDLRA) or a Network File System (NFS) are the supported intermediate data transfer media for storing backups

Supported Data Transfer Media for Physical Migrations

Part of the Zero Downtime Migration process involves creating a backup of the source database and restoring it to the target database. Zero Downtime Migration supports Oracle Cloud Infrastructure Object Storage, Zero Data Loss Recovery Appliance, or NFS storage backup media, depending on your target environment.

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

Oracle Cloud Infrastructure Object Storage

Object Storage is supported as a backup medium when migrating a database to Oracle Cloud Infrastructure, Exadata Cloud Service, or Exadata Cloud at Customer.

If you back up the database to Object Storage, then the Zero Downtime Migration service initiates the source database backup and restores it to the target environment, so Object Storage must be accessible from both the source and target environments.

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.

Zero Data Loss Recovery Appliance

Zero Data Loss Recovery Appliance is supported as a backup medium when migrating a database to an Exadata Cloud at Customer target.

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 parameters, 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.

Refer to the Zero Data Loss Recovery Appliance documentation for information about creating backups.

Network File System (NFS)

NFS is supported as a backup medium when migrating a database to an Exadata Cloud at Customer target.

If you choose to back up the database to an NFS mount, then the Zero Downtime Migration service initiates the source database backup and restores it to the Exadata Cloud at Customer target environment. The NFS should be accessible from both the source and target environments.

Supported Database Architectures for Physical Migration

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

Target Placeholder Database Environment

Zero Downtime Migration requires that you configure a placeholder database target environment before beginning the migration process. Zero Downtime Migration uses the provisioned target as a template and recreates the target during the course of migration.

You should configure the target database with the required and desired options of your native environment, because Zero Downtime Migration does not preserve this automatically during the migration.

During the migration process, the Zero Downtime Migration service host restores the source database to this placeholder database target environment by dropping the placeholder database and recreating a database in the target environment with the same db_name as that of source database.

Any database parameters for the target database, including SGA parameters, are maintained during the migration, and the migrated database runs with this same configuration.

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. You can make any modifications to database parameters after the migration.

Logical Migrations with Zero Downtime Migration

Online and offline logical migrations using Zero Downtime Migration are described in the following topics:

Logical Online Migration

Zero Downtime Migration harnesses Oracle GoldenGate and Oracle Data Pump to perform an online logical migration.

During a logical online migration, the source database remains online for client connections while data is moved to the target database, using a combination of Oracle Data Pump and Oracle GoldenGate replication.

The source database can be either a pluggable database (PDB) or a non-multitenant database.

Logical online migration involves two steps:

  • Instantiation of target database.

    Oracle Data Pump extracts data from the source database and loads it into the target database.

  • Real-time data replication between source and target databases.

    Oracle GoldenGate replicates data between the source and target databases in real-time until you choose to switch applications over to the target database.

Logical Offline Migration

Zero Downtime Migration can perform an offline logical migration using Oracle Data Pump to extract the data from the source database and load it into a target database.

Offline logical migration means that the source database is not available for clients while data is moved to the target database. When using the offline migration method, you must stop updates to the source database before you start a migration. When the migration is complete, the target database and source database do not require any direct SQL*Net connectivity between them.

Supported Logical Migration Paths

Zero Downtime Migration supports logical migration paths to a variety of target databases.

Based on your migration configuration, Zero Downtime Migration detects one of the following target database systems:

  • Autonomous Database Shared (Data Warehouse or Transaction Processing):

    The following migration methods are supported for supported Autonomous Database targets:

    • Online or offline migration using a database link
    • Online or offline migration using OCI Object Storage
  • Autonomous Database Dedicated Infrastructure (Data Warehouse or Transaction Processing):

    • Online or offline migration using OCI Object Storage
  • Co-managed Database Systems: Exadata Cloud Service, Exadata Cloud at Customer, Virtual Machine, or Bare Metal

    The following migration methods are supported for supported co-managed database targets:

    • Online or offline migration using a database link
    • Online or offline migration using OCI Object Storage
    • Offline migration using NFS
    • Offline migration using Direct Copy
    • Offline migration using Object Storage with OCI CLI

Supported Data Transfer Media for Logical Migrations

Some Zero Downtime Migration logical migration paths involve placing Oracle Data Pump dump files on storage media for transfer to the target database.

For logical migrations, supported data transfer media are:

  • Oracle Cloud Object Store

    Object Storage is supported as a Data Pump dump file storage medium for online and offline logical migrations to target Autonomous Database or co-managed databases.

  • Network File System (NFS)

    In offline logical migrations to co-managed target databases, NFS is supported as a data transfer medium.

  • Direct Copy

    Data Pump dumps are transferred directly from the source to target securely using secure copy (SCP) or RSYNC.

Data Replication

Replication migrates all data and metadata operations in transactions committed after the initial load until you resume the migration job after the Monitor Replication Lag phase. It includes inserts, deletes, and updates of data in tables within the migrated schema. Create, alter, and drop DDL operations are not replicated.

The following objects are not supported:

Zero Downtime Migration Requirements and Considerations

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 (Linux-x86-64) or later releases.

You can deploy the Zero Downtime Migration service on a standalone server on-premises or on a standalone Linux server (compute instance) in the Oracle Cloud. Oracle Linux is the supported platform for the Zero Downtime Migration service host.

Note that the Zero Downtime Migration service host can be shared with other applications for other purposes.

Source and Target Database Servers - Supported Platforms

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

Supported target systems are

  • Oracle Cloud Infrastructure co-managed databases: Exadata Cloud Service, Exadata Cloud at Customer, Virtual Machine Database System, and Bare Metal Database System

    The target co-managed database can be either a pluggable database or a non-multitenant database.

  • As a target environment only, Autonomous Database is supported platform for logical migrations. You can choose a Dedicated Infrastructure (Data Warehouse or Transaction Processing) or Shared (Data Warehouse or Transaction Processing).

    An Autonomous Database is a pluggable database in an Autonomous Container Database (ACD) deployed on an Autonomous Exadata Infrastructure (AEI) rack.

  • On-premises Exadata Database Machine

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 18c
  • Oracle Database 19c
  • Oracle Database 21c
  • All subsequent Oracle Database releases

Note:

The following notes apply only to physical migrations.

Because Zero Downtime Migration physical migrations leverage Oracle Data Guard, you must have the same operating system and database version on both source and target. However, note that, while Standard Edition databases can use Zero Downtime Migration, they must use the offline migration method which is based on a backup and restore methodology and does not leverage Data Guard.

Zero Downtime Migration physical migrations do 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.

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.

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 work flow using defined operational phases based on configured input parameters, such as the target platform, backup medium, and so on. You can customize the work flow by inserting custom plug-ins on each of the operational phases. The Zero Downtime Migration service lets you pause and resume the migration work flow at any chosen operational phase.

Migration work flow-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.

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.

ZDM_BASE and ORACLE_BASE do not allow access by group or others.

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.

For physical migrations, SSH connectivity from the Zero Downtime Migration service host to the source database server and the target database server 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 $ZDM_BASE/crsdata/zdm_service_host/rhp/conf/standalone_config.properties.

The properties are:

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

Restart the Zero Downtime Migration service 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.