Oracle RAC Licensing Explained

Real Application Clusters is one of the most expensive database options Oracle sells, and its cost is driven less by the option price than by the counting rule that every node must be fully licensed. Teams that deploy RAC for high availability often discover the licence bill doubles, because the option sits on top of the database on every core in the cluster. This article explains how RAC is licensed, where the cost comes from, and how to contain it. It extends the database licensing pillar and connects to the options and packs problem.

What is Oracle RAC and how is it licensed?

Real Application Clusters lets a single database run across multiple server nodes simultaneously, providing both scalability and resilience. For licensing, the important fact is that RAC is an extra cost option on Enterprise Edition, not a feature of the base database. Deploying it adds a second per processor charge on top of the Enterprise Edition charge, applied to the same cores.

The licence requirement therefore has two layers on every node: the Enterprise Edition database itself, and the RAC option. Both are counted on the full processor core count of each participating node, with the core factor applied. There is no concept of licensing RAC on a fraction of the cluster.

RAC as a database option

Because RAC is an option rather than a separate product, it inherits the database's metric. If the database is licensed by Processor, RAC is licensed by Processor on the same cores. If the database is licensed by Named User Plus, RAC follows the same user count subject to the option's own minimums. This coupling means the RAC decision cannot be made independently of the underlying metric choice covered in processor versus Named User Plus.

The option model also means RAC is subject to the same inadvertent use risk as any other option. A clustered configuration that uses RAC features without the option licensed produces an audit finding in exactly the way an unlicensed management pack does, a pattern explored in the options and packs article.

Counting cores across cluster nodes

The counting rule is simple to state and expensive to apply: every node that participates in the cluster must be licensed in full, for both the database and the option. A node cannot be partially licensed, and a cluster cannot have some nodes licensed for RAC and others not. If a server can run an instance of the clustered database, its full core count enters the calculation.

The table makes the doubling visible. A two node cluster of modest 16 core servers needs 32 processor licences before any other option is added. Each extra node adds its full core count twice, once for the database and once for RAC, so cluster growth is the dominant cost driver.

RAC under Named User Plus

When the underlying database is licensed by Named User Plus rather than Processor, RAC follows the same user population, but the option carries its own processor based minimum. The minimum is calculated from the cluster's total processor count, so a sparsely used RAC cluster can still owe a substantial number of Named User Plus licences for the option purely because of the core count. The interaction between the user metric and the processor minimum is the subject of the Named User Plus minimums article, and RAC sharpens it because the minimum applies to the option as well as the database.

RAC One Node and the Standard Edition path

Two lower cost routes exist. RAC One Node is a separate, cheaper option that provides a single active instance with fast automated failover to another node, rather than multiple concurrently active instances. It suits availability requirements that do not need active active scaling. The nodes it can run on must still be licensed for the database, but the option charge is lower than full RAC.

The second route is Standard Edition 2, which includes a restricted form of RAC at no extra option cost, subject to a strict socket limit. This is a genuinely different entitlement, not the Enterprise Edition option, and it cannot be scaled beyond the Standard Edition socket cap. For estates whose availability needs fit within those limits, it is the cheapest clustered option available, a point developed in the Standard Edition 2 article.

The total cost of a RAC cluster

The total cost of a RAC cluster is the Enterprise Edition licences for every node, plus the RAC option licences for every node, plus any other options in use such as Partitioning or the management packs, plus annual support on all of it at the standard support rate. Because each of these stacks on the same core count, the cost compounds quickly. A cluster running Enterprise Edition, RAC, Partitioning, and the Diagnostics and Tuning packs is paying four or more per processor charges on every core.

This compounding is why RAC clusters are disproportionately represented in large audit findings and renewal disputes. The disciplined response is to model the full option stack on the actual core count before deployment, and to confirm that every active option is both needed and licensed. That modelling is part of the database licensing service.

The buyer side view

The buyer side view of RAC is that the availability benefit is real but the licence model is unforgiving, so the cluster size and the option stack must be deliberate. Size the cluster to the availability requirement rather than to consolidation convenience, prefer RAC One Node or Standard Edition clustering where the requirement allows, and confirm every option on the cluster is licensed before an audit confirms it for you. For the full option modelling and worked clusters, see the database pillar, the database licensing white paper, or request a consultation.

Where RAC audit findings arise

RAC audit findings arise in two ways. The first is a node that can run the clustered database but was never licensed, often a standby or maintenance node added after the original purchase. Oracle counts it because it can participate in the cluster, and the customer's records do not, producing a finding equal to a full database plus option licence for that node. The second is RAC features detected as in use on a database that was only licensed for Enterprise Edition without the option, the classic inadvertent option use.

Both are defended by reconciling the actual cluster topology against the entitlement and by establishing whether the detected feature use reflects genuine RAC operation or a benign artefact. This reconciliation is part of the audit defence practice, and it depends on having an accurate, current map of which nodes belong to which cluster.

Alternatives that lower the RAC bill

Several alternatives reduce the RAC bill without abandoning resilience. RAC One Node provides automated failover at a lower option cost where active active scaling is not required. Standard Edition 2 clustering suits estates within the socket cap. A traditional active passive failover configuration using a standby node may avoid the RAC option entirely if it stays within the limited failover allowances Oracle provides, a topic covered in the disaster recovery licensing article.

The right alternative depends on the recovery time objective, the scaling requirement, and the existing estate. The common thread is that the resilience goal should drive the architecture, and the architecture should then be licensed deliberately, rather than reaching for full RAC by default and absorbing the doubled cost. Modelling these alternatives against the actual availability requirement is exactly the kind of analysis that separates a contained estate from an overlicensed one.

RAC and disaster recovery interaction

RAC and disaster recovery licensing compound when a clustered production database also has a standby. The standby cluster, if it applies data, is licensed like production, which means the RAC option is required on the standby nodes as well as the primary ones. A two node primary RAC cluster with a two node standby RAC cluster therefore needs the database and the RAC option on all four nodes, quadrupling the option cost relative to a single unclustered server.

The limited failover allowance offers narrow relief within a single cluster, letting one node cover a failed node for up to ten days a year under strict conditions, but it does not extend to a separate standby cluster applying data continuously. The interaction between clustered scaling and resilience is one of the most expensive in the database estate, and it is set out alongside the standby rules in the disaster recovery licensing article. Sizing both the cluster and its recovery topology deliberately is the only way to keep the compounded cost defensible.

RAC on virtualised infrastructure

Running RAC on a virtualisation platform combines two of the most expensive rules in Oracle licensing. The cluster nodes must each be fully licensed for the database and the RAC option, and the soft partitioning rule means each virtual node is licensed for the physical host it runs on, not the virtual cores assigned to it. A virtualised RAC cluster spread across a shared host pool can therefore expose the full core count of every host the nodes could reach, doubled for the option.

The containment strategy mirrors the soft partitioning approach: isolate the RAC nodes onto dedicated physical hosts so the licensable boundary is the cluster's own hardware rather than a shared pool. Where that isolation is not enforced, the exposure can dwarf the intended cluster size. The mechanics of the soft partitioning rule that drives this are covered in the soft partitioning article, and the combination is a frequent and large audit finding.