1. Migrate your on-premises VMware workloads to the cloud
  2. Migrate Oracle Database

Migrate Oracle Database

We strongly recommend that you migrate Oracle Databases running in an on-premises VMware environment to an Oracle Cloud Infrastructure Database service such as Oracle Exadata Database Service,Oracle Autonomous Database, Oracle Base Database Service, and so on. You can take advantage of all the benefits provided with Oracle Cloud Infrastructure Database services.

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.

Following are options for database proximity placement:
  • Create an Oracle Database or migrate an existing Oracle Database to Oracle Cloud Infrastructure

    We highly recommend an 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.

Considerations

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.

Every Oracle Database migration requires a discovery and planning phase. Key discussions in this phase should include the following questions. The answers to these questions help determine the grouping of databases, the number of databases to migrate, and the overall effort of the migration.
  • 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.

Migration Options

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
  • Small database
  • Schema subsetting
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 11.2.0.3)
Data Pump Transportable Tablespace Medium Low Physical Medium Online/Continuous Set of schema tablespaces (requires source Oracle Database version 11.2.0.3)
SQL*Loader Low High Logical High Offline Migrate specific tables or schemas
GoldenGate High High Logical High Offline/Continuous
  • Schema Subsetting
  • Logical transformation
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

Remote Cloning

PDB Relocation

PDB Migration

 Low Low Physical Low Online/Continuous
  • Existing 12c PDB to PDB migration
  • Remote cloning can be non-CDB

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

As part of the source migration effort, an appropriate sizing and planning exercise should be performed to ensure that the database meets capacity and performance requirements.

Note:

The capacity sizing effort for the database and VM is the same as on premises.
The results of this planning exercise help to define target database configuration and VM shapes.
  • Performance requirements of the workload
    • Transactions per second
    • Number of user connections
    • Expected future workload changes
  • Capacity requirements
    • vCPUs
    • Memory
    • 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

Oracle Zero Downtime Migration is the solution recommended by Oracle Maximum Availability Architecture (MAA) for migrating Oracle Databases to Oracle Cloud. Oracle Zero Downtime Migration has been designed with the goals of keeping the migration process as simple as possible and ensuring least impact on production workloads. The source databases can be on premises or in Oracle Cloud. Oracle Zero Downtime Migration automates the entire migration process, reducing the chance of human errors. It also uses high availability (HA) technologies that are integrated with Oracle Database, such as Oracle Data Guard, and follows all MAA best practices that ensure zero downtime of production environments.

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 Zero Downtime Migration provides the following database support and supported configurations:
  • Oracle Zero Downtime Migration supports Oracle Database versions 11.2.0.4 and later.
  • The source and target databases should use the same database version.
  • Oracle Zero Downtime Migration 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 Zero Downtime Migration 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 Zero Downtime Migration 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, Oracle Zero Downtime Migration migrates it to a CDB with the same set of PDBs as in the source CDB.
  • To support migrations, Oracle Zero Downtime Migration 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. Oracle Zero Downtime Migration also uses FPP’s evaluation mode to validate the migration process and detect possible failure conditions before the migration starts. Oracle Zero Downtime Migration 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.

When migrating from on-premises to the cloud, there are many source and target scenarios to consider. On-premises source applications and databases could both be running on VMware, or your applications might be running on VMware, while databases are running Oracle Database Appliance or Oracle Exadata. There are also multiple target cloud scenarios to consider such as applications running on Oracle Cloud VMware Solution, while databases could run on Oracle Base Database Service, Oracle Exadata Database Service on Dedicated Infrastructure, or Oracle Autonomous Database on Dedicated Exadata Infrastructure. See Explore More for detailed Oracle Database migration instructions according to source and target scenarios.