EMEA A&C CCOE Partner Technology Cloud Engineering

Cloud Lift Your Database to OCI - A Partners Quick Start Guide

Saleh Abed
Technology and Cloud Adoption & Implementation Consultant

Oracle database products offer customers cost-optimized and high-performance versions of Oracle Database, the world's leading converged, multi-model database management system, as well as in-memory, NoSQL and MySQL databases. Oracle Autonomous Database, available on premises via Oracle Cloud@Customer or in the Oracle Cloud Infrastructure, enables customers to simplify relational database environments and reduce management workloads.

Given Oracle’s lead in the universal database category, non-Oracle customers should consider a move to Oracle Database 21c or Autonomous Database. An analysis naturally needs to include the cost of migration, cost for new licenses and cost of long-term operations. Constellation believes Oracle has a very good chance to prevail as a winner in most cases, with application rewrite costs likely being the dealmaker or showstopper.

Holger Mueller
Vice President and Principal Analyst - Constellation Research

Oracle Makes Its Great Database Even Better—and Adds Low Code to It

What are the Business Drivers for Database Cloud Migration

If we look to migrating database to cloud as a puzzle, then the first and most important piece of this puzzle is understanding the why – why you are considering moving to cloud – what is the pain-point or business driver you are addressing.

This piece can lead us to other important pieces like what is the right solution for this problem, how to build the solution, what are the solution components and what is the right migration strategy. So, let’s see some of these business drivers:

  • Application performance problems, unable to cope with data growth.
  • Aging hardware, hardware expiring support or due for renewal.
  • Database sprawl is a very common concern and issue, across DB versions, OS versions, and hardware. Plus, DBAs cannot keep up with escalating workloads.
  • Complexity of managing security compliance and policies for data access.
  • Complex architectures to ensure high availability, in addition to disaster recovery problems, and unacceptable RPO/RTO performance.
  • Costly over-provisioning of database to prepare for peak demand.
  • Difficulty of making databases available to all stages of dev/test lifecycle.


What are the database migration requirements and constraints?

In a nutshell, you need to know certain things before you design a migration strategy, like source database, target database, constraints, and business requirement.

Source Database, database version, database size and number of database tables, workload, usage and performance requirements, single or multi-tenant architecture, character set, and platform endian format of the source and target databases.

Target Database, database type, database version, high availability and disaster recovery requirements.

Constraints, the runtime constraints are the ones that are considered upon implementation. The bandwidth and connectivity, fallback capability, downtime requirements for migration, project resources available for migration, staffing and so forth.

Business Requirements, like moving database from on-premise to cloud without a downtime or moving to cloud database that needs no administration.


Automatic Workload Repository

A very important tool to use before starting with any database migration process is Automatic Workload Repository (AWR). AWR is a built-in performance evaluation and analysis tool available out of box with all database versions. AWR collects database systems statistics automatically, and it stores them in a repository. The statistics collected and processed by AWR include:

  • Object statistics that determine both access and usage statistics of database segments
  • Time model statistics based on time usage for activities, displayed in the V$SYS_TIME_MODEL and V$SESS_TIME_MODEL views
  • Some of the system and session statistics collected in the V$SYSSTAT and V$SESSTAT views
  • SQL statements that are producing the highest load on the system, based on criteria such as elapsed time and CPU time
  • Active Session History (ASH) statistics, representing the history of recent sessions activity

AWR analysis allows you to determine latencies and target database requirements. Latency is the average synchronous single-block read latency, it is a value of source database. Average value should be less than 40 milliseconds, if it is greater than 40 milliseconds then it would be latency too high. CPU is looked at into the Average Active Session, AAS, which is core count of source databases. Typically, AAS greater-than-average core count is considered to be a CPU bound.

Same way, Workload Type, I/O workload and megabytes per second workloads and IOPS of source database, ratio of I/O megabytes per second to IOPS compared to 128K is considered a mixed workload versus OLTP and DSS. To estimate Workload Type, classify hourly workload as OLTP or DSS, based on ratio of IOP megabytes per second to IOPS compared to 128. If number of OLTP hours is between 40% and 60%, source database can be classified as mixed workload.

