Oracle RAC Licensing Guide

Oracle RAC Licensing Guide

Oracle Real Application Clusters (RAC) is a powerful option for Oracle Database that enables a single database to run across multiple servers for high availability and scalability. However, RAC’s licensing requirements are complex.

This guide provides a practical overview of RAC and RAC One Node, explains where they are used, and breaks down the licensing models (on-premises vs cloud) and compliance considerations. It is intended for SAM managers and Oracle licensing professionals to manage Oracle RAC licenses proactively and avoid common pitfalls.

Overview of Oracle RAC and RAC One Node

Oracle Real Application Clusters (RAC) allows multiple Oracle Database instances to run on different servers (nodes) while accessing a shared database storage. All instances coordinate to present a single database to applications, improving availability and throughput. I

n a RAC environment, if one server fails, others continue serving the database, providing near-continuous uptime​. The combined CPU power of multiple nodes can also scale up performance beyond a single server’s capacity​. Typical RAC clusters range from 2 nodes to several nodes, all active concurrently.

Oracle RAC One Node is a variation that permits only one active database instance on one node at any time (with a second node as a hot standby). It provides single-instance failover capability: if the active node fails or needs maintenance, the database instance can fail over or migrate to another node with minimal downtime​.

RAC One Node offers high availability without multiple active instances, making it a lighter alternative to full RAC for smaller deployments. It’s an active-passive cluster: one node runs the database, and another is ready to take over if needed. This is useful for rolling maintenance and quick recovery from node failures, though it doesn’t provide load balancing across nodes like full RAC​.

Enterprise Edition Only: RAC (in both forms) is an extra-cost option available only with Oracle Database Enterprise Edition (EE). It cannot be used with Standard Edition databases​. (Oracle Database Standard Edition 2 does not allow multi-node RAC; Oracle offers Standard Edition High Availability (SEHA) in 19c+, a two-node failover solution akin to RAC One Node, at no additional license cost for SE2 users​. But full RAC clustering remains exclusive to Enterprise Edition.)

Common Use Cases for Oracle RAC

High Availability (HA): RAC is commonly deployed to eliminate single points of failure in database environments. If one server in the cluster crashes or is taken down, the database instance on another node continues to operate, so applications see no downtime. This makes RAC a go-to solution for mission-critical systems that require near 24/7 availability (e.g. banking systems, reservation systems).

Scalability and Performance: Because RAC allows a database to use the CPU and memory of multiple servers, organizations use it to scale out workloads. As demand grows, you can add nodes to a RAC cluster to increase capacity. The load balancing across instances can improve throughput for high-concurrency OLTP systems or large data warehouses that a single server might not handle.

Large-Scale Environments: Many large enterprise applications (ERP, CRM, financial systems) and data warehouse implementations use RAC to meet HA and performance requirements. RAC is prevalent in finance, telecom, and e-commerce industries, where downtime is costly and workload volumes are high. It’s also used in consolidation projects – instead of one huge server, a cluster of smaller servers can host a heavy database workload with RAC.

Oracle RAC One Node Use Cases: RAC One Node is suited for environments needing quick failover without full RAC complexity. For example, a smaller production system that still requires high availability might run on RAC One Node: the database runs on one server normally, and if that server has an issue, the instance can restart on a second server. It’s ideal for rolling patching of OS or database software (you can relocate the instance to the secondary node during maintenance)​. It provides HA for single-instance databases that don’t need active load distribution across multiple nodes.

In summary, use RAC when continuous availability and horizontal scaling are paramount, and consider RAC One Node for a simpler HA solution when only one active instance is sufficient.

Licensing Models for Oracle RAC (Enterprise Edition)

Oracle RAC is an add-on option license to Oracle Database Enterprise Edition, and its licensing must align with the database licensing model you choose. Two primary Oracle database licensing metrics exist: Processor and Named User Plus (NUP).

The same metrics apply to RAC:

• Processor Licensing – based on the number of processor cores used.
• Named User Plus Licensing – based on the number of named users who access the software.

Matching the Database License:

You must license RAC using the same metric as your Enterprise Edition database license (you cannot mix metrics). If your database is licensed per processor, RAC must be processor-licensed; if the database is licensed per NUP, RAC must be NUP-licensed​. Additionally, RAC option licenses are required for each database that uses RAC in your environment on top of the base database licenses.

Enterprise Edition Requirement:

Since RAC is only available on Enterprise Edition, ensure the underlying database is EE. It’s not legal to enable RAC on Standard Edition databases​. (If an Oracle LMS audit script finds RAC enabled on a Standard Edition installation, that’s a compliance red flag.) Each RAC cluster database will thus incur Enterprise Edition licensing plus RAC option licensing.

Processor vs Named User Plus (NUP) Licensing

For Oracle Database (and RAC), the choice between Processor and NUP licensing depends on whether you can count your users and the scale of deployment:

• Processor Licensing: You pay per CPU core (after applying Oracle’s core factor). This model is common in large or web-facing systems where users are numerous or unidentifiable​. It requires licensing every processor on every node of the RAC cluster. For example, a RAC cluster with eight nodes, each with two processors (16 processors total) must have 16 processor licenses for RAC​. Oracle’s Processor Core Factor table applies on-premises to adjust the processor count based on CPU type (for instance, many Intel CPUs have a 0.5 factor, so two cores = 1 licensed “processor”)​. Each Oracle RAC processor license costs roughly $23,000 per processor (list price)​. The base Database EE licenses would also be required in the same quantity.
• Named User Plus (NUP) Licensing: You pay for each distinct user (or device) that accesses the database. This can be cost-effective for smaller user populations. All human and non-human users who use the RAC database (directly or indirectly) must be counted​. Oracle imposes a minimum of 25 Named User Plus licenses per processor for Enterprise Edition​. This means in a RAC environment, you calculate the processor count of the cluster and multiply by 25 to get the minimum NUP required or license the actual user count, whichever is higher​. Each RAC NUP license is priced at roughly $460 per named user (list price)​

Comparison of Metrics:

Example – Licensing a RAC Cluster: Suppose you have a 2-node RAC cluster, each node with 8 Intel cores (16 total). The core factor for Intel is 0.5, so the cluster has 8 Processor licenses worth of CPUs.

You would need 8 Processor licenses for Oracle Database EE and 8 for the RAC option​. At list prices, that’s 8 × $47,500 for EE plus 8 × $23,000 for RAC (though discounts may apply). If you opted for NUP licensing and had 120 users, you must compare that to the minimum: 16 cores/2 = 8 processors * 25 = 200 NUP minimum.

Since 120 users are below 200, you’d need to license 200 Named Users Plus for the database and RAC option each. This illustrates that in multi-node environments, NUP minimums can exceed actual users, so Processor licensing might be more straightforward at a certain scale.

Important: The RAC option must be licensed for every processor or every user for which the database is licensed. In other words, if you have X processor licenses for the database, you need X processor licenses for RAC; if you have N NUP licenses for the database, you need N NUP licenses for RAC​. Oracle will audit and expect that the number of RAC licenses equals the number of database licenses used on RAC databases.

Licensing Per Node and Core

When calculating RAC licenses, remember that all nodes in the cluster count. Oracle’s rules require you to license every server where the database is installed and/or running. In a RAC cluster, the database is installed on all participating nodes, so each node’s cores must be fully licensed for both Database EE and the RAC option​.

It does not matter if one node is mostly idle or only used for failover (except in certain RAC One Node scenarios discussed later). It must be licensed if the Oracle software is installed on that node​.

Licensing per core is subject to the Processor Core Factor on-premises. For example, a node with 16 processor cores with a 0.5 core factor counts eight licenses. Oracle publishes a Core Factor Table to determine this for various CPU types (most modern x86 chips are 0.5). For Named User Plus, the core count influences the minimum NUP requirement as described.

In summary, cluster size directly affects the cost: more nodes or cores = more licenses. Even if your RAC database isn’t heavily using one node, you cannot license just a subset of the cluster in an active RAC setup – you must cover the entire cluster’s hardware. The only exception is in a true active-passive configuration (like RAC One Node or cold standby) under strict conditions (see failover rules below).

RAC Licensing: On-Premises vs Cloud

Licensing Oracle RAC in the cloud introduces additional considerations, as cloud instances use virtual CPUs, and Oracle has special cloud policies. The fundamental license metrics (Processor or NUP) remain the same, but how processors are counted can differ in cloud environments, and the type of cloud service matters (Infrastructure-as-a-Service vs Oracle’s own cloud services).

On-Premises (and BYOL Cloud) – If you are managing licenses yourself (Bring Your Own License on cloud VMs or traditional on-prem servers), count processors by physical cores (on-prem) or by vCPUs (cloud) according to Oracle’s formulas.

On-premises, you use the core factor; in authorized public clouds (AWS, Azure, Google Cloud), Oracle’s policy treats 2 vCPUs as equivalent to 1 Oracle processor license if hyper-threading is enabled​. For example, an AWS EC2 VM with eight vCPUs (with multi-threading) requires 4 Processor licenses. The Oracle Processor Core Factor is not applied to these public clouds – Oracle uses the simplified vCPU mapping instead. Named User Plus licensing on the cloud works similarly: you still must license all users (with the same 25-per-processor minimum, where “processor” is calculated via vCPUs)​.

Oracle Cloud Infrastructure (OCI):

Oracle’s own cloud distinguishes between License Included and BYOL offerings. If you use an Oracle Database Cloud Service with a License Included, you are essentially renting the licenses as part of the hourly rate – in that case, RAC usage is permitted if the service offering supports it (for example, Oracle offers Database Cloud Service configurations with RAC on two nodes for HA).

BYOL on OCI follows rules similar to other clouds: Oracle defines an “OCPU” on OCI, which equals one physical core (or two vCPUs with hyper-threading) – an OCPU is treated as one processor license. A two-node RAC on OCI with 4 OCPUs each would require 8 processor licenses (if BYOL). The benefit of OCI is that some high-end RAC features (like Oracle’s Engineered Systems or Autonomous Database) include RAC without you directly licensing it, because the cost is baked into the service fee. Always confirm whether a given OCI service is license-included or requires BYOL for RAC.

AWS/Azure:

Oracle RAC is not provided as a managed service on AWS or Azure (unlike single-instance RDS on AWS, which doesn’t support RAC). If you want RAC on these clouds, deploy it on compute instances (EC2, Azure VMs) with shared storage and use your licenses. Under Oracle’s cloud licensing policy (for Authorized Cloud Environments), you count vCPUs as noted (2 vCPUs = 1 license)​.

Also, Standard Edition’s usual cloud limits apply (Standard Edition 2 is limited to 8 vCPUs on AWS/Azure and does not allow RAC in any case). So, only Enterprise Edition with RAC BYOL is an option on AWS/Azure. Be mindful that if you use cloud auto-scaling or dynamically add nodes, any additional instance that runs the Oracle database would also require licensing.

Hybrid Cloud Considerations:

If your RAC spans on-prem and cloud (in a stretch cluster scenario) or you move workloads, ensure the licenses cover the maximum nodes that might be active. Oracle’s licensing is not elastic – you need licenses for peak usage, not average. However, if you decommission on-prem nodes in favour of cloud nodes, you may reallocate licenses accordingly (subject to any contract rules on cloud reassignments).

In short, the cloud doesn’t bypass RAC licensing—you still need to account for all processors or users. The counting method differs (vCPUs vs. physical cores), and Oracle has specific rules for public clouds​. Always review Oracle’s most current “Licensing Oracle Software in Cloud Environments” policy for up-to-date formulas and ensure your cloud architecture (e.g., the number of VMs in an RAC cluster) matches the licenses you have.

Oracle RAC and Virtualization

Many enterprises run Oracle databases on virtualized infrastructure (VMware, Hyper-V, KVM, etc.) or use Oracle’s own virtualization (Oracle VM Server or Oracle Linux KVM) to allocate CPUs. Virtualization does not reduce Oracle RAC licensing requirements unless it meets Oracle’s hard partitioning criteria. This is a critical point often misunderstood, leading to compliance issues.

Oracle classifies virtualization technologies into soft partitioning (not accepted for license reduction) and hard partitioning (accepted methods to limit licensing to a subset of cores). According to Oracle’s policy, most hypervisors (including VMware ESXi, Microsoft Hyper-V, and default KVM) are considered soft partitioning.

This means Oracle does not consider a VM’s virtual CPU assignment as a limit for licensing. Instead, you must license all physical cores in the underlying hosts where the Oracle software could run​ In practical terms,

if you run an RAC node on a VMware cluster, Oracle requires licensing every physical host in that VMware cluster that could host that RAC VM (even if the VM is pinned to certain hosts unless you have taken very specific measures)​The flexibility of VM migration (vMotion) triggers Oracle’s stance that the entire cluster is one environment. For KVM, if it’s the standard deployment with dynamic allocation, the same logic applies – all cores of the host or cluster might need licensing.

Oracle-Approved Hard Partitioning:

Oracle does allow certain configurations to count as hard partitioning, where you can license only a fixed subset of cores. Examples include Solaris Zones (capped), IBM LPAR with capped partitions, Oracle VM Server (OVM) with CPU pinning, and Oracle Linux KVM with hard partitioning enabled via Oracle’s documentation​. If you use Oracle VM Server, you can assign a VM to specific cores (and not allow it to run elsewhere); in such a case, Oracle permits licensing just those cores. Oracle Linux KVM from Oracle (with Oracle’s KVM management) can similarly be configured so that a VM is tied to certain cores and treated as a hard partition (Oracle provides docs on how to do this).

For RAC on VMware (considered soft partitioning), the typical policy implication is: if you have an RAC cluster of VMs spread across a vSphere cluster with (say) 10 physical hosts, you must license all 10 hosts’ cores for Oracle EE and RAC. This can be extremely expensive and is a common pitfall. Some companies create dedicated VMware clusters for Oracle workloads to contain the license scope (so you only license that smaller cluster). If using OVM or Oracle Linux KVM, you might restrict an Oracle RAC VM to, for example, 4 cores on a host with static assignment – Oracle would then accept licensing just those 4 cores (this must be documented per Oracle’s partitioning policy).

Key point: In virtualization, ensure your architecture aligns with your licenses. If using non-Oracle virtualization (VMware, etc.), assume you must license every possible host the RAC nodes can run on. If you want to limit licensing, consider Oracle’s virtualization solutions or physical segregation of Oracle servers. Oracle’s partitioning policies explicitly state that soft partitioning “is not permitted to limit the number of software licenses required.”​Violating this can lead to huge compliance gaps.

RAC One Node Licensing Considerations (Active-Passive Clusters)

Oracle RAC One Node has some special licensing implications because only one node is active. It is still licensed as an option to Enterprise Edition (except in the case where it’s included with SE2 for free). RAC One Node has a lower list price than full RAC, approximately $10,000 per processor (or $200 per NUP) versus $23,000 per processor for RAC​. This reflects its more limited capabilities.

When using RAC One Node on Enterprise Edition, you must license the active node’s processors (or all users) just like any RAC deployment. However, Oracle’s 10-day failover rule can apply to the passive node.

Oracle’s licensing rules permit a configured failover server to remain unlicensed until it is used, provided usage is limited to 10 days per year on that server​. In an active-passive cluster (one primary, one failover), this means you could license just the primary node’s CPUs for RAC One Node and have the secondary node set up as an “unlicensed spare” that only runs the database when a failover occurs.

As long as failovers (or live migrations) to the secondary don’t exceed 10 separate days per calendar year, Oracle permits not purchasing a license for that spare node​. Day 1 of usage on the spare counts as one of those ten days (even if it’s just a few minutes of use). If you exceed 10 days, you must also fully license that node.

Example:

You have a two-node cluster for RAC One Node. You bought licenses for Node A (primary) – say, four processors for DB EE and 4 for RAC One Node. Node B is installed with Oracle but is only used when Node A is down or during maintenance.

