There are many times when you want to move to Azure but don’t have the liberty of re-platforming the database due to the dependency of applications. Don’t despair, there are still ways to move your workload. Azure has support for Oracle! We previously showed a way to almost run an Oracle Database as a Service on Azure, but if you have a line of business (LOB) application or an application that requires support for high availability, it is also possible:  Presenting Azure support for Oracle disaster recovery including Oracle Data Guard.

Oracle Support on Azure

Oracle supports running Oracle DB 12.1 Standard and Enterprise editions in Azure on virtual machine (VM) images based on Oracle Linux.   Oracle has guaranteed license mobility from on-premises to Azure. “These images are considered “Bring Your Own License” and as such you will only be charged for compute, storage, and networking costs incurred by running a VM. It is assumed you are properly licensed to use Oracle software and that you have a current support agreement in place with Oracle.

Licensing Details

Microsoft Azure is an ‘Authorized Cloud Environment.’   Under this program, “count two vCPUs as equivalent to one Oracle Processor license if hyper-threading is enabled, and one vCPU as equivalent to one Oracle Processor license if hyper-threading is not enabled.” Please note that unlimited license agreements (ULAs) may also be used.

High Availability

Any conversation about this topic requires us to look at the recovery time objective (RTO) and recovery point objective (RPO) of an application. In our application, this is how long the database can be down as well as the maximum amount of data loss that can be tolerated. Oracle defines well-known reference architectures based on RTO & RPO objectives.

Assuming we require comprehensive high availability (HA) and disaster recovery (DR), real-time failover and zero/near-zero data loss, an implementation using Oracle Data Guard will be pursued.

Oracle Data Guard

Data Guard is one offering from Oracle that ensures high availability, data protection, and disaster recovery for enterprise data. It uses a standby database (exact replica) to survive outages of any kind and data corruptions. This technology is available in Oracle Enterprise Edition.   Oracle also provides, as a separately licensed product, Oracle Active Data Guard; this technology allows for real-time data protection and disaster recovery and expands capabilities.

A few key features from Oracle regarding Oracle Data Guard are:

  • Fast redo transport for best recovery point objective (RPO), fast apply performance for best recovery time objective (RTO)
  • Fast failover to a standby database to maintain availability should the primary database fail for any reason
  • Automatic or automated (depending upon configuration) re-synchronization of a failed primary database, quickly converting it to a synchronized standby database after a failover occurs.
  • Reduction of planned downtime by utilizing a standby database to perform maintenance in a rolling fashion

Oracle Real Application Clusters (RAC) was also considered, but it is not supported on any cloud environment other than Oracle’s.

Oracle Data Guard on Azure

Microsoft recommends — for the best performance of Oracle DB production workloads on Azure — to be sure to properly size the VM image and use Managed Disks that are backed by Premium Storage.

Azure provides the M-Series virtual machines that are ideal for extremely large databases or other applications that benefit from high vCPU counts and large amounts of memory.

Azure also provides a Managed Disk offering called Ultra SSD that can scale performance up to 160,000 IOPS. IOPS are “an input/output performance measurement used to characterize computer storage devices.” Database performance is often constrained by the performance of the underlying storage; therefore, utilizing the Ultra SSD offering, you can be sure to minimize this concern.

Another key concept to enable this high availability scenario is to leverage Azure availability sets for the virtual machines. Availability sets are a fundamental technology that makes our scenario possible.

  • Each virtual machine in your availability set is assigned an update domain and a fault domain by the underlying Azure platform.
  • Update domains allow for a virtual machine to recover before maintenance on another virtual machine is initiated on a different update domain.
  • Fault domains define the group of virtual machines that share a common power source and network switch.
  • Managed disks provide better reliability for availability sets by ensuring that the disks of VMs in an availability set are sufficiently isolated from each other to avoid single points of failure.

Availability zones, an alternative to availability sets, expand the level of control you have to maintain the availability of the database VMs. With Availability Zones, Azure offers a 99.99% VM uptime Service Level Agreement (SLA).

Lastly, Azure Site Recovery (ASR) provides an additional level of disaster recovery via its ability to orchestrate replication, perform disaster recovery testing, and run failovers and failback; ASR is fully compatible with Oracle Data Guard on Azure.

A logical architecture using a virtual network (VNET) and subnets (isolation & projection), Oracle DB VMs, premium storage, and Oracle Data Guard is presented below.

Diagram of VM architecture

