Oracle on Azure

This Blogs aims to explain why Azure is a better destination than GCP/OCI/AWS for migrating on-premises Oracle workloads, including Oracle proprietary databases, business applications, custom applications, and ISV applications.

There are multiple options on Hosting Application leveraging Oracle as DB, Based on complexity i have categorised this into different solution categories.

Oracle on Native Azure VM

In Rehost or ‘Lift and Shift’ scenarios, on-premises workloads are migrated to run on Azure Native Virtual Machines (VMs). This approach involves moving your Oracle Database (DB) to standard Azure VMs, which you manage yourself, offering flexibility and cost savings compared to fully managed services.

Recommending native Azure VMs for Oracle workloads is appropriate in specific scenarios, balancing trade-offs between performance, management effort, and cost. Here are the key use cases:

• Small to Medium Workloads: Ideal for databases where high performance isn’t critical, such as smaller Online Transaction Processing (OLTP) or analytical workloads. Standard VM hardware often suffices, reducing costs compared to Exadata-based managed services like Oracle Database@Azure.

• Cost-Sensitive Projects: When budget constraints are a priority, native VMs avoid the premium pricing of managed services and specialized hardware. Using constrained core vCPUs can further lower Oracle licensing costs, making this option attractive for budget-conscious projects. (Architectures for Oracle Database on Azure Virtual Machines)

• Custom Configurations: If you require specific hardware or software setups unavailable with managed options—such as custom OS images or unique storage configurations—native VMs provide the flexibility to meet those needs.

• Non-Critical Applications: Suitable for development, testing, or less critical applications where downtime or performance hiccups are tolerable. This includes environments where experimentation is common, and managed services might be excessive.

• Full Control and Compliance: When regulatory or compliance requirements (e.g., data residency laws or security policies) demand complete control over the database environment, native VMs allow you to configure settings like Network Security Groups and Azure Firewall to align with those needs. (Overview of Oracle Applications and Solutions on Azure)

Oracle Licensing on Native Azure VMs

There are some constraints around Oracle Database licensing when running on native VMs in cloud environments like Azure or GCP. Microsoft Azure follows this licensing model:

• With Multi-Threading Enabled: Two vCPUs are counted as equivalent to one Oracle Processor license.

• With Multi-Threading Disabled: One vCPU equals one Oracle Processor license.

For this reason, we recommend using constrained vCPU VM series.These VMs offer the same underlying memory, throughput, and network capabilities as standard VMs but with a limited vCPU count. This helps fit within Oracle’s per-core licensing model, reducing costs.

How Constrained VMs Work:

• In a hyper-threaded VM, Azure allocates 2 threads per core, known as vCPUs.

• When hyper-threading is disabled, Azure presents single-threaded cores (physical cores), resulting in a 1:1 vCPU-to-CPU ratio.

Recommended Constrained VM SKUs for Oracle: Check the list of available sizes here: List of Available Sizes with Constrained vCPUs.

Pros

• Ideal Migration Scenarios: Perfect for cases where Oracle is currently running on Hyper-V or physical servers. Azure’s right-sizing tools, paired with constrained VM SKUs, make it a seamless fit for these environments.

• High Availability (HA): Oracle Databases in a Real Application Clusters (RAC) setup are used for HA. While RAC isn’t officially certified by Oracle on Azure, you can achieve HA using Azure’s native capabilities, such as Availability Zones and Oracle Data Guard replication across zones. This provides redundancy at both rack and datacenter levels.

• Cost Reduction: Using constrained VM SKUs reduces Oracle licensing costs without significantly impacting performance for many workloads.

• Licensing Optimization: Disabling multi-threading or hyper-threading on regular Azure VMs adjusts the CPU ratio to 1:1, further lowering license costs.

Cons

• Licensing Complexity: Oracle’s licensing rules can be challenging in cloud environments. You’ll often need to navigate Bring Your Own License (BYOL) scenarios and ensure VM configurations align with Oracle’s core-counting policies.

• RAC Limitations: Although high availability is achievable with Azure’s native features, RAC is not officially certified by Oracle on Azure, which might deter some users relying on official support.

Oracle on AVS (Azure VMware Solution)

In Scenario where customers are running their Oracle Databases on VMware environment, easiest migration path would be moving VMware on cloud with easier lfit & shift approach using VMware VMotion or Bulk migration method.

Although there are license contrains here as well, will though details one by one

Oracle does not recognize VMware as a hard partitioning technology, which has significant implications for licensing. Hard partitioning allows users to license only a subset of a server’s processors, thus offering more control and potentially lowering costs. However, since Oracle considers VMware a soft partitioning tool, customers must license all physical cores accessible by the Oracle software.

Careful management of VMware clusters is essential to minimize licensing costs. Cluster segregation can be an effective strategy to avoid having to license an entire vCenter. Organizations can limit the number of physical cores that need to be licensed by isolating clusters that run Oracle software. This requires rigorous VMware management practices to ensure that Oracle workloads are restricted to designated clusters and do not migrate freely across environments that are not fully licensed.

Key Points