If Node A fails and you switch to Node B for 2 days in the year (and perhaps a couple of one-day maintenance switchovers), and it totals 5 days of Node B being active, you’re within the 10-day rule – Node B can remain unlicensed. Suppose you planned a longer migration (e.g., running on Node B for a month), that breaks the 10-day limit, so Node B would need to be licensed too.

Live Migration (Omotion): 

RAC One Node can perform a live migration of the running database instance to another node (Oracle calls this “Omotion”)​ . During such a migration, the instance might be running on both nodes (source and target) to transfer activity for a brief period.

In practice, Oracle still views this as part of your failover allowance. It’s typically done for planned maintenance and should be completed quickly. Ensure these events are counted towards the 10-day rule if the second node was unlicensed.

Multiple Nodes:

If RAC One Node is configured across over two nodes (e.g., one active and two potential failover targets). Generally, only one failover node can be unlicensed under the 10-day rule​. All other nodes that might host the database would need licenses. Oracle’s rule explicitly allows only one unlicensed spare server per cluster for failover.

So, if you had a 3-node cluster for RAC One Node (one active, two spares), one of those spares could be designated as the failover target (unlicensed until used). Still, if you want the capability to fail over to the third node, you would likely need to license it or at least not use it in failover unless in an emergency (which could still trigger compliance issues later).

Summary for RAC One Node:

You license the active node(s) according to normal rules (processors or NUP matching the EE licenses)​. You can have an idle standby node without a license, but monitor your usage – keep a log of any failover days. RAC One Node’s lower cost makes it attractive if you only need one active instance; just remember to license additional nodes if they run the database beyond the brief 10-day window. From a compliance standpoint, treat RAC One Node like regular RAC for the primary node and treat the secondary node as a special case that is essentially “free” only as long as it stays truly passive.

