You can migrate a database with Zero Downtime Migration (ZDM) using the Physical Online method. A standby database is built in OCI and kept in sync via redo apply. At your will, a switchover is all it takes to complete the migration. This way even very large databases can be migrated with no or very little downtime.
With the Physical Online method, you can target:
- Virtual Machine DB System
- Bare Metal DB System
- Exadata DB System (ExaCS)
- Exadata Cloud at Customer (ExaCC)
- Exadata (on-prem)
Since the method uses Data Guard as the migration vehicle, this can only be only with Enterprise Edition databases.
Personally, I like this approach because it builds on technology that most of us know already. Data Guard is heavily in use in most organizations. Although ZDM does all the heavy lifting, it is nice to know what happens underneath the hood.
To complete the migration all you need is a regular Data Guard switchover (which ZDM also takes care of). A switchover operation ensures that there will be no data loss at all. In addition, if you have a properly configured application, it won’t experience downtime. Just a brown-out while the switchover takes place.
This method has an excellent fallback possibility. When you switch over to the OCI database, the redo flow is reversed. Now, the on-prem database is a standby database, and it is kept in sync via redo from the OCI database. For those with Advanced Security Option special attention is needed. Read more about it later on.
You migrate the entire database. All the internals are brought to the cloud as well. This includes:
- SQL Plan Baseline
- SQL Profiles
- Public objects
The initial backup of the source, on-prem database will use RMAN Compression. It will drastically reduce the size of the backup, and thus the amount of data that you must transport to the cloud. And the really good thing: ZDM can use RMAN Compression even if you don’t have a license for the Advanced Compression Option. Check the documentation for details on the restricted use license.
You can customize the RMAN backup. You know your system best, so it is possible to tweak the number of RMAN channels used and the compression algorithm applied. Default is 10 and medium.
When ZDM takes the full backup of your source database (Exadata on-prem and ExaCC excluded), it uses Oracle Database Cloud Backup Module for OCI to allocate a special sbt channel. The backup is sent directly to OCI Object Storage. Thus, you don’t need any additional disk space on your source system to hold the backup. The same applies on the target system.
When migrating to ExaCC or Exadata on-prem you can use an existing backup. Use the response file option
DATA_TRANSFER_MEDIUM=EXTBACKUP. Also, if you have a Zero Data Loss Recovery Appliance (ZDLRA) you can restore directly from it, without taking a full backup first. If you are migrating to any other platform, ZDM will need to take a full backup as part of the workflow.
The standby database is kept in sync via redo apply. This means that there are no restrictions in supported data types. Further, DDL in any form is supported and even with a heavy workload on the primary database, your standby database should be able to keep up.
You can migrate to a higher patch level. ZDM will automatically invoke datapatch for you on the OCI database. But you must handle the on-prem database yourself. After switching over to the OCI database and datapatch has been executed, you should patch the on-prem Oracle Home to the same patch level.
- You can migrate to the same version only. This is a restriction of Data Guard. If you also need to upgrade the database, then you must do that after the migration. But it will incur additional downtime.
- The same applies to PDB conversion. ZDM can run the
noncdb_to_pdb.sqlscript for you. But that will incur downtime as well. If you decide to convert to PDB, you need to develop an alternate fallback plan (which is Data Pump or Transportable Tablespaces). The PDB conversion is irreversible, and your on-prem database will be useless as a fallback option.
- It is not possible to migrate between editions.
- The entire database is migrated. I listed this as a benefit as well, but it has a flipside as well. It is not possible to perform any transformation during the migration, e.g. converting any old BasicFile LOBs to SecureFile LOBs. Also, you bring over any old baggage in your database. Sometimes it is nice to start from scratch because garbage tends to accumulate in a database over time.
- If you have a Standard Edition database, you can’t use Physical Online method. Only the Physical Offline is supported.
- You can’t configure Automatic backup on your target database until after the migration has been completed.
- If you need to protect your OCI database with Data Guard, then you must build the standby database after the migration has been completed. Normally, you would use a cascading standby database to keep the target database protected by Data Guard even after the migration has been completed. But currently the OCI tooling does not support that option.
- If your source database is not encrypted, you must create a keystore that can be used later on for TDE Tablespace Encryption. The keystore is created in the source database with no downtime, and you don’t need a separate license just for creating a keystore. You do not have to actually encrypt your source database until it reaches the cloud.
Using this approach, you have a great fallback option. When you switch over to the OCI database, then the redo flow is reversed and the source, on-prem database is now the standby database. If you need to fallback, simply issue another switchover (you could call that a switchback) and start to use the on-prem database again – with no data loss. See step 5 in MAA Practices for Cloud Migration Using ZDM (Doc ID 2562063.1).
There is a catch, however. The OCI database is encrypted using TDE Tablespace Encryption. Any redo generated for an encrypted tablespace is also encrypted. This means that the on-prem database must be able to decrypt the redo before it can be applied. This can happen in two ways:
- You have a license the Advanced Security Option.
- You tell the on-prem database to decrypt the redo and apply it to unencrypted tablespaces.
- On-prem database:
SQL> alter system set tablespace_encryption=decrypt_only;
- OCI database:
SQL> alter system set tablespace_encryption=auto_enable;
Using the Physical Online method in ZDM is a straight-forward way of migrating your database to OCI. It uses Data Guard which is very familiar to most of us. The method does, however, have some limitations, and you can’t target Autonomous Databases.
Want to Know More
If you want to know more about migrations in general, I suggest that you take a look at our webinar Migration Strategies – Insights, Tips and Secrets
In addition, these links contain additional useful information:
- Physical Migrations with Zero Downtime Migration
- MAA Practices for Cloud Migration Using ZDM (Doc ID 2562063.1)
Other Blog Posts in This Series
- Install And Configure ZDM
- Physical Online Migration
- Physical Online Migration to DBCS
- Physical Online Migration to ExaCS
- Physical Online Migration and Testing
- Physical Online Migration of Very Large Databases
- Logical Online Migration
- Logical Online Migration to DBCS
- Logical Offline Migration to Autonomous Database
- Logical Online Migration and Testing
- Logical Online Migration of Very Large Databases
- Logical Online and Sequences
- Logical Offline Migration How To Minimize Downtime
- Logical Migration and Statistics
- Logical Migration and the Final Touches
- Create GoldenGate Hub
- Monitor GoldenGate Replication
- The Pro Tips
9 thoughts on “Zero Downtime Migration – Physical Online Migration”
How does it take care Endian format conversion ? I don’t see option for in-house e.g. moving from Solaris to Linux
The physical migration works from Linux only. Our team is working on making logical migration available from Solaris.
Can we use ZDM 21c version for migrating on-prem database from Exadata X5 to X8M by specifying PLATFORM_TYPE=NON_CLOUD ?
Yes, you can use the latest version of ZDM to migrate to your on-prem Exadata. As you mention, you use PLATFORM_TYPE=NON_CLOUD. See documentation: https://docs.oracle.com/en/database/oracle/zero-downtime-migration/21.1/zdmug/preparing-for-database-migration.html#GUID-892533DD-94BA-405F-8C27-47F02BA9E06C.
Thank you very much for your posts – they are extremely useful for us!
Do you know – is it possible to migrate several databases in parallel using ZDM to ExaCC? As we have pretty short downtime for some of our systems.
I am great that you found the blog posts useful.
Yes, you can migrate several databases in parallel. ZDM was built for handling multiple databases at the same time.
However, if you are migrating from or to the same hosts, note that multiple jobs running at the same time will “steal” resources from each other. But it doesn’t really matter much, because you can copy the database before the maintenance window starts. After that databases are kept in sync with redo and all it takes is a switchover. If you have multiple databases to switchover at the same time, then ZDM can do that as well.
Do you know if phase ZDM_MANIFEST_TO_CLOUD can run in parallel for a set of DBs in ExaCC? As from our experience OCI operations in ExaCC (i.e. database creation in OCI web console) are serial.
When you use the console yourself, I know that operations are serial. However, ZDM doesn’t have to do much in the ZDM_MANIFEST_TO_CLOUD step. It should be over very quickly and I don’t expect it to cause concurrency problems.
If I am not mistaken there are no interruptions to the database during and after ZDM_MANIFEST_TO_CLOUD, so you could even postpone those actions to after the maintenance window or a later maintenance window.
Thank you very much for the valuable information, Daniel!