Part 10/10: Summary and a Migration Decision Tree

This is part 10 and the last part of our blog series about migrating Oracle databases to Oracle Cloud. In this part, we will summarize all topics in previous parts and introduce a decision tree to help you determine what migration methods are applicable depending on your system characteristics and requirements.

Why Move to Oracle Cloud?

By running your Oracle databases on Oracle Cloud you benefit from a high degree of automation, simplified management, implementing high availability and disaster recovery with a click of the button, scalability, higher performance, and higher security. Additionally, you reduce cost by using the elastic capabilities of the cloud and pay only for what you use.

Oracle Database Cloud Service Offering

Oracle offers many different database cloud services that primarily differ in their level of administration and control. Database Cloud Service (DBCS) is a managed service where the customer is responsible for database administration and tuning, while Oracle provides tooling to simplify the management tasks like patching, backup, recovery, and building high availability and disaster recovery solutions. DBCS can be run on virtual machines, dedicated bare-metal machines, and dedicated Exadata (Exadata Cloud Service - ExaCS).

Oracle Autonomous Database is a fully automated service running on shared or dedicated Exadata infrastructure. It provides high performance, high availability, and security like always-on encryption out of the box. Customers can focus on their data and application development instead of spending their time and resources doing regular administration tasks.

For customers who want or must keep their data in their own data centers behind their own firewalls, Oracle brings the cloud to them and offers a managed and even the autonomous database service running on Exadata Cloud at Customer.

Oracle Database Migration Considerations

Choosing the right migration method depends on many factors and characteristics of your source and destination platforms and databases. These include, but are not limited to, your platform, database version, database edition and options, database architecture, character set, and data types. One of the most important and discussed factors is the downtime that can be tolerated during the migration process, which primarily depends on database size and network bandwidth.

Choosing the right database service depends on many factors like your requirements for performance, security, isolation, scalability, and high availability. The target database service then determines what set of migration methods are available to move to that database service. As managed services provide you access to the database machine and container database, you can choose either a logical or physical migration method. Moving to an autonomous database service requires using logical 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 and MV2OCI are command-line tools based on Data Pump and allow migrating Oracle databases on-premise to Oracle Cloud in "one-click". As these are new command-line tools, you'd need to invest some time to learn the commands and set up the configuration. This time pays off especially when you migrate a large number of databases.

Zero Downtime Migration (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.

Maximum Availability Architecture (MAA)

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.

Data Guard allows you to 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. Data Guard is the technology used by ZDM to achieve zero-downtime migration.

Golden Gate enables real-time data integration between different Oracle databases. It provides all the necessary programs to capture, transform, propagate, and apply changes happening in a source database to a target database. 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.

Data Pump

Oracle Data Pump technology enables you to move data and metadata from one database to another by using export and import utilities. Data Pump provides a very wide range of benefits like supporting older releases back to version 10.1, migrating databases across platforms with different endian formats, different database architectures, and versions. You can choose to export the full database, specific schemas, tablespaces, or tables.

You have the full flexibility to control the degree of parallelism, compression, encryption, and what objects and objects types to include or exclude. Data Pump also supports network mode to move the data using a database link without the need for intermediate storage.

RMAN

Oracle Recovery Manager (RMAN) is the tool used for efficiently backing up and recovering the Oracle database. RMAN is also used to facilitate database migrations on-premises and from on-premise to the Cloud.

RMAN provides different ways to migrate an Oracle database across platforms by using backup and restore scenarios, including converting the database data files for cross endian platform migrations. Using inconsistent backups you can minimize the downtime to the time needed to create and apply one last incremental level 1 backup.

Multitenant Architecture

The multitenant option was introduced in version 12.1 to enable an Oracle database to function as a multitenant container database (CDB). The multitenant architecture provides easy and powerful features to move databases across platforms, even with just one single SQL command.

It provides numerous migration methods to move databases across platforms. The migration methods are very easy and straightforward allowing moving a 12c non-CDB or PDB to a target CDB with a higher release version, hot cloning while the source database remains online, and refresh and relocate capabilities to significantly reduce downtime.

Migrating Small Amount of Data

Oracle provides different tools to simplify migrating a small amount of data, a limited number of objects, and data stored in flat files.

Oracle SQL Developer's Database Copy utility enables you to migrate your data in a very simplified way by using a graphical wizard taking you step by step through the migration options. SQL Developer's Cart utility enables you to create a cart into which you add selected objects to be loaded into a target database. This method is useful when you need to create a subset of objects from one or more schemas on the source database and deploy them on the target.

SQL*Loader enables you to load data from external files into a table in the Oracle database. It supports many file formats such as CSV, tab-delimited, and pipe-delimited files. Thanks to the powerful data parsing engine, there is very little limitation on the format of the data in the data file.

Migrate Oracle Databases from AWS to Oracle Cloud

By moving your Oracle database from Amazon RDS and EC2 to Oracle cloud you benefit from access to the newest features and all options of Oracle database including Real Application Clusters (RAC), isolation and high performance on dedicated Exadata infrastructure, automated database management, Oracle Autonomous Database that takes automation to the next level, and best price-performance for Oracle databases on the public cloud.

Summary

The following table summarizes most of the migration methods discussed in this blog series and their characteristics. Lines with the same color provide the same characteristics discussed here but still may differ regarding further factors.

Decision Tree

Even me being very passionate about relational databases and always tend to create tables for everything, I was thinking of another way to provide a quick guide for what migration methods to consider based on some important characteristics and requirements, and ended up with a decision tree.

The first thing to consider is the target database in the cloud. If you are migrating to an autonomous service, then you have to go with a logical migration method. The same applies if your source and target databases do not have compatible character sets.

All Oracle databases in the cloud run on Oracle Linux, which is a little-endian format. If your source database run on a platform with the big-endian format, then you have to choose a logical migration method or a physical one that allows endian conversion.

If your source database runs on a little-endian platform, review the requirements for Zero Downtime Migration. In case ZDM is not applicable, consider one of the manual methods.

Obviously, the higher your database version is, the more migration methods are available. One more reason to upgrade!!! Before making the final decision, always review the Oracle documentation regarding prerequisites, restrictions, and recommendations. And testing testing testing!

Further Reading

For more information and details have a look at:

• Move to the Oracle Cloud
• Cloud Migration Advisor
• Oracle Architecture Center
• Migrating Databases to the Cloud
• Oracle Zero Downtime Migration

Next Blog

This was the last part of the series. But there would be for sure a next blog about database migration or maybe something else :-) Stay tuned! In case you have any questions, feel free to reach out to me! It would be my pleasure to help.