Database Migration

Part 4/10: Automation Tools and Maximum Availability Architecture Migration Methods

In this part, we will introduce the automation tools and Maximum Availability Architecture (MAA) migration methods.

Automation Tools

Automation is one of the major benefits of migrating workloads to the cloud. Oracle provides different database migration solutions to even automate the migration process to the cloud.

MV2ADB (Move to Autonomous Database)

MV2ADB is a command-line tool that allows migrating data from an Oracle database on-premise to Oracle Autonomous Database in “one-click”. It is based on Oracle Data Pump export and import utility. The tool automatically runs the following steps that you would usually execute one by one:

  1. Run Oracle Autonomous Database Schema Advisor (Doc ID 2462677.1) to analyze the database schemas and report any concerns that may arise during the migration.
  2. Export the data from the source database using Data Pump export.
  3. Transfer the dump files into Oracle Cloud Infrastructure Object Storage.
  4. Import the data into the Autonomous database using Data Pump import.
  5. Verify the Data Pump import log file.

MV2ADB can also be configured to use a database link to transfer the data directly over the network and avoid staging the data on Object Storage.

For sure, before you are hitting the “one-click” to start the migration, you have to meet the prerequisites, become familiar with the tools’ syntax and options, and create your desired configuration. But this overhead pays off, especially when you are migrating multiple databases or testing the migration multiple times, as automation ensures you are executing the same code and reduces human error.

For full description, requirements, and execution examples have a look at Doc ID 2463574.1

MV2OCI (Move to Oracle Cloud Infrastructure)

MV2OCI is the counterpart of MV2ADB for migrating your database to Oracle Database Cloud Service (DBCS). This time, as you can access the database machine, the dump files are copied to the local storage instead of OCI Object Storage. MV2OCI can also be executed using the network mode without using any intermediate storage.

For full description, requirements, and execution examples have a look at Doc ID 2514026.1

As both M2ADB and MV2OCI relies on Data Pump export and import, you have the full flexibility Oracle Data Pump provides for migrating databases across platforms with different endian formats, migrating to different database architecture, or a higher release version.

Zero Downtime Migration (ZDM)

ZDM is a software solution that allows you to seamlessly migrate your on-premises Oracle Databases to the Oracle Database Cloud Service (DBCS). It is based on the precepts of Oracle’s Maximum Availability Architecture (MAA), and as the name implies, ensures minimal or no downtime during the migration process.

ZDM builds a standby database in the cloud and keeps it in sync with your primary database in your own data center, and when you are ready to migrate, all it takes is a simple switchover.

In the first step, you download ZDM and configure it. It requires Linux 7 or above, and it is highly recommended to be run on a separate server (neither your source database server nor the target database server in the cloud). You could install it on a virtual box, OVM, etc. ZDM runs the following steps:

  1. Establish a connection between the source database on-premise and Object Storage.
  2. Transfer backup files of the source database to Object Storage.
  3. Instantiate a Data Guard standby database in the cloud using the backup files from the previous step.
  4. Set up connectivity between source and target and complete Data Guard configuration to keep the standby in sync with the primary.
  5. Perform switchover to swap the roles. The database in the cloud becomes the primary now.

As ZDM is based on Data Guard, source and target must have the same endian format, same database architecture, same edition, and same release version. However, it is possible to migrate to a higher patch level and run datapatch afterward.

ZDM can also be used to migrate Standard Edition databases to the cloud. In this case, the source database will be migrated in an offline manner using the backup and restore method.

Keep in mind, that the target database in the cloud is encrypted using TDE tablespace encryption. So after switchover (cloud becomes the primary), you are not allowed to switch back unless you have the Advanced Security Option (ASO) for your on-premise database.

Have a look at this blog post by Daniel Overby Hansen for more detailed information about the characteristics and requirements for sources and target systems.

It’s best practice to use the automation tools if applicable. Otherwise, use a manual method according to your requirements. So let’s start with our 20+ manual methods!

Maximum Availability Architecture (MAA) Migration Methods

MAA is Oracle’s best practices blueprint based on proven Oracle high availability technologies to reduce planned and unplanned downtime for Oracle databases on-premises and in the cloud.

Implement Application Continuity to mask outages from end-users and applications by recovering the in-flight database sessions following recoverable outages. It is available with RAC, RAC One Node, and Active Data Guard options.

1. Data Guard

By using Data Guard you build a standby database in the cloud, keep it in sync with your primary on-premise database, and finally switch over to complete the migration. You can use Data Guard to migrate to Oracle Database Cloud Service (DBCS) as access to the operating systems’ database machine is required.

For detailed steps and code examples have a look at:

In case you want to upgrade your source database to a higher version in addition to the migration, then you have these options:

  1. Upgrade your source database on-prem first and use Data Guard as described.
  2. Use Data Guard as described, and then upgrade your primary in the cloud.

However, in both cases, you are upgrading the primary database. The time needed for the upgrade counts to applications’ downtime.

  1. Use Transient Logical Rolling Upgrade for the lowest downtime as the upgrade is performed on the target standby database in the cloud before switching over. During the upgrade, the original primary database on-premise is still open for use.

For detailed steps and code examples have a look at:

Keep in mind, Data Guard is not a database option that has to be purchased separately. But Active Data Guard is.

2. Golden Gate

Golden Gate allows you to replicate, filter, and transform data from one database to another. As it replicates transactions (and not physical data blocks), it is a logical replication method. Hence, it can be used to migrate on-premise databases to Oracle Database Cloud Service (DBCS) and Oracle Autonomous Database (ADB).

Furthermore, it supports migrating across different platforms (different endian format), different architectures (non-CDB to PDB), and different release versions (e.g. 11g to 19c) so you achieve an upgrade in the same time. 

Golden Gate has many more capabilities, but these are out of the scope of this blog.

For detailed steps and code examples have a look at:

Using Golden Gate on OCI is on promotional offer until December 31st, 2020 if used to migrate into Oracle Cloud.

Conclusion

Oracle provides automation tools to be used for free to simplify and automate the database migration process to the Oracle cloud. It is best practice to use these automation tools if applicable. Automation saves you time and reduces human error. Zero Downtime Migration (ZDM) launches a standby database in the cloud and keep it in sync for you to complete the migration by just switching over by a click of the button.

Oracle Maximum Availability Architecture (MAA) provides database technologies like Data Guard and Golden Gate for a (near) zero downtime migration to Oracle Database Cloud Service and Oracle Autonomous Database.

Further Reading

Would you like to get notified when the next post is published?