Oracle makes a distinction between soft partitioning and hard partitioning in its licensing model:

• Soft Partitioning: Technologies that allow for dynamic allocation of resources but do not provide Oracle-recognized methods to limit the number of processors being used. VMware falls under this category, requiring licensing of all cores accessible.

• Hard Partitioning: Oracle-approved methods to limit resource usage to specific cores, such as Oracle VM Server, IBM LPAR, and certain physical hardware partitioning tools. These technologies allow sub-capacity licensing, making them more cost-effective in environments with fewer Oracle workloads.

For example, consider a 3-node AVS cluster using AV36P nodes, where each node has 36 physical cores:

• Total cores = 3 nodes × 36 cores/node = 108 cores.With a core factor of 0.5 (typical for Intel CPUs with hyper-threading), the number of processors to license = 108 × 0.5 = 54 processors.

• Oracle Database Enterprise Edition costs approximately $47,500 per processor (per Oracle’s Technology Global Price List). Thus, the licensing cost = 54 × $47,500 = $2,565,000.

Example: If a company has Oracle deployed on a VMware cluster with 3 Hosts, all of those hosts’ cores must be licensed, regardless of how many virtual CPUs are allocated to Oracle in the environment. Even if only a portion of the virtual CPUs is actively running Oracle, the company must account for all the physical hardware.

This makes AVS an expensive option for Oracle workloads unless mitigated by specific licensing agreements, such as an Unlimited License Agreement (ULA).

Strategies to Manage Licensing Costs

To minimize licensing costs:

• Cluster Segregation: Isolate Oracle workloads to a dedicated cluster (e.g., a 3-node AV36 cluster). This limits the number of cores requiring licenses but demands strict management to prevent Oracle VMs from migrating to unlicensed clusters via vMotion.

• Rigorous Management: Use VMware tools to enforce boundaries, ensuring Oracle software does not inadvertently span across the entire vCenter environment, which would require licensing all accessible cores.

Unlimited License Agreements(ULA):

• • ULAs allow unlimited use of specified Oracle software for a fixed term, avoiding per-core or per-cluster licensing.

    • For AVS, the ULA must include a license mobility clause, enabling on-premises licenses to be applied to the cloud. Oracle’s strategic partnership with Microsoft supports this mobility (per the Oracle and Microsoft Strategic Partnership FAQ).

    • This provides flexibility to scale Oracle deployments on AVS without additional licensing costs during the ULA period, making it a cost-effective option for large enterprises.

Pros

• Familiarity and Ease of Use: If your team uses VMware on-premises, AVS lets you stick with the same tools, reducing the learning curve and potential errors for managing Oracle databases.

• Enhanced Security: AVS offers a private cloud on dedicated hardware, providing better isolation for sensitive Oracle data, which is crucial for compliance.

• Similar Setup: AVS mirrors your on-premises VMware environment, so you can move your Oracle VM with minimal changes, reducing migration time and complexity.

• Familiar Tools: Using the same management tools means less learning and fewer errors, speeding up the process.

• Automated Migration: AVS provides tools designed for VMware migrations such vMotion,svMotion, automating much of the work, unlike native VM which may need more manual setup.

Cons:

• Lack of Scalability Savings: Businesses cannot license only the cores they need; instead, they must license all cores that could potentially run Oracle software, regardless of actual use.

• Higher Costs: Organizations often face exponentially higher costs because Oracle insists on licensing all the cores within a given cluster or data center rather than the specific hosts or VMs running Oracle.

• Compliance Challenges: The movement of virtual machines between physical hosts through VMware’s vMotion further complicates compliance, as the potential for Oracle workloads to migrate triggers the requirement to license more physical cores.

• Technically Oracle RAC supported on VMware environment, but as per Oracle policy is not officialy certified to run on non oracle public clouds

Oracle Database@Azure(Exadata)

Oracle Database@Azure is a service where Oracle databases run on Exadata X9M hardware within Microsoft Azure's data centers. This setup ensures low latency access to Azure resources, making it ideal for customers wanting Oracle’s database performance within Azure’s ecosystem.Enterprise-critical features like Oracle Real Application Clusters (Oracle RAC), Oracle Data Guard, Oracle GoldenGate, managed backups, self-managed Oracle Recovery Manager (RMAN) backups, Oracle Zero Downtime Migration (Oracle ZDM), on-premises connectivity, and seamless integration with other Azure services are supported.

Key features include:

• High Performance with Exadata X9M HardwareIt currently runs on Oracle Exadata X9M hardware, with configurations starting at a quarter-rack (minimum 2 database servers and 3 storage servers), scalable up to 32 database servers and 64 storage servers.

• Private Connectivity via Azure Virtual Network: customers can deploy Oracle Exadata within their Azure Virtual Network (VNet), using private IP addresses for secure, isolated access without public internet exposure, Helps meet data residency and security requirements, critical for industries like BFSI

• High Availability: Supports Oracle Real Application Clusters (RAC) and Oracle Data Guard for redundancy and disaster recovery, with built-in redundancy and failover capabilities and offer SLA of 99.9%

• Sub-1 Millisecond Network Latency:When applications and the database are in the same Azure region, network latency can be sub-1 millisecond due to co-location within Azure data centers.

• Integration with Azure Services: Integrates with Azure’s ecosystem, including Microsoft Entra ID for identity management and Azure AI/ML services,Combine Oracle’s database capabilities with Azure’s AI tools for advanced analytics or generative AI applications.

• Simplified Migration and Compatibility: Full compatibility with on-premises Oracle Database and Exadata deployments, supported by tools like Oracle Zero Downtime Migration,Lift and shift on-premises workloads to Azure without refactoring, minimizing migration effort and risk.

• Managed Service with Clear Responsibility Matrix: Oracle manages the Exadata hardware, Oracle Database software, and operating system (Oracle Linux 8.6+), while Microsoft manages the Azure infrastructure, and customers manage data, applications, and VNet.

• Cost Management and Licensing : Available through the Azure Marketplace with options to use existing Oracle licenses (BYOL) or Microsoft Azure Consumption Commitments

• Oracle Database software includes Enterprise Edition, with supported versions from 12c to 23c, customer-selectable based on compatibility and needs.

Responsiblity Matrix for Oracle Exadata

Oracle Software Stack in Exadata

• Oracle Database Software Versions: software includes Enterprise Edition, with supported versions from 12c to 23c, customer-selectable based on compatibility and needs.

• Additonal Components: Data Guard for high availability and disaster recovery & Golden Gate for data replication for DR

• Operating System: Oracle Linux 8.6 Later

• Licensing: Customers can bring their own Oracle Database licenses (BYOL) or purchase them through the Azure Marketplace,

Oracle Exadata X9M Overview

Oracle typically offers the X9M in several rack‑scale configurations:

• Quarter Rack:
  • Typically includes 2 database servers and 3 storage servers.
  • Often used for smaller-scale or departmental workloads.

• Half Rack:
  • Generally configured with 4 database servers and 6 storage servers.
  • Balances performance and capacity for medium‑sized enterprises.

• Full Rack:
  • Usually features 8 database servers and 12 storage servers.
  • Designed for very large, mission‑critical deployments requiring maximum throughput and IOPS.

Hardware Specifications for Oracle DB Exadata(X9M)

Exadata X9M consists of database servers and storage servers, with different configurations for high capacity (HC) and potentially extreme flash (EF)

Database Servers:

• The database servers in Exadata X9M, as used in Oracle Database@Azure, are equipped with advanced compute capabilities. Research suggests the following specifications, based on Exadata Cloud Services X9M documentation:

• Processor: 1 x AMD EPYC 7J13, offering 64 cores and 128 threads. The base clock speed is 2.6 GHz, with a turbo frequency up to 3.5 GHz, providing high performance for database operations (AMD EPYC 7J13 Processor)

• Cores: 64 cores, with 128 threads, supporting high compute workloads.

• Memory: 512 GB, expandable, supporting large in-memory database workloads, as seen in Exadata Cloud Services X9M configurations (Exadata Cloud Services X9M Specifications).

• Storage: 2 x 3.84 TB NVMe Flash SSD for local storage, with the option to expand to 4 x 3.84 TB, ensuring fast access to frequently used data (Oracle Exadata Database Machine Hardware Components).

Storage Server (High Capacity - HC):

• CPU Manufacturer and Family: Intel, specifically the Intel Xeon Scalable 4th generation (codenamed Sapphire Rapids), with the model being Intel® Xeon® Gold 6448Y

• Cores: 32 cores total, with 2 processors each having 16 cores, operating at 2.6 GHz, based on Exadata X9M HC storage server specs

• Memory: 256 GB DDR4 for general operations and 1.5 TB Persistent Memory, allocated for Exadata RDMA Memory (XRMEM)

• Storage: Includes 12 x 18 TB 7,200 RPM SAS HDDs for bulk storage (total raw capacity 216 TB) and 4 x 6.4 TB NVMe Flash SSDs for caching (total 25.6 TB)

Cons:

Cost: Oracle Exadata on Azure uses specialized Exadata hardware and is a managed service, likely resulting in higher costs compared to running Oracle on standard Azure VMs. Customers can choose from a variety of VM sizes in Azure VM, potentially finding more cost-effective options, especially with constrained vCPU VMs to reduce Oracle licensing costs

Scalability: Exadata on Azure offers scalability in predefined rack configurations (quarter-rack to full-rack), which might not be as flexible as scaling individual VM sizes in standard Azure VM. Customers can choose from various VM sizes in Azure VM, including constrained vCPUs for cost savings, offering more granular scaling.

Reference Artcile:
https://docs.oracle.com/en-us/iaas/Content/database-at-azure/oaa.htm
X9M: https://docs.oracle.com/en-us/iaas/exadatacloud/doc/exa-service-desc.html#GUID-EC1A62C6-DDA1-4F39-B28C-E5091A205DD3
License: Counting Licenses on Azure AVS - Palisade Compliance
Implementation: https://docs.oracle.com/en-us/iaas/Content/database-at-azure-exadata/odexa-exadata-services-azure.html