We strongly recommend that you migrate Oracle Databases running in an on-premises VMware environment to Oracle bare metal or virtual machine DB systems, Exadata DB systems, or Autonomous Databases running on Oracle Cloud Infrastructure. You can take advantage of all the benefits provided with the Oracle Cloud Infrastructure Database service.
Database Migration From an On-Premises VMware Environment
Whether you’re migrating existing application and middle tier systems from on-premises to Oracle Cloud VMware Solution, or creating application and middle tier systems on Oracle Cloud VMware Solution, key points to consider are latency and the proximity of the database to the Oracle Cloud VMware Solution platform.
- Create an Oracle Database or migrate an existing Oracle Database to Oracle
We highly recommend using the Oracle Cloud Infrastructure Database service. Different database service options are available in Oracle Cloud Infrastructure. You can choose the appropriate option depending on your application and workload requirements.
- Migrate non-Oracle databases to Oracle Cloud VMware Solution
This option is specific for non-Oracle databases such as Microsoft SQL Server, IBM DB2, and PostgreSQL. In this use case, you can migrate non-Oracle databases to Oracle Cloud VMware Solution by using the VMware HCX tool and migration best practices for the specific database.
- Maintain databases on-premises
This option mitigates the need to migrate your database systems from on premises to the cloud. However, latency and throughput might be key considerations for the impact on your applications. Consider solutions such as Oracle Cloud Infrastructure FastConnect for connectivity between Oracle Cloud VMware Solution and on premises.
Migrate Oracle Databases to Oracle Cloud Infrastructure
Before you migrate Oracle or non-Oracle databases from an on-premises data center to the Oracle Cloud Infrastructure, review the following considerations, prerequisites, and evaluation process.
This section applies to migrating on-premises Oracle Databases to Oracle Cloud Infrastructure, which includes the database platforms listed in the previous section. Before you start any migration effort, understand the individual database workload, restrictions, and any dependencies.
- What is the current version of this database?
- How many databases of this version will you be migrating?
- How many databases are tied to a specific line of business (LOB)?
- Are any databases on non-Linux platforms; that is, will there be any cross-endianness migration?
- Are there any dependent databases that might need to be migrated together?
- Are there any third-party databases (non-Oracle) to migrate, and which versions (for example, SQL Server 2016)?
- For test and development database, will all copies be migrated or just the master copy?
- How large are the databases—total disk space and space for the data itself in GB/TB?
- Will you use FastConnect or VPN for network connectivity to Oracle Cloud? The bandwidth and size of the database will primarily drive the migration solution.
There are many methods for migrating Oracle Databases from on-premises to Oracle Cloud Infrastructure. Each method depends on the business recovery point objective (RPO), recovery time objective (RTO), and overall availability service level agreement (SLA). Migration administrators must evaluate and map these business agreements with the appropriate methods.
Oracle Maximum Availability Architecture (MAA) specifically addresses these options and methods. The following table briefly discusses them.
|Solution||Complexity||Granularity of migration||Migration type (physical or logical)||Overall deployment effort||Migration model||Key migration use cases|
|Data Pump Conventional Export and Import||Low||Medium||Logical||High||Online/point in time||
|Data Pump Full Transportable||Medium||Low||Physical||Medium||Online/Continuous
Requires the source to be read-only during the export
|Full database with same endianness (requires source Oracle Database version 220.127.116.11)|
|Data Pump Transportable Tablespace||Medium||Low||Physical||Medium||Online/Continuous||Set of schema tablespaces (requires source Oracle Database version 18.104.22.168)|
|SQL*Loader||Low||High||Logical||High||Offline||Migrate specific tables or schemas|
|RMAN Backup and Restore||Low||Low||Physical||Low||Offline/Continuous||Full database or set of tablespaces|
|Data Guard||Low||Low||Physical||Low||Online/Continuous||Full database with zero or near zero downtime|
PDB Remote Cloning
Note:Many of the solutions can be combined to create the most efficient migration strategy. Some packaged applications might have restrictions on the tools supported for migration.
Sizing and Deployment Planning
Note:The capacity sizing effort for the database and VM is the same as on premises.
- Performance requirements of the workload
- Transactions per second
- Number of user connections
- Expected future workload changes
- Capacity requirements
- Storage and IO capacity
- Future growth
- Manageability requirements
- Oracle Cloud Infrastructure native services and accessibility
- Monitoring tools
- Backup solutions
- Scalability capabilities
- Database scale
- VM scale
- Cluster scale
- Availability requirements
- Oracle high availability solutions
- vMotion, DRS
- Application requirements
- Dependencies between on-premises components
- Network flow between applications and Oracle Cloud Infrastructure services
Rationalization, Standardization, and Consolidation
As part of the migration effort, we recommend that the migration team use this opportunity to standardize on the database version and consolidate database systems where appropriate. Oracle Database 19c should be the minimal standardized database version because it provides the long-term support release.
Consolidation is one of the major strategies that organizations are pursuing to achieve greater efficiency in their operations. Consolidation enables organizations to increase the utilization of IT resources, which lowers costs because fewer resources are required to achieve the same outcome. Operational costs are also reduced because fewer components and objects need to be monitored, managed, and maintained.
DBAs and Admins should look for the best opportunity to consolidate as many databases as possible. With Oracle 19c, you have the opportunity to use the Oracle multitenant option with a maximum of three pluggable databases (PDBs). This further provides greater economies of scale, and higher consolidation densities can be realized with application and database modernization. Therefore, you should determine which databases would fit into the container database (CDB) model of deployment.
Along with consolidation, consider isolation management. Isolation requirements can influence the method or degree of consolidation possible. The level of isolation that the system demands determines whether you consolidate multiple PDBs in a single database, host multiple databases on a single platform, or use some combination of both approaches. Isolation can be categorized into four areas: fault, resource, security, and operational. Each cloud model handles isolation slightly differently, using OS or database built-in capabilities, often combined with advanced features or products to provide a complete solution, commensurate with the risk.
Migrating to Oracle Database Service Using Oracle Zero Downtime Migration
It’s not in the scope of this article to provide detailed steps for zero downtime Oracle Database migration from an on-premises environment. You can follow the detailed steps outlined in Oracle Database: Move to Oracle Cloud Using Zero Downtime Migration.
- Oracle ZDM supports Oracle Database versions 22.214.171.124 and later.
- The source and target databases should use the same database version.
- Oracle ZDM supports Oracle Databases hosted on Linux operating systems.
- The source database can be a single-instance database migrating to a single instance or an Oracle Real Application Clusters (RAC) database, or it can be a RAC one-node or RAC database, migrating to a RAC database.
- Oracle ZDM supports Enterprise Edition and Standard Edition Oracle Databases as source databases. Enterprise Edition databases are migrated using Oracle Data Guard; Standard Edition databases are migrated offline using a backup and restore methodology.
- Oracle ZDM allows for the source database to be a non-container database (CDB) or a container database (CDB) with one or more pluggable databases (PDBs). If the source database is a non-CDB, it’s migrated as a non-CDB. If the source database is a CDB with one or more PDBs, ZDM migrates it to a CDB with the same set of PDBs as in the source CDB.
- To support migrations, ZDM uses features and functionality from the Oracle Fleet Patching and Provisioning (FPP) framework. For example, it uses the FPP job scheduler capabilities, which give full control for scheduling, pausing, and resuming any database migration task. ZDM also uses FPP’s evaluation mode to validate the migration process and detect possible failure conditions before the migration starts. ZDM includes audit capabilities during and after migration, and it distributes its migration process in distinctive phases, which lets users customize the workflow and add user action scripts at any step.