(Note: In Oracle Database Standard Edition 2 environments, Oracle includes a feature similar to RAC One Node for HA at no extra cost as of 19c (SEHA). This still only allows one active instance at a time on a two-node setup, but doesn’t require EE licenses. This guide focuses on Enterprise Edition scenarios, but SE2 users should know that option.

Compliance Enforcement and Audit Considerations

Understanding how Oracle detects and enforces RAC licensing is key to avoiding surprises. Oracle’s License Management Services (LMS, now Oracle GLAS) conducts audits using scripts and tools that check for installed options and usage. The RAC option is one of the database features these scripts look for.

Oracle’s LMS collection script will query views like V$OPTION and DBA_FEATURE_USAGE_STATISTICS to see if “Real Application Clusters” is enabled or used on any databases. For example, if a database was ever started in cluster mode, the feature usage might record a use of RAC. If the LMS audit output shows RAC as “TRUE” or with usage count > 0 for a given database, Oracle will expect that you have licensed the RAC option for that database’s processors/users. In an audit report, a line might indicate something like “Oracle Real Application Clusters – Used: Yes – Last Used: 2024-07-15” indicating that RAC was active on that instance. It doesn’t matter if it was only used briefly; any usage requires a license for the period installed.

Installed vs. Running:

Oracle’s contracts require licenses for any software “installed and/or running” on a server​. This means even if you installed the RAC option but didn’t actively use it, Oracle could ask for proof that it was never used. It’s safer to assume that you need the license if the Clusterware and RAC binaries are present and the database is configured as RAC. Oracle’s audit scripts typically capture usage stats and the cluster configuration (they can list the cluster name, number of nodes, etc., for each database). If a database is part of a “2-node RAC” and you only bought licenses for an instance, that discrepancy will be flagged.

Common Audit Findings: Some typical issues that audits reveal in RAC environments include:

• Unlicensed RAC usage on some servers: e.g., a development or test RAC database was set up without licenses, thinking only production needed them. Oracle requires licenses for all environments (unless using free Oracle Database Personal Edition or Standard Edition, which don’t support RAC anyway).
• Standard Edition with RAC enabled: as noted, Standard Edition 2 cannot use RAC. If a company upgraded from an older Standard Edition that allowed clustering to SE2 and left the cluster running, an audit will flag that as unlicensed use of RAC on SE2​.
• Insufficient Named User Plus counts: For example, if you have an RAC cluster with 8 processors but only 100 NUP licenses (when the minimum is 200), Oracle would identify the shortfall and require purchasing more NUP to meet the minimum​.
• All nodes not licensed: Sometimes organizations license some but not all nodes in an RAC cluster (perhaps misunderstanding failover rights). Every node must be fully licensed in a true RAC (multi-active) cluster​. Oracle might find that a DR node in a cluster wasn’t licensed outside the 10-day rule allowance.
• Virtualization compliance issues: Oracle auditors will review your VMware cluster configurations. They may request VMware vCenter documentation or verify if VMs with Oracle can move to hosts that weren’t licensed. It’s not uncommon for Oracle to assert that additional hosts need licensing if they find evidence (through logs or configuration) that an Oracle RAC VM could run there. This is a nuanced and often contentious area. Still, from a SAM perspective, it’s best to avoid ambiguity by adhering to Oracle’s partitioning policy (or having contractual clauses that specify allowed virtualization).

To prepare for an audit or self-assessment, consider running Oracle’s LMS scripts internally (or using Oracle’s provided ORAchk tool for license compliance) to see if RAC option usage appears​. Checking DBA_FEATURE_USAGE_STATISTICS in each database for “Oracle Real Application Clusters” usage is a good internal audit step. Also, ensure your Oracle Global Service Inventory (inventory.xml) and database parameter files are reviewed – they show if Clusterware is installed and if a database is configured as RAC.

Common Licensing Pitfalls with Oracle RAC

• Accidentally Enabled RAC: Installing Oracle software with RAC capabilities and creating a database on a cluster can trigger the RAC option, even if you didn’t intend to use it. For instance, if you use Oracle Grid Infrastructure for ASM and accidentally configure a database as cluster-enabled, the RAC option becomes active. Always double-check that CLUSTER_DATABASE=FALSE on single-instance databases, and do not install RAC components if you don’t have licenses.
• Not Licensing All Cluster Nodes: A classic mistake is to license only the active nodes and assume passive nodes don’t need licenses. With full RAC (multiple active nodes), all participating nodes are active, so none are truly passive – all must be licensed. Even with RAC One Node, as explained, the second node must be licensed if it’s ever used beyond the allowed limit. Ignoring a node in licensing counts can lead to a big compliance gap.
• Misunderstanding the 10-Day Rule: Some think the 10-day failover rule applies to any cluster or RAC. It only applies to a designated failover node in an active-passive setup​. It does not mean you can run half your RAC cluster for 10 days without licenses. Also, the 10 days are cumulative across the year​. Misusing this rule (e.g., rotating an active node every 10 days to avoid licensing both) would violate compliance.
• Named User Licensing in Large Deployments: Using NUP licensing for a RAC environment that serves many users can backfire. If the user count is high or poorly tracked, you might fall out of compliance by exceeding your licensed NUP count. Additionally, if the hardware is sizable, the NUP minimums might require more licenses than you anticipated. Many organizations start with NUP to save cost but forget to true-up when user counts grow. Always monitor user counts against your NUP licenses, and remember the per-processor minimum threshold​.
• Virtualization and DR Mix-ups: Running RAC on VMware without understanding Oracle’s licensing stance can lead to huge exposure. Similarly, using technologies like VMware SRM or stretch clusters across sites could mean your RAC is “installed” on many hosts. Oracle believes all those must be licensed (unless proven otherwise). Another pitfall is assuming a disaster recovery RAC (or standby RAC database) doesn’t need licensing. If it’s a standby open for read (Active Data Guard) or an RAC used for DR drills, it does need full licensing (with ADG option as well, if used). Only truly idle, powered-off backups of RAC databases avoid licensing, and even then, the Clusterware installation should be considered.
• Mixing Edition or Option Usage: Enabling RAC implicitly means using Enterprise Edition (since RAC is not allowed on SE). Sometimes, DBAs inadvertently enable RAC features on a Standard Edition database (for example, by trying SE2 High Availability, which, if done incorrectly, might be seen as RAC). Ensure the edition and options align with what you purchased – no “accidental Enterprise features” on Standard Edition and no “accidental RAC” on a single instance that wasn’t meant to be clustered.

Best Practices for Managing RAC Licensing

To stay compliant and optimize costs with Oracle RAC, consider these best practices:

• Architect with Licensing in Mind: When designing RAC clusters, factor in the licensing cost of each node. If a requirement can be met with RAC One Node instead of multi-node RAC, evaluate the cost savings (RAC One Node’s lower price and potential to leave one node unlicensed on standby can cut costs significantly​). Conversely, if uptime requirements demand full RAC, plan the budget for all nodes. Avoid sprawling RAC deployments if a simpler HA solution suffices.
• Contain Oracle Workloads: If using virtualization like VMware, dedicate specific hosts or clusters to Oracle RAC. This limits the number of physical processors you need to license. For example, have a small ESXi cluster solely for Oracle databases, separate from your general VM farm, to avoid licensing the entire environment. Also, disable auto-migration of Oracle RAC VMs to unlicensed hosts (no vMotion outside the licensed cluster).
• Use Hard Partitioning if Possible: If you run RAC on Oracle’s virtualization (OVM or Oracle Linux KVM), configure pinned CPUs per Oracle’s partitioning guidelines so you only license what you use. Document these settings to show auditors. For instance, if your RAC VM is pinned to 4 cores on an 8-core host, ensure you have Oracle’s acknowledgement (via policy document or support note) that this is a hard partition scenario.
• Monitor Feature Usage: Regularly check the feature usage stats on your databases. Oracle provides the view DBA_FEATURE_USAGE_STATISTICS which will show “Oracle Real Application Clusters” usage. If you see any “YES” or usage counts on a database that shouldn’t be using RAC, investigate immediately. It could be a misconfiguration. Proactively disabling or uninstalling unused options (using Oracle’s chopt tool or not linking RAC libraries) can prevent accidental usage.
• Track and Limit Failover Time: If using RAC One Node or any failover cluster, maintain a log of failover occurrences. Ensure the total is within the 10-day rule if you choose not to license the standby node. If you foresee a scenario exceeding 10 days (e.g., a prolonged data centre migration), arrange to purchase temporary licenses or migrate licenses to cover that period to stay compliant.
• Review User Counts (NUP) or Processor Changes: For NUP-licensed environments, periodically audit how many named users can access each RAC database. Reconcile this with your license count. If the business adds users (or new apps connect to the database), update your licensing counts or convert to processor licensing if thresholds are passed. For Processor-licensed environments, keep an eye on hardware upgrades – adding CPUs or upgrading to chips with different core factors could increase your required license count​.
• Stay Updated on Licensing Policies: Oracle’s rules can evolve (e.g., changes in cloud licensing rules or partitioning definitions). Ensure you refer to the latest Oracle Partitioning Policy document for virtualization and the cloud licensing policy for any cloud deployments​. Also, verify license implications when upgrading database versions or editions (for example, if Standard Edition 2 HA now provides an alternative to RAC, consider if that affects your future strategy).
• Engage Oracle Expertise: Managing Oracle licensing is complex. It may be worth involving Oracle license specialists or SAM consultants to perform periodic compliance checks, especially before an official Oracle audit or when significant architecture changes happen (like moving to the cloud or expanding a cluster).

Now that we understand the mechanics and pitfalls of RAC licensing, let’s summarize the key recommendations for ensuring compliance and optimizing your Oracle RAC licensing.

Recommendations

1. License Every RAC Node – Ensure all servers running or configured for an Oracle RAC database are fully licensed for Oracle Database Enterprise Edition and the RAC option. There is no concept of partial licensing for active RAC nodes – if Oracle software is installed on a node, include it in your license count​. (Exception: one designated failover node in an RAC One Node setup can be excluded until it’s used beyond 10 days) Always double-check that you have purchased the RAC option licenses equal to the number of database licenses used on the cluster​.
2. Use Enterprise Edition Only – Do not attempt to use RAC with Standard Edition databases. If your organization runs Standard Edition 2, leverage Oracle’s SE2 High Availability feature for clustering instead of RAC, or upgrade to Enterprise Edition for true RAC. Remember that RAC (and RAC One Node) are only legal on Enterprise Edition​.
3. Align Metrics and Quantities – Match your RAC licensing metric to your database licensing metric. If you license the database by processors, license RAC by processors; if by NUP, license RAC by NUP in the same quantity​. Keep track of Oracle’s NUP minimums (25 per processor for EE) and ensure your user counts meet those requirements​. If your user count is approaching the minimum threshold times cores, consider switching to processor licensing to simplify compliance.
4. Monitor and Disable Unused Options—Regularly audit your databases for RAC option usage. Use Oracle’s feature usage views or run LMS scripts internally to see if RAC (or any extra-cost option) appears as used​. If an option is not needed, disable it (for RAC, this might mean converting a database to a single instance or removing Clusterware). Preventing accidental usage is far easier than justifying it in an audit.
5. Plan for High Availability Wisely – Choose RAC vs RAC One Node based on needs and cost. For full active-active scalability and HA, the budget for RAC is on all nodes. If you primarily need failover capability, consider RAC One Node to save on licensing – you’ll pay about 40% of the full RAC’s cost per processor​ and can keep a spare node unlicensed under the 10-day rule​. Make sure to script or automate failovers in RAC One Node so they’re quick and track the failover duration.
6. Contain Oracle Deployments in Virtual Environments – If running RAC on VMware or other hypervisors, isolate those VMs to dedicated hosts/clusters that are fully licensed. Do not allow Oracle RAC VMs to drift onto hosts that aren’t licensed – use affinity rules or dedicated clusters. This avoids the scenario of needing to license an entire virtualization farm​. If your virtualization platform supports it, pin VMs to specific cores and follow Oracle’s hard partitioning guidelines to possibly reduce license counts, but always get confirmation (e.g., via Oracle’s policy docs or a signed contract amendment).
7. Document Your Architecture and Policies – Keep records of your RAC cluster configurations, the nodes involved, and how they are licensed. Document each failover event with dates and duration if using a failover node under the 10-day rule​. Having this documentation ready can help address questions in an audit. Also, document any virtualization restrictions (like “Oracle RAC VMs run only on Hosts A, B, C in cluster X”) to demonstrate your compliance boundaries.
8. Educate DBAs and IT Staff – Ensure the technical teams understand the licensing impact of enabling RAC. They should know that spinning up a new RAC instance or adding a node isn’t just a technical action but has licensing implications. Implement internal approval processes for deploying RAC or RAC One Node so the licensing team can verify entitlements beforehand. Small mistakes (like creating a test RAC database without approval) can lead to big compliance issues.
9. Use Oracle’s Tools and Support – Utilize Oracle’s tools, such as Oracle Enterprise Manager’s License Management Pack or ORAchk’s “Health Check for Licensing,” to continuously monitor usage. Oracle’s support site provides the official LMS collection tool – consider running it before Oracle asks, so you see exactly what they would see​If any ambiguity arises (for example, how licensing applies in a specific cloud scenario or uncommon cluster setup), don’t hesitate to reach out to Oracle or verified licensing experts in writing for clarification. Having an official statement can be valuable.
10. Prepare for Audits Proactively – Conduct self-audits regularly. Simulate an Oracle audit by collecting data on installations and feature usage. Address gaps – e.g., purchase additional licenses if needed or reconfigure systems to stay compliant – before Oracle’s auditors come in. This avoids penalties and positions your team as diligent and in control of your licensing. Pay special attention during Oracle ULA (Unlimited License Agreement) certification or renewal; if you have a ULA that includes RAC, ensure all deployments are accounted for before the ULA ends.

By following these recommendations, your organization can effectively manage Oracle RAC licensing, ensuring high availability for your databases without high risk on the compliance side.

Oracle RAC can deliver tremendous benefits for uptime and performance, but it must be handled with a clear licensing strategy in mind. Always keep communication open between your technical teams and license management functions so that deployments align with entitlements. With careful planning and oversight, you can leverage RAC’s capabilities confidently while staying in line with Oracle’s licensing policies.