Real Application Clusters Licensing

Real Application Clusters is a priced Enterprise Edition option licensed on every node where it runs, using the same processor or Named User Plus metric as the database, so the buyer move is to license only the nodes that genuinely need it.

How is Real Application Clusters licensed?

Real Application Clusters is licensed as a priced Enterprise Edition option that follows the database metric on the nodes where it runs. If the database is licensed by processor, the RAC option is licensed by processor on the same cores, with the core factor table applied. If the database uses Named User Plus, the option follows that metric with its own minimums. RAC is not a feature you can switch on for free, so its presence on a node carries both a database cost and an option cost, and both must be entitled.

Do you license every node in the cluster?

You license the database and the RAC option on every node that participates in the cluster, because each node runs an instance of the clustered database. A four node cluster therefore carries database and option licensing across all four nodes, counted by core with the core factor applied. This is why cluster size is a direct lever on exposure. Adding a node to a clustered database adds licensable cores for both the database and the option, so cluster growth is a licensing decision, not just a capacity one.

Is RAC available on Standard Edition 2?

Real Application Clusters on Enterprise Edition is a separately priced option, and recent releases removed the bundled clustering capability that earlier Standard Edition releases carried. That means you should confirm both your edition and your entitlement before relying on clustering. A team that built a cluster expecting the old Standard Edition behaviour can find itself outside entitlement on a newer release. Reading the edition and the option entitlement against the contract, and flagging anything contract dependent as contract dependent, settles the question before a finding does.

How do you keep the cluster scoped?

You keep the cluster scoped by limiting RAC to the nodes that truly need high availability or scale, rather than letting it spread across every host in a rack. Many estates carry clusters larger than the workload requires, often because the cluster grew with the hardware. Right sizing the cluster to the nodes that genuinely run the clustered database reduces both the database and the option footprint. The buyer side discipline is to treat each node added to a cluster as an explicit licensing choice with a documented justification.

Where do RAC findings overcount?

RAC findings overcount when they assume the option runs on more nodes than it does, ignore the core factor, or fold standby and spare nodes into the active cluster count. A cold standby node that is not running the clustered instance is a different licensing position from an active cluster member. Separating the active cluster from standby arrangements, and applying the correct core factor to the right cores, removes the inflation a finding builds in when it treats the whole hardware pool as one live cluster.

A worked example

Consider an anonymized telecommunications firm whose finding counted a six node cluster as fully clustered when only three nodes ran the clustered database and three were independent. The defense separated the active cluster from the standalone nodes, applied the correct core factor, and confirmed the option entitlement against the contract. The RAC exposure halved against the opening figure. No client names, sector level example only.

The buyer moves

The buyer moves are to map which nodes actually run the clustered database, apply the correct core factor to those cores, separate active cluster members from standby and standalone nodes, and confirm edition and option entitlement against the contract. Each move keeps the RAC line tied to the real cluster rather than to the full hardware pool.

Where to go next

This piece links up to the Oracle Database Licensing Guide. Keep reading across the cluster: