The question to migrate or not to the Cloud comes more and more often now. There are some added values to go to the Cloud as analytics capabilities, scalability and flexibility, cost saving, no dedicated hardware and its related maintenance, no maintenance for patch, no worry to have about HA, DR or Data Protection. We can easily understand this. But on the other side, we can also wonder what will be the performance, what about my sensitive data, how to monitor the costs, the lock-in risk (am I married for ever or how high is the egress cost) and of course what will be the downtime of the migration. For this last point, the Oracle ZDM tool is going to help us. For some time now I have been wondering what is the easiest way and best way for customer to migrate to OCI, before hearing about Oracle Zero Downtime Migration. I wanted to have a closer look at it and test it. I would like, through this blog, to share some information I could gather about ZDM.

Oracle Cloud solutions

First of all, let’s have a quick and closer look to the Oracle Cloud Solutions available to manage my oracle databases. We are having the OCI with databases running on VM (Virtual Machine) or BM (Bare Metal) and autonomous databases. And we are having 3 offers based on Exadata : Exadata On-Premises, Exadat Cloud at Customer (ExaCC) and Exadata Cloud Service (ExaCS).

Exadata Machine on On-Premises:

  • This solution will fulfil my need for sensitive data with higher performance and availability requirements.
  • The exadata are installed in customer Data Center. The data are locally stored behind customer firewall.
  • The customer will manage every component including the HW.
  • There is no Cloud Services available.
  • This solution is based on purchased-based Model.
  • For Exadata X9M we are having 2 models. The X9M-2 with 2 sockets and the X9M-8 with 8 sockets. For example, for a X9M-8 Half Rack, I will have 2 DB servers giving a total of 384 cores, 3 storage server with a total of 98 cores, 648 TB of disk storage, 77 TB of flash storage and 4.5 TB of persistent memory. The Oracle datasheet for Exadata can be found here:
    https://www.oracle.com/a/ocom/docs/engineered-systems/exadata/exadata-x9m-2-ds.pdf
    https://www.oracle.com/a/ocom/docs/engineered-systems/exadata/exadata-x9m-8-ds.pdf

Exadata Cloud at Customer (ExaCC):

  • In this solution the Exadata will still be stored in the customer Data Center. So the data are still located on customer side behind the firewall.
  • But the customer will be only responsible to manage the Exadata VMs (DomU) and the Databases when Oracle will on its side manage the Exadata HW, firmware and hypervisor.
  • In case for Automomous Database Service subscription, Oracle will manage the full stack, that’s to say including the VMs and the DB. Customer will in that case only be responsible of his data.
  • Customer can benefit of Cloud Services.
  • Database are provisioned through the Oracle Cloud.
  • All data is encrypted and not visible to Oracle
  • The cost is based on hourly OCPU consumption and shape sizing.
  • This solution is based on subscription-based model

Exadata Cloud Service (ExaCS):

  • In this solution, the Exadata and customer’s data are stored on the Oracle’s Public Cloud.
  • The customer will in this case also be responsible to manage the Exadata VMs (DomU) and the Databases when Oracle will on its side manage the Exadata HW, firmware and hypervisor.
  • In case for Automomous Database Service subscription, Oracle will manage the full stack, that’s to say including the VMs and the DB. Customer will in that case only be responsible of his data.
  • Customer can benefit of Cloud Services.
  • The cost is based on pay-per-use model.
  • This solution is based on subscription-based model.

How can I migrate my databases to OCI?

There is several factors to take into account:

  • Database version
  • OS system and version
  • Character set
  • Among of database and indexes
  • Data Types in the on-premises database
  • Storage
  • Network bandwidth
  • Downtime length
  • Architecture CDB or Non-CDB
  • Endian format that can be found with the V$TRANSPORTABLE_PLATFORM view. OCI Database uses Linux platform (little endian)

There are then several migration methods available and that we can use:

  • DataPump (Export/Import, Tranportable, …)
  • Remote Cloning PDB or Non-CDB
  • RMAN Cross-Platform Transportable PDB, tablespace
  • RMAN Duplicate from Active Database
  • RMAN Convert Transportable Tablespace
  • SQL Developer
  • Plug/Unplug PDB or Non-CDB

And of course ZDM (Zero Downtime Migration) Oracle tool!

What is Oracle ZDM?

ZDM is Oracle’s premier solution for simplified and automated Oracle databases migration. It provides zero to negligible downtime for production system. That’s to say minimal to no production database impact during the migration. This tool will reduce the human errors.

The current version is Oracle ZDM 21.4.

Where can I migrate to with ZDM?

  • Oracle Exadata On-Premises
  • Oracle Exadata Cloud at Customer (ExaCC)
  • Oracle Exadata Cloud Service (ExaCS)
  • Oracle Database Cloud Infrastructure (BM and VM)
  • Oracle Cloud Autonomous Database (OTP and ADW)

Where can I migrate from?

  • On-Premises
  • Oracle Databases on AWS RDS (Relational Database Service)
  • Oracle Public Cloud Gen 1
  • Oracle Cloud Infrastructure (OCI)
  • Databases can be hosted on Linux, AIX and Solaris OS
  • Databases can be SI, RAC one Node or RAC Databases
  • Oracle Database Enterprise and Standard Edition
  • Non-CDB or CDB with one or more PDB

Source database version can be : 11.2.0.4, 12.1.0.2, 12.2.0.1, 18c, 19c, 21c.

ZDM will have following benefits:

  • Simple and Efficient with Oracle ZDM automated workflow
  • Highly Available
  • Flexible
  • Validation
  • Cost-Effective

Finally ZDM follows Oracle MAA (Maximum Availability Architecture) best practices with Golden Gate and Data Guard solutions. Online migration workflow will be using Recovery Manager, Data Pump and DB links.

Oracle ZDM Migration workflows

There is 7 Migration workflows we can use with ZDM. Some of those workflows are using backups.

In case backups are used, the initial backup of the source will use RMAN compression. What is nice with ZDM is that, while the migration is performed with ZDM and only in the purpose of the migration operation, Oracle Advanced Compression and Oracle Advanced Security licenses are granted and can be used for free. The advantage is that it will reduce the size of the backup, that is to say the amount of database being transported to the cloud. RMAN backups can be customized. In case we are migrating to on-prem, that’s to say, migrating to Exadata Machine or ExaCC, you can use existing backups, and none needs to be taken through ZDM. Also if using Zero Data Loss Recovery Appliance (ZDLRA), restore can be done directly from it without taking backups. For any other target platform (OCI, ExaCS, or Autonomous Database), ZDM will have to take backups itself as part of the workflow.

1- Physical Offline Migration

This workflow will support SE2 and EE database migration. It will use backup and restore through RMAN with a backup location that can be either an object storage, or a NFS file system or a ZDLRA (Oracle Zero Data Loss Recovery) appliance.

Following are the high level workflow’s steps:

  • ZDM Download and configuration
  • Database Migration start
  • Connection of the source database to the backup location
  • Backup of the database
  • Transfer of the database backup files
  • Instantiation of a target database with a recover using the backup files
  • Switchover to the target database
  • Migration process finalization

2- Physical Online Migration

This workflow will support EE database migration only. It will use RMAN and Data Guard. The standby database will be created using backups. The backup location can be either an object storage, or a NFS file system or a ZDLRA (Oracle Zero Data Loss Recovery) appliance.

Following are the high level workflow’s steps:

  • ZDM Download and configuration
  • Database Migration start
  • Connection of the source database to the backup location
  • Backup of the primary database
  • Transfer of the database backup files
  • Instantiation of a standby database using backup files
  • Primary and standby databases synchronization
  • Switchover (swapping roles)
  • Migration process finalization

3- Physical Online Migration with Direct Data Transfer

This workflow will support EE database migration only. It will use RMAN and Data Guard. The standby database will be created using active database duplication (for version 11.2) or restore from service (for 12.1, 12.2, 18.X or 19.X version).

Following are the high level workflow’s steps:

  • ZDM Download and configuration
  • Database Migration start
  • Connection to the source and target databases
  • Instantiation of a standby database doing active database duplication or restore from service
  • Primary and standby databases synchronization
  • Switchover (swapping roles)
  • Migration process finalization

4- Logical Offline Migration with Backup Location

This workflow will support SE2 and EE database migration. It will use Data Pump with a backup location that can be either an object storage, or a NFS file system or a ZDLRA (Oracle Zero Data Loss Recovery) appliance.

Following are the high level workflow’s steps:

  • ZDM Download and configuration
  • Validations (directory export/import for example)
  • Connection to the backup location
  • Data Pump Export from source database to the backup location
  • Data Pump import from the backup location to the target database
  • Instantiation of the target database
  • Switchover to the target database
  • Migration process finalization

5- Logical Offline Migration with DB Links

This workflow will support SE2 and EE database migration. It will use Data Pump and DB links. This workflow can only be used for database having a size less than 100 GB.

Following are the high level workflow’s steps:

  • ZDM Download and configuration
  • Validations (directory export/import for example)
  • Connection of the source and target database via DB link
  • Data Pump import from the source to the target database
  • Validation of the target database
  • Switchover to the target database
  • Migration process finalization

6- Logical Online Migration with Backup Location

This workflow will support SE2 and EE database migration. It will use Data Pump with a backup location that can be either an object storage, or a NFS file system or a ZDLRA (Oracle Zero Data Loss Recovery) appliance, and Golden Gate.

Following are the high level workflow’s steps:

  • ZDM Download and configuration
  • Database Migration start
  • Source, target and backup connections
  • Golden Gate configuration and source transaction captures
  • Data Pump Export from source database to the backup location
  • Data Pump import from the backup location to the target database
  • Golden Gate configuration and apply changes
  • Switchover to the target database
  • Migration process finalization

7- Logical Online Migration with DB Links

This workflow will support SE2 and EE database migration. It will use Data Pump, Golden Gate and DB links.

Following are the high level workflow’s steps:

  • ZDM Download and configuration
  • Database Migration start
  • Source and target database connections via DB link
  • Golden Gate configuration and source transaction captures
  • Data Pump import from the source database to the target database
  • Golden Gate configuration and apply changes
  • Switchover to the target database
  • Migration process finalization

Summary

As we can see ZDM is a great and complete tool to migrate database to Oracle Cloud and Oracle Exadata solutions. Physical migration workflow requires the source and target databases to be in the same database release. Logical migration workflow will support cross-platform and cross-version migration. There will be an in-flight upgrade while migrating to the Oracle Cloud. To migrate from on-premises to Oracle Autonomous databases, we can only use the logical workflows. ZDM tool supports non-CDB to PDB migration as well.

In a next blog, I will describe a demo on how to perform an offline logical migration from on-premises to ADB (Autonomous DataBase).