Database Migration (Lift & Shift) is the process of migrating an Oracle Database from On-Premise to Cloud (Oracle Cloud (OCI), Amazon AWS, Microsoft Azure, etc).
This post covers the Overview, Methodology and Database Concepts that are important related to Migration like Version, Character-set, Big/Little Endian, Multi-Tenant Architecture (PDB & CDB), DB Size, DB Options, etc.
Migration Methodology
Different Migration Scenarios
- Migrating From On-Premise to Oracle Cloud
- Migrating From Amazon RDS, EC2 to Oracle Cloud
- Migrating From Azure to Oracle Cloud
Various Database Options Available In Oracle Cloud
Before migrating your database, you need to check which database option you will be choosing to migrate your on-prem database.
Databases in Oracle Cloud Infrastructure can be put in two main categories:
- User-Managed Database: User-managed Database are the Databases on bare metal, virtual machine, and Exadata DB systems that enable you to customize with the resources that meet your requirements.
- Autonomous Database: It includes
- ATP: Autonomous Transaction Processing
- ADW: Autonomous Data Warehouse
To know more about the various Database options in detail please check my previous post on Oracle Cloud Database Options (VMDB, BMDB, ExaCS, ExaCS & Autonomous (ADW, ATP)
Also read: Overview of Oracle Data Guard In Oracle Cloud Infrastructure
Various Connectivity Option To Oracle Cloud
Once you are done with choosing which database option you will be choosing to migrate your on-prem database, the second thing you need to consider is how your database is shipped to Oracle Cloud.
Online Method
In this method, you will be directly connecting to Oracle Cloud Network and migrating your database. You can use three different options to connect to the Oracle Cloud network.
- Internet Gateway: You will be using Public to connect and data will flow over the internet, used this only for POC’s purpose
- IPsec VPN Tunnel: The second way to connect is using IP Sec VPN Tunnel and typically used to extend OCI Network (i.e. VCN) as if this is an extension to your On-Premise Network so that your users in On-Premise Network can connect to Cloud using Secure Tunnel over the Internet but on Internal (or non -public IP).
- FastConnect: FastConnect is the most expensive solution whereas connecting over the IPSec VPN Tunnel is the most common method.
To know more about the three connectivity options check my post on 3 Ways to Connect to Oracle Cloud
Offline Method
- Data Transfer Disk: Data Transfer is an offline data migration service that lets you securely move petabyte-scale datasets from your datacenter to Object Storage or Archive Storage on Oracle Cloud Infrastructure.
To know more about data transfer disk check here
Supported Versions (DBCS Migration)
Supported version for migration to Oracle DBaaS currently (as of March 2018) are
- 11G On-Premise Database to 11G Database on Cloud
- 11G On-Premise Database to 12C PDB on Cloud
- 12C Non-CDB On-Premise Database to 12C PDB (Pluggable Database) on Cloud
- 12C PDB On-Premise Database to 12C PDB (Pluggable Database) on Cloud
Where PDB Stands for Pluggable Database and CDB stands for Container Database in Multi-Tenant Architecture of 12c Database.
Note: If your on-prem database is at lower version i.e. 11g release 1 or lesser, then first you need to upgrade it to a higher version and then you can migrate to the cloud
Migration Methods
There are multiple migrations possible depending on things like, Source & Destination Database version, Endian, Characterset, Options, Downtime, etc . Methods to migrate Oracle Database to Cloud includes
- Conventional Export/Import and Data Pump
- Transportable Tablespace Data Pump
- Full Transportable Data Pump
- Unplug/Plug (12c Only)
- Remote Cloning (PDB and Non-CDB)
- Recovery Manager (RMAN)
- SQL* Loader
- Oracle GoldenGate
- ZDM (Zero Downtime Migration)
- MV2ADB
- MV2OCI
- Hybrid DataGuard
Lets Deep-Dive into each Migration Methods we have:
Original* Export/Import
- Traditional oldest Method to Migrate Data
- Very SlowNot designed for large Database (100GB+)
- Must be used for 9i or previous versions
- Not fit to Migrate to Cloud
Data Pump Export/Import
- Introduced in 10g Database
- Designed to handle a large volume of data
- Very data is very large (few hundred GBs)
- From a performance point of view, the Transportable Tablespace method could be quicker
- Nothing to worry about Character set or Endian
- Can be used for 11g on-premise to 11g/12c PDB Cloud Migration
- Can be used for 12c Non-CDB/PDB on-premise to 12c PDB Cloud Migration
Data pump Transportable Tablespace
- Fastest Method to migrate Data
- Entire Datafiles in a Tablespace are moved from source to Target Database
- Moving of Datafiles is quick compared to each object hence this method is
- quicker than Data Pump Export/Import
- Requires some configuration and setup to migrate using Transportable
- Tablespaces could be complex
- Can be used for 11g on-premise to 11g/12c PDB Cloud Migration
- Can be used for 12c Non-CDB/PDB on-premise to 12c PDB Cloud Migration
Data Pump Full Transportable
- Introduced in 12c, make migration to 12c Database Easy & Quick
- 12c can be configured as Non-CDB or CDB/PDB
- Can be used to migrate to both Non-CDB or PDB
- Moves all of System, User, and Application Metadata without complex setup
- required in Transportable Tablespace Method
- Combines the ease of Data-pump and speed of Transportable Tablespaces
- Can be used for 11.2.0.3+ on-premise to 12c PDB Cloud Migration
- Can be used for 12c Non-CDB/PDB on-premise to 12c PDB Cloud Migration
- Use this method to migrate from Non-CDB to PDB
- One PDB to another PDB
Unplug/Plug
- Uses 12c Multitenant feature of Pluggable Database(PDB)
- Supported by
- 12c Non-CDB on Premise to PDB on Cloud
- 12c PDB on Premise to PDB on Cloud
- If TDE is enabled, export TDE master encryption key on the source before migration and
- Import TDE Master key in CDB on target (If no key store in CDB then create it)
Remote Cloning
- Uses 12c Multitenant feature of Pluggable Database(PDB) Supported from
- 12c Non-CDB on Premise to New PDB on Cloud
- 12c PDB on Premise to New PDB on Cloud
- Target database on DBCS must be new PDB (You can’t clone to an existing PDB)
- During migration, the on-premise database must be Read Only
- After migration, on-premise can be changed to reading Write and can be used
RMAN Convert Transport Tablespace With Data Pump
- RMAN Convert TTS + expdp for
- 11g on-premise to 11g Cloud Migration
- 12c Non-CDB or PDB on-premise to new or Existing PDB Cloud Migration
- Copy Dump & Image File to Cloud Compute
- Import (impdp) to Cloud 11g Database
RMAN TTS with Data Pump
- RMAN Backup TS + expdp: 11g on-premise to 12c PDB on Cloud
- Copy Dump & data file to Cloud Compute
- Restore + impdp to Cloud PDB
- Very Similar to RMAN Convert TTS plus Data pump
RMAN Cross-Platform Transportable Tablespace Backup Sets
- RMAN Backup To Platform: 12c Non-CDB/PDB on-premise to 12c PDB on
Cloud - If Endian Conversion is required RMAN BACKUP TO PLATFORM DATAPUMP TABLESPACE
- Copy Backup Set & Dump File
- Restore Foreign Tablespace Dump File to Cloud PDB
RMAN Cross-Platform Transportable PDB
- RMAN Un-Plug/Plug: 12c PDB on-premise to 12c PDB on Cloud
- If Endian Conversion is Required
- Unplug PDB + RMAN BACKUP FOR TRANSPORT PLUGGABLE DATABASE
- Copy PDB to Compute Cloud
- RMAN RESTORE ALL FOREIGN DATAFILES + Plug PDB
SQL Developer
- SQL Developer to migrate data to Cloud has two options
- DDL statement + SQL*loader control & Data File
- DDL statement + Insert Statement (Use SQL Developer)
- User SQL Developer
Oracle Golden Gate
- Zero or near-zero downtime migrations when an Oracle Data Guard solution is not applicable
- Bi-directional replication can be configured from the migrated database back to the production database for use as a fallback solution
ZDM (Zero Downtime Migration)
- Oracle automated tools make it seamless to move your on-premises database to the Oracle Cloud with virtually no downtime.
- Note: this utility will be available probably from December 2o19
Click here to know more about Zero Downtime Migration.
MV2OCI
- M2OCI is a utility by Oracle to move data to Oracle Cloud Database in “one-click”.
- To know about MV2OCI check DOCI-ID: 2514026.1
MV2ADB
- MV2ADB is a utility by Oracle to move data to Oracle Autonomous Database in “1-click”
- To know more about MV2ADB check DOC-ID: 2463574.1
Hybrid DataGuard
- Used when you required Zero Downtime
- Primary database instances on-premise that need a standby in the Oracle Cloud
- Once Migration Done successfully make Standby Database to primary using switchover
Now it’s your turn to post your doubts in the comment section and let us know where you are facing challenges while doing the migration to the Oracle cloud. If you like the post don’t forget to share this with your colleague or friends.
Related/Further Readings
- Oracle Cloud Database Options (VMDB, BMDB, ExaCS, ExaCS & Autonomous (ADW, ATP)
- 3 Ways to Connect to Oracle Cloud(
- ADB) MV2ADB: move data to Autonomous Database in “one-click” (Doc ID 2463574.1)
- OCI) MV2OCI: move data to Oracle Cloud Database in “one-click” (Doc ID 2514026.1
- Migrating Databases to the Cloud
- Using Oracle GoldenGate for an Efficient & Flexible Oracle Cloud Migration
- Migration to Exadata Best Practices
- Migration to Exadata Cloud Using Advanced Data Guard Approach with Minimal Downtime (2326901.1)
- Oracle EBS (R12) On-Premise to OCI Migration (Lift & Shift): 10 Things You Must Consider
Begin Your Cloud Journey
Begin your journey towards becoming an Oracle Cloud Expert and earn a lot more in 2024 by joining our FREE CLASS. You will also know more about the Roles and Responsibilities, Job opportunities for OCI Architects, Admins in the market, and what to study Including Hands-On labs you must perform to get the Higher Paying jobs.
Click on the below image to Register for Our FREE CLASS on MASTERING ORACLE CLOUD FOR DBAs, APPs DBAs, ARCHITECTS & SYS ADMINS
sanjay Kumar says
Hi..i am looking to move Oracle VM on Azure to DBCS on OCI….or to Autonomous DB on OCI…any documents u have will be greatly appreciated.
Rahul Dangayach says
Hi Sanjay,
Please check below documents
http://oracle-blogs-test.compendiumblog.com/a-complete-guide-to-interconnect-oracle-cloud-infrastructure-oci-with-microsoft-azure
https://leandromichelino.medium.com/how-to-migrate-an-azure-windows-instance-to-oci-using-azure-export-9b9a349a9d21
https://docs.microsoft.com/en-us/azure/migrate/tutorial-migrate-physical-virtual-machines
https://azure.microsoft.com/en-gb/services/azure-migrate/
Thans & Regards
Team 21
Ayush Srinet says
Hi..i am looking for cutover plan from On Prem F5 Vips to Oracle Cloud. can you please help me for best practices to do this.
Rahul Dangayach says
Hi Ayush,
Migrating from an on-premises F5 load balancer to Oracle Cloud requires careful planning and execution to ensure a smooth transition with minimal disruption to your applications and services. Here are some best practices to consider for your cutover plan:
Develop a migration plan: Before you begin your migration, you need to develop a detailed plan that outlines the steps involved, timelines, dependencies, and contingencies. This plan should include a list of all the applications and services that are currently using the F5 load balancer, the IP addresses and ports associated with each application, and the corresponding configurations required in Oracle Cloud.
Test the migration plan in a non-production environment: It is crucial to test the migration plan in a non-production environment to identify any potential issues or risks. This will also give you an opportunity to refine your plan and make necessary changes before moving to production.
Prepare the Oracle Cloud environment: You need to prepare the Oracle Cloud environment by setting up the appropriate networking components, such as VCNs, subnets, security rules, and internet gateways. You should also provision the required compute instances and configure them to support load balancing.
Configure the Oracle Cloud load balancer: Once the Oracle Cloud environment is ready, you need to configure the Oracle Cloud load balancer with the necessary settings, including SSL certificates, listeners, health checks, and backend sets. You should also configure the load balancer to handle traffic in a way that is consistent with your on-premises F5 load balancer.
Set up DNS: You need to update your DNS records to point to the new Oracle Cloud load balancer IP address. This should be done during a scheduled maintenance window to minimize disruption to your users.
Test the cutover: Once you have completed the migration, you need to test the cutover to ensure that your applications and services are functioning correctly. You should also monitor the traffic to identify any issues or anomalies and take corrective actions as needed.
Monitor and optimize performance: After the cutover, you should monitor the performance of your applications and services in the Oracle Cloud environment and optimize the load balancer settings as needed to ensure optimal performance.
Overall, the key to a successful cutover from an on-premises F5 load balancer to Oracle Cloud is careful planning, testing, and execution. By following these best practices, you can minimize risks and ensure a smooth transition to the cloud.
Hope this helps.
Thanks & Regards
Rahul Dangayach
Team K21Academy
KRISHNAKANT NIRALA says
Hi Rahul Dangayach,
Could you please send link/video/docs to creare RAC/Data Gaurd on Exadata CS and mogration from on premise to OCI.