AIS recently participated in a joint proof of concept (POC) where this architecture was deployed with M128 VMs and premium storage and achieved the following goals:

  • ~35TB Database (Oracle Table Limit)
  • ~30-45 second failover under user load of 5000- 15,000 concurrent users with Zero Data Loss
  • Active Data Guard Running in Max Availability (SYNC, Successful Failover)
  • Can handle both planned and unplanned failovers
  • Achieve 120,000 IOPS
  • Can be further secured using Network Security Groups (NSG) and Application Security Groups (ASG)

Visit our website to find out more about our work with Microsoft Azure, or contact AIS today to get started with Oracle DB on Azure!

Let’s say you are trying to move an Oracle database to Azure, but don’t want to go down the route of creating an Oracle Database in an Azure VM for obvious reasons: You don’t want to be responsible for maintaining the VM’s availability, hotfixes patching, etc. At the same time, let’s say you do want to take advantage of a fully-managed persistence service that offers local and geo-redundancy and the ability to create snapshots to protect against accidental deletes or data corruption.

It turns out that the latest advancements in Azure Container Instances (ACI), combined with the ability to deploy them in a VNET, can get you close.

Let’s start by reviewing the architecture.

Architecture diagram

We can host an Oracle DB container image inside Azure Container Instances (ACI). ACI is a container-as-a-service offering that removes the need to manage the underlying virtual machines. It also eliminates the need for setting up our orchestrator. Additionally, ACI-hosted containers (Linux only for now) are placed in a delegated subnet. This allows the Azure container instance to be available from inside a VNET without the need to open a public endpoint.

Finally, the data files (persistent) aspect of the database resides in Azure Files, which removes the need to manage our durable storage since Azure Files takes care of the local and geo-redundancy. Additionally, Azure Files can take snapshots, allowing us a point-in-time restore ability.

(Azure Files also support Virtual Network service endpoints that allow for locking down access to the resources within the VNET.)

ACI also offers fast start times, plus policy-based automatic restarting of the container upon failure.

Here are the three steps to get this setup working:

Step One

Create the ACI hosting Oracle Database Server 12.2.01 that mounts an Azure File share and is connected to a delegated subnet.

az container create -g <> --name <> --image registry-1.docker.io/store/oracle/database-enterprise:12.2.0.1 --registry-username <> --registry-password <> --ports 1521 5500 --memory 8 --cpu 2 --azure-file-volume-account-name <> --azure-file-volume-account-key <> --azure-file-volume-share-name <> --azure-file-volume-mount-path /ORCL --vnet <> --vnet-address-prefix <> --subnet <> --subnet-address-prefix <>

Step Two

This step is a workaround that could be eliminated if we had access to the Docker file used to create this image.  We are essentially copying /oradata files containing the control files, data files, etc. to the Azure file share.

mkdir -p /u02/app/oracle/oradata/ORCL; cp -r /u02/app/oracle/oradata/ORCLCDB/. /u02/app/oracle/oradata/ORCL/

Step Three

Connect to the Oracle database from the VNET.

Since the Oracle DB container is created in a VNET, a private IP address is assigned to the container.  We can use this IP to connect to it from inside the VNET.

That’s it! We now have an Oracle database without the need to maintain the underlying VM or data volume.

Let’s Talk Pricing

Azure Container Instances bill per second at the “container” group level. “Container group” resources like vCPU/ Memory are shared across multiple containers sharing the same host

The current pricing per second is listed below:

Container group duration:
Memory: $0.0000015 per GB-s
vCPU: $0.0000135 per vCPU-s

The setup we defined above (8GB memory and two vCPUs) will cost ~$100/month based on the following pricing calculation:

Memory duration:

Number of container groups * memory duration (seconds) * GB * price per GB-s * number of days

1 container group * 86,400 seconds * 8 GB * $0.0000015 per GB-s * 30 days = $31.1

vCPU duration:

Number of container groups * vCPU duration (seconds) * vCPU(s) * price per vCPU-s * number of days

1 container groups * 86,400 seconds * 1 vCPU * $0.0000135 per vCPU-s * 30 days = $69.98

Total billing:

Memory duration (seconds) + vCPU duration (seconds) = total cost

$31.1 + $69.98 = $101 per month

Almost! But not completely there!

As the title suggests, the approach mentioned above gets us close to our objective of “Oracle DB as a service on Azure” but we are not all the way there. I would be remiss not to mention some of the challenges that remain.

Our setup is resilient to failure (e.g., policy-based restart) but this setup does not offer us high availability. For that, you will have to rely on setting up something like the Oracle Data Guard on Azure.

ACI supports horizontal scaling and as such the vertical scaling options are limited to current ACI limits (16GB and four vCPU).

ACI VNET Integration capability has some networking limits around outbound NSGs and public peering that you need to aware of.

I’d like to thank Manish Agarwal and his team for help with this setup.