Not only that, even more deeper! If Workload Type estimate is OLTP, and IOPS are greater than 5,000 then environment could potentially benefit from consolidating to an Oracle Exadata Cloud Service because of the flash cache benefits.


Reference Architecture for Database migration to OCI

This diagram is presenting a minimum OCI architecture for migrating a source database to OCI.

The OCI architecture consists of single availability domain and a VCN. Within the VCN, there are two subnets, private and public. It has Bastion host on a public subnet and a DBVM host of any Oracle version from 19c to 11g on a private subnet for security purposes. In case of Autonomous Database, it will be Autonomous Database Instance (ATP/ADW).

You can connect to object store through service gateway. Dynamic Routing Gateway - DRG, is used to establish a secure and private connection between OCI, VCN and then any on premise systems, for example, source database. Connectivity is via VPN or any tunneling mechanism to reach the OCI VCN.

Migration Methods and Tools

Many methods and tools exist to migrate Oracle databases to Oracle Cloud Infrastructure Database service. Which of these methods apply to a given migration scenario depends on several factors, as we mentioned above.

We have five methods available for migrating on-premise source database to OCI cloud database service.

  • Recovery Manager – RMAN
  • Data Pump
  • MV2ADB
  • Plug/Unplug
  • Zero Downtime Migration


Recovery Manager – RMAN

Recovery Manager - RMAN, is one of the reliable and versatile offline migration tools available in every enterprise or a standard database release.

You can presently migrate source databases of both CDB or non-CDB type varying from 11g to all the way 19c. Target database cloud service would be used or can be used for this migration type would be the VM bare metal Exadata Cloud Service and as well as Exadata Cloud at Customer. Similarly, versions vary from whatever the source versions are for like to like or in-flight upgrade. Cross-platform migration is possible through RMAN.

RMAN is used as a migration tool using the backup sets that are used for creating a backup and restore strategy. Migrating from small to large databases can be handled by RMAN.


Data Pump

Oracle Data Pump technology enables very high-speed movement of data and metadata from one database to another, it is full, and offline database migration tool. Like RMAN, Data Pump is a native tool available with all types of licenses and on Cloud. The tool is very simple to use, designed to offer maximum flexibility of slicing and dicing data movement. It supports small to large database independent of Endian format and character set.

Like any Oracle database utility, the latest version, like 19c Data Pump Client, is compatible to any lower version up to 10g and is interoperable between versions.

For migration support, source databases supported are:

  • CDB/PDB databases 12c, 18c, and 19c.  
  • Non-CDB databases, 11g, 12c, 18c, and 19c.

While supported target databases are: DBaaS VM, DBaaS Bare Metal, Exadata Cloud Service, and Exadata Cloud@Customer.

There are five different modes of data unloading:

  • Schema Mode: default mode, specific schemas;
  • Table Mode: specific set of tables, dependent objects associated to those tables;
  • Tablespace Mode: the tables in the specified tablespace, which is a logical storage container housing all tables and objects;
  • Transportable Tablespace Mode: only the metadata for the tables and dependent objects within the specified set of tables; and
  • Full Export Mode: entire database is exported and can be either fully imported or a partial import can be done based on the requirements.



Move to Autonomous Database (MV2ADB) is a new tool is permitting the load data and migration from “on premises” to Autonomous Database Cloud leveraging on Oracle Data Pump and within one command. Data Pump Import lets you import data from Data Pump files residing on the Oracle Cloud Infrastructure Object Storage.

MV2ADB is a free, easy to use tool, supports both OLTP and OLAP workloads of small to large database sizes.

It allows in-flight upgrade to ADB, requires some downtime and knowledge of scripting configuration to automate data movement. Source databases supported for MV2ADB: 11g, 12c, 18c, and 19c. OCI target databases service: autonomous data warehouse, autonomous transaction processing (both dedicated or shared), Oracle 19c and above.

MV2ADB fully automates the entire data migration process from on premise Oracle database to autonomous database on OCI. MV2ADB tool is only available through MyOracle Support interface under MOS note 2463574.1



You can use this method only if the on-premises platform is little endian, and the on-premises database and the Oracle Cloud Infrastructure Database service database have compatible database character sets and national character sets.

With PDB, you can use the Plug/Unplug method to migrate an Oracle Database 12c PDB to a PDB in an Oracle Database 12c database on a Database service database deployment.

With Non-CDB, you can use the Plug/Unplug method to migrate an Oracle Database 12c non-CDB database to a PDB in an Oracle Database 12c database on a Database service database deployment. This method provides a way to consolidate several non-CDB databases into a single Oracle Database 12c multitenant database on the Database service.

To complete the picture, I mentioned above “little endian”, so What is Endianness?

  • Endianness is an attribute of a system that indicates whether integers are represented from left to right or from right to left.
  • Endianness comes in two varieties, a big and a little. A big-endian representation has multi-byte integer written with its most significant byte on the left side. A little-endian representation, on the other hand, places the most significant bit on the right side.
  • All processors must be designated as either big-endian or little-endian. Intel 8086 processors, the AMD64, and their clones are all little-endian. Some distributions of Linux have little-endian mode. IBM AIX, Oracle Solaris, SunSpark, Motorola 68K, and the PowerPC families are all big-endian. In fact, the Java virtual machine is a big-endian as well.


Zero Downtime Migration

Zero Downtime Migration (ZMD) gives you a quick and easy way to move on-premises databases and Oracle Cloud Infrastructure Classic instances to Oracle Cloud Infrastructure, Exadata Cloud at Customer, and Exadata Cloud Service without incurring any significant downtime, by leveraging technologies such as Oracle Active Data Guard.

ZMD uses mechanisms such as backing up the source database to Oracle Cloud Infrastructure Object Storage, creating a standby database (with Data Guard configuration, Oracle Data Guard Maximum Performance protection mode and asynchronous (ASYNC) redo transport mode) in the target environment from the backup, synchronizing the source and target databases, and switching over to the target database as the primary database.

The source databases that ZDM supports are: CDB and PDB from 12c, up to 19c, and non-CDB 11g. Non-container in the sense that if these versions are not running non-container version licenses, it still supports that. The target databases it supports is DBaaS VM, DBaaS Bare Metal, ExaCS, ExaCC, and then support from 11g to 19c versions.

ZMD is compliant with Oracle Maximum Availability Architecture (MAA) and supports Oracle Database 11g Release 2 ( and later database releases. Zero Downtime Migration provides a robust, flexible, and resumable migration process that is also easy to roll back. ZMD uses a controlled switchover method for dynamically moving database services to the new database environment in Oracle Cloud Infrastructure, Exadata Cloud at Customer, and Exadata Cloud Service. You can perform and manage a database migration of an individual database or perform database migrations at a fleet level using ZMD.


Finally, let me summarize the database migration tools to OCI in terms of “What is the Tool?” and “Why Do we use it?”



Data Pump





Is the tool?

RMAN tool is available for performing and managing Oracle Database backups, clones, duplications and restorations.

Oracle Data Pump provides high performance Export and Import utilities for migrating databases

MV2ADB is a utility to migrate data from any source to Autonomous database (ATP and ADW)

Plug/Unplug Method can be used when you are moving from a Single Tenant to a multi-tenant Database architecture

ZDM is Oracle MAA recommended solution that provides a robust, flexible and resumable migration with fallback capability.


Do we use it?

  • Migrate to OCI DB (VM and BM), ExaCS or ExaCC
  • Source DB or higher
  • Small to Large DB
  • Migrate to OCI DB (VM and BM), ExaCS or ExaCC
  • Source DB or higher
  • Small to Large DB
  • Structured unstructured data
  • CSV, Parquet, AVRO and Dump Files of Database and Tables
  • Migrate to Multi-tenant Architecture
  • Uses RMAN, Data Pump or other tools to migrate
  • Small to Large DB
  • Migrate to OCI DB, ExaCS or ExaCC
  • Source DB or higher
  • Small to Large DB
  • Zero Downtime


Learn More

For more information on Oracle database migration tools to OCI, technical briefs and documentation please visit:


Subscribe to our Channel

EMEA A&C Partner Technology Cloud Engineering remains available to work with EMEA Partners to on engagements, check our calendar of activities: Oracle Partner Enablement Calendar

For any questions please contact us at partner.imc@beehiveonline.oracle.com

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.