A Quick Guide to licensing, architecting, and migrating on-prem Oracle databases to the cloud

This article attempts to share experiences learned by assessing legacy on-premises Oracle environments of customers planning to migrate to the Cloud. This is not an exhaustive technical guide for migrating Oracle workloads to the Cloud; instead, it highlights the key considerations, like Licensing, HA/DR, etc., when planning the migration.

The intended audience is anyone involved in such a migration project, be it Project Managers, Solution Architects or DBAs.

Hosting an Oracle Database in the Cloud

Oracle databases can theoretically run on any of the following cloud environments

• AWS EC2*
  – Shared tenancy
  – Dedicated Hosts
• AWS RDS*
• MS Azure VM*
  – Shared tenancy
  – Dedicated
• OracleDB@Azure
• Bare Metal
  – AWS Bare Metal Instance
  – Azure BareMetal Infrastructure
  – Google Cloud’s Bare Metal Solution
• VMWare on Cloud
  – Azure VMWare Solution (AVS)

Each hosting option has pros and cons when deciding upon a solution. Later in this article, we compare the hosting options vis-à-vis important evaluation parameters.

* Cloud computing environments using AWS EC2, AWS RDS, or MS Azure VM are known as an Authorized Cloud Environment for hosting and licensing Oracle databases (and, in general, most Oracle Software).

Licensing Oracle

Types of Oracle Database licenses

• Processor licensing is based on the processors (Enterprise Edition) or sockets (Standard Edition) required to run the Oracle database. It is often used in environments where a high or unknown number of users are accessing the system.
• User Plus (NUP) licensing is based on the number of users accessing the system and is usually suitable for smaller or non-production environments.

To better understand the Oracle licensing, it is important to understand the following two concepts:

• Oracle’s Core Factor

Ref: https://www.oracle.com/assets/processor-core-factor-table-070634.pdf

• Oracle’s Cloud licensing policy

Ref: https://www.oracle.com/assets/cloud-licensing-070579.pdf

Calculation of Oracle database licenses

The number of Oracle database licenses required depends on the hosting platform, i.e., the server type and specifications. Understanding the following concepts is important to understanding how an Oracle database is licensed.

Authorized Cloud Environments

For licensing purposes, two vCPUs on any of the ‘Authorized Cloud Environments’ are counted as equivalent to 1 processor license if multithreading** is enabled, and one vCPU is equivalent to 1 processor license if multithreading is not enabled.

** Multithreading is a property of CPUs that allows multiple threads to run on a single core. A thread on the Cloud is the same as a vCPU (virtual CPU). Hence, if multithreading is enabled, 2 vCPUs can run on a single physical core, and hence, 1 Oracle processor license is required. Note that multithreading can only be enabled/disabled when launching a VM on AWS/Azure.

Bare Metal Environments

Hosting an Oracle database on bare metal infrastructure in cloud environments is like hosting on on-premises physical servers. Hence, the license calculation uses the ‘Core Factor Table’. Using the table, you must determine the ‘Core Processor Licensing Factor’ for your vendor and processor type.

Let’s take an example:

• We want to license Oracle EE on an Intel CPU with 16 cores
• A factor of 0.5 applies to an Intel-based bare metal infrastructure
• This means the number of Oracle licenses required exceeds the number of physical cores on the server. i.e., if the server has 16 physical cores, then 8 Oracle processor licenses are required to host Oracle databases on that server.

However, consult the core factor table for the factor applicable to your specific server specs.

High Availability and Disaster Recovery

Apart from licensing, another critical aspect that could prove decisive is the solution’s High Availability and Disaster Recovery. Providing a suitable HA and DR solution is about wholistically meeting the application’s defined SLAs (typically RPO and RTO).

Let’s first look at the native Oracle solutions traditionally used in on-premises setups:

• Real Application Clusters (RAC) — Most common High Availability solution that deploys Oracle in a cluster of 2 or more nodes and protects against failure of one or more nodes. The database continues to function as long as one node is available.
• Data Guard — A Disaster Recovery solution that works on a primary database and one or more standby databases that are kept in sync with the primary using synchronous or asynchronous replication.
• RMAN — Oracle’s native backup utility is usually an integral part of the overall HA/DR strategy for every Oracle shop.

When migrating Oracle databases to the Cloud, most legacy shops expect to meet or improve their existing SLAs and, hence, similar solutions to those they have used. However, Cloud environments are limited in providing solutions for HA and DR, which is important to understand before making decisions.

Alongside Oracle’s native features, most cloud environments have native features that can be used to build resilient architectures. However, it is important to know that Oracle RAC is not a supported or certified feature in most cloud environments. Though theoretically, there are ways to create a RAC setup, and if you need Oracle for support, you will be on your own. Instead, it is recommended that Data Guard be used for both HA and DR capabilities on the Cloud as it has been proven to meet the most stringent SLAs in legacy setups. Other than that, some Cloud native features that are usually deployed are:

• Regions and Availability Zones
• Inbuilt multi-AZ capabilities
• Snapshots

Reference Architecture

Here is a typical architecture for hosting Oracle on an Azure VM-based solution within a region across multiple AZs (The same can be done with EC2 instances on AWS):

• This architecture leverages Oracle Data Guard to provide HA and DR capabilities across availability zones within a region.
• The same architecture can also be extended to provide inter-region DR capabilities by having a standby in another region.
• An observer has been deployed in another AZ to provide automated failover capability.

