Before You Begin
Before you begin migrating resources and applications, consider the migration options and provision and migrate any necessary application databases.
You can provision application databases as separate databases, or as pluggable databases (PDBs) within the container database (CDB) of a single database system.
Both Oracle Grid Infrastructure (which supports multi-node DBs) or Logical Volume Manager are supported.
Note:
To use database migration tools such as Zero Downtime Migration (ZDM), the target database SYS password must be the same as the SYS password of the source database to be migrated.There are a number of migration strategies you can use depending on workload complexity and on downtime requirements.
For information about provisioning a database, see Provision a Virtual Machine Database earlier in this document.
About Migrating Workloads
This section presents a number of common migration scenarios.
One set of options migrates on-premises workloads to a newly created domain on Oracle Cloud Infrastructure:
- Manually migrate workloads using the WebLogic Administrator Console to deploy resources and one of the following methods to deploy applications:
- WebLogic Administrator Console
- JDeveloper deployment tools
- Migrate workloads using WebLogic Deploy Tooling (WLDT).
- Migrate workloads using the WebLogic Scripting Tool by targeting existing application deployment scripts to the new domain.
Another option is to update the WebLogic Server tooling that you use to deploy domains on premises (such as WebLogic Scripts, or WebLogic Deploy Tooling model files) and target them to Oracle Cloud Infrastructure to create a new domain and re-deploy applications.
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.
- 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 |
|
| 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 |
|
| 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 |
|
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
- 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.