Most on-premises Oracle database deployments can be migrated to Oracle Cloud Infrastructure without requiring significant re-architecture, re-integration or business process changes, and will result in a solution that is more flexible, more reliable, and delivers higher performance at a lower cost than deployments running on-premises or with other cloud providers.
OCI provides several deployment and edition options depending on the amount of customer administration needed, and you may choose to use more than one of these options depending on each database’s unique business needs.
Consider the following before you begin the migration process:
- The best time of day to perform the migration
- Downtime requirements
- Database and data set size
- The source and target database character sets
- The source and target database versions
- If the source database contains user-defined data types
- The source database and the target database platform (endian)
Source – Link
Challenges with Database Migration to Oracle Cloud
1. Problems Might Arise in the Bulk Data Transfer
When performing the build data load over the network, network interruptions or delays might interfere with the load process. Oracle does offer Oracle FastConnect to speed things up but at a cost and feasibility. Or when using physical storage devices to transfer the data, the shipment of the storage devices might be delayed. (Due to weather, theft, chipset shortage, wreck, damage and so on.)
How to Mitigate: Retain a backup of the data that is to be transferred to Oracle Cloud or ensure that the data can be re-created easily. Communicate clearly with all the concerned parties, and reset timelines as needed. Buy or use insurance, where appropriate. And be sure to maintain security compliance as required.
2. Data Synchronization Problems Might Make a Parallel Run Unfeasible
The data synchronization tool might not be able to keep up with the volume or velocity or changes data after the initial bulk load, making it impossible to test the new cloud database in parallel with the on-premises database before cutover.
How to Mitigate: Find the adequate data synchronization tools and test them thoroughly as part of your migration planning. If synchronization is not possible, work with the business leaders to identify contingency plans for reducing any risks that this might pose to the enterprise.
3. The Migration Project Could Easily Become Late and Over Budget
The data loading, data structure conversion and software development effort might end up taking significantly longer than estimated, making the migration project late and over budget.
How to mitigate: Start with small migrations to gain experience before tackling large or complex migrations. Find the right cloud migration partner to help you plan and execute the migration, and adopt agile/DevOps to continually deliver business value instead of trying to carry out waterfall projects.
4. The Migration Plan and Objectives Might be Misaligned
You might discover that the migration project as planned will not accomplish the objectives that were set at the prework step.
How to Mitigate: This may make it necessary to begin the process all over again, so that the migration plan is brought into line with the objectives and requirements. However, the cloud migration is planned and failing to meet the objectives is preferable to taking after the migration and implementation work which has been done.
5. The Goals of the Cloud Migration Might Be Technically Unfeasible
The migration method (rehost, refactor, re-architect, rebuild, or replace) that is most appropriate from a technical standpoint might not suit the business strategy or objectives that were set during the planning / pre-work stage. The business goals might not be easily realized and business strategy might not be easily implemented because of technical realities in the legacy application portfolio.
How to Mitigate: This may make it necessary to begin the process again at the pre-work stage, in order to reset the expectations of business leaders regarding the technical realities of the legacy application portfolio.
6. Public Cloud Providers Might Not Meet Your Requirements
You either may not be able to find a provider that meets your requirements, or your provider might lack the services you need to offer a complete service.
How to mitigate: Use an iterative approach when developing your requirements and evaluating the public cloud vendors. An iterative approach will aid in the development of realistic requirements and will also help you keep abreast of advancements achieved by cloud providers. Also, look at both managed & Unmanaged options Unmanaged options can be like IaaS in which database services run in a virtual machine. By nature, the managed options are more restrictive. The unmanaged IaaS options is a fallback used by some cloud customers.
7. The Requisite Skills are Not Available internally or From Partners
Cloud database migration is a new and growing area, so you might not be able to find the necessary skills amongst your staff. Also, potential partner organizations might be too expensive or otherwise unfeasible to work with.
How to mitigate: Address the skills issue early in the planning process and proceed with the migration project only as you can find or develop the necessary skills.
8. Your Database Might Not Perform Adequately in the Cloud
The platform differences between the cloud environment and the on-premises data center could result in functional inadequacies when the old app and database are moved to the cloud.
How to mitigate: Test the cloud database thoroughly during the planning steps to ensure that there are no unpleasant surprises after the migration. You might perform quick pilots or a proof of concept upfront for critical pieces of functionality and to check that they work as expected. Also, during the parallel run of the two systems, perform thorough testing to find any performance or capacity problems in the cloud-based system.
Strategies to Migrate Database to Oracle Cloud
Database Migration with Data Pump
An important consideration for a migration, particularly for the database tier, is the “endian-ness” of a platform. This refers to the way data is represented for a particular hardware and operating system, mainly the order in which bytes are stored in a word for memory addressing, networking, file storage, etc. A “big endian” platform stores the most significant byte first (i.e. starting at the lower address) while a “little endian” platform stores the least significant byte first.
Migration to a New Platform of the Same Endian Format
When the target of a database migration is of the same endian format, we recommend the use of the database migration process called Transportable Database (TDB) to migrate the database. While export/import (datapump) might be used, TDB represents the quickest way to migrate the database and is recommended.
Migration to a New Platform of Different Endian Formats
When the target platform is of a different endian format, there are two possible migration techniques.
1. Export/Import (Datapump)
Export/import using datapump has traditionally been used to perform Database migrations across platforms – this represents a full logical export of the database to a dump file which is then moved to the target machine before being imported.
2. Transportable Tablespaces
The alternative for migrating to a target platform of a different endian format is a more recently certified technique of migration called Transportable Tablespaces (TTS)
Oracle Data Pump allows customers to move data from one Oracle Database to another in a swift and efficient fashion. It supports 4 methods for database cloud migrations:
Data Pump Export / Import – Use Data Pump Export to create a dump of the source database, move that dump file to the target, and import it into the cloud database. (Supports the broadest matrix of source-target combinations).
Data Pump Full Transportable – Copy an entire database from your on-premises host to the database on the Oracle Cloud Database Service (compatible character sets required)
Data Pump Transportable Tablespace – This method is generally much faster than conventional methods because the data files containing all of the actual data are simply copied to the destination location. You use Data Pump to transfer only the metadata of the tablespace objects to the new database (certain compatibility between source and target are required).
Oracle Cloud – Full Support for the OnPrem Oracle Database Feature Set
In-addition to the OCI Deployment choices there is the consideration of the different editions of Oracle Database that your organization requires.
Enterprise package includes the Oracle Database Enterprise Edition, Data Masking and Subsetting Pack, Diagnostics and Tuning Packs, and Real Application Testing.
High Performance extends the Enterprise package with the following options: Multitenant, Partitioning, Advanced Compression, Advanced Security, Label Security, Database Vault, OLAP, Advanced Analytics, Spatial & Graph, Database Lifecycle Management Pack and Cloud Management Pack for Oracle Database.
Extreme Performance package extends the High Performance package with the following options: RAC (Real Application Clusters), In-Memory Database, Active Data Guard.
E-Business Suite and Oracle DB Support / Upgrade Path
- IF EBS CM is used
Upgrade Cloud Manager to Version 20.1.1.2.1.
Run the refreshExaDBMetadata.pl script to update the Cloud Manager metadata