Comparing the Hosting Options

Finally, we will compare various hosting options for Oracle databases on Cloud based on multiple evaluation parameters.

Let’s first get our definitions right:

AWS EC2 (or Azure VMs)

This is the IaaS solution on AWS/Azure in a shared tenancy model.

Dedicated Hosts (not the bare metal type)

This is the IaaS solution on AWS/Azure in a dedicated tenancy model where the host is dedicated to the organization.

AWS RDS

This is an AWS PaaS solution i.e. the managed database service

OracleDB@Azure

This is the Azure PaaS solution where Oracle Exadata database service runs on OCI and collocated Azure Data Center.

Azure VMWare Solution (AVS)

Similar to VMWare on-premises, this is the VMWare running on Azure infrastructure

Bare Metal Environments

Bare Metal instances provide you with physical CPUs, not virtualized CPUs and don’t run under a hypervisor

Oracle Licensing:

AWS EC2 (or Azure VMs)/ Dedicated Hosts/ AWS RDS

• Core Factor does not apply
• Comes under the ‘Authorized Cloud Environment’ policy
• Soft partitioning, i.e. all vCPUs on the server need to be licensed

OracleDB@Azure

· Core Factor does apply

· Hard partitioning, i.e. license required for provisioned oCPUs only

AVS

• Core Factor does not apply
• Comes under the ‘Authorized Cloud Environment’ policy for Oracle licensing
• Soft partitioning, i.e. all cores on the VMC/AVS cluster, need to be licensed

Bare Metal Environments

· Core Factor does apply

· Soft partitioning i.e. all vCPUs on the server need to be licensed

High Availability and Disaster Recovery (HA/DR):

AWS EC2 (or Azure VMs)/ Dedicated Hosts/ Bare Metal Environments

· RAC on ‘authorized cloud environments’ is not an Oracle-supported or certified solution, though deploying RAC using features like AWS multi-attach EBS volumes might still be possible. Support needs to be sourced externally from a third-party

• Use Data Guard across multiple Availability Zones to provide the HA/DR capabilities and meet the SLAs

AWS RDS

RDS provides a multi-AZ feature that allows the database to be run in 2 availability zones in an active-passive manner

OracleDB@Azure

• RAC can be deployed and is supported by Oracle for HA
• Data Guard can be used for DR

AVS

• RAC can be deployed in an on-prem hosted VMWare infrastructure
• Data Guard can be used for DR

Scalability:

AWS EC2 (or Azure VMs)

• On-demand/ flexible model, No upfront capacity commitment with a pay-as-you-go model for scaling in or out
• Instance size can be changed, more instances can be created, or existing ones can be removed as required.
• Any additional capacity will incur both infra and Oracle licensing cost

Dedicated Hosts (not the bare metal type)

• Upfront capacity commitment, i.e. Infra and licensing, are paid off once. Hence, if there is any spare capacity, more databases can be added without provisioning more infra or buying more Oracle licenses.
• Scaling ‘out’ means buying a full host worth of infra, and Scaling ‘in’ means spare capacity cannot be released.

AWS RDS

• On-demand/ flexible model, No upfront capacity commitment with a pay-as-you-go model for scaling in or out
• Vertical scaling can be done by changing the size of instance
• Any additional capacity will incur both infra and Oracle licensing cost

OracleDB@Azure

• This is an on-demand/ flexible model; no upfront capacity planning is required. More databases and oCPUs can be provisioned as required.

AVS

• The upfront capacity planning and commitment is required, i.e., Infra and licensing, are paid off once. Hence, if there is any spare capacity, more databases can be added without provisioning more infra or buying more Oracle licenses.
• Scaling ‘out’ means buying a full host worth of infra, and Scaling ‘in’ means spare capacity cannot be released.

Bare Metal Environments

• Upfront capacity commitment, i.e. Infra and licensing, are paid off once.
• To add more capacity and databases, a new bare metal instance will be required. Bare metal instances usually start from a minimum of 64 vCPUs

Support for Database Versions:

AWS EC2 (or Azure VMs)/ Dedicated Hosts/ AVS/ Bare Metal Infrastructure

Any version, as long as the customer has support from Oracle or a third party

AWS RDS

• Version > = 19c are fully supported on RDS for Oracle***
• Support for version 12c has been deprecated.

*** AWS RDS Custom can be used to deploy lower versions, but it is not a fully managed version of the RDS service

OracleDB@Azure

• Version > = 19c are fully supported
• Lower versions up to 11g are only supported with a valid Oracle support contract.

Migration Method:

AWS EC2 (or Azure VMs)/ Dedicated Hosts/ Bare Metal Infrastructure

• Data Guard is the recommended Migration method
• Block replication tools like AWS Application Migration Service or Azure Migrate (offline mode) can also be used for lift and shift migration.

AWS RDS

Data Guard is the recommended Migration method

OracleDB@Azure

Oracle ZDM (automated solution from Oracle)

AVS

Lift and Shift Migration methods like vMotion

Conclusion

There are no right or wrong answers. The right cloud hosting option for Oracle databases depends on multiple factors and parameters, as highlighted above, and needs to be evaluated based on your current setup and future requirements. The most common reasons customers choose one solution over another are the TCO and the impact on their risk profile.

The best approach is to assess these parameters thoroughly and seek expert advice from your partners based on your landscape.