Oracle RAC One Node Licensing

Oracle RAC One Node Licensing

Oracle RAC One Node is a specialized Oracle Database option that enables high availability through an active-passive cluster model. It enables enterprises to run a single active database instance on a cluster and fail over to a secondary node when necessary.

This advisory explains how Oracle RAC One Node licensing works, its differences from full Oracle RAC, and how IT asset managers at global enterprises can optimize costs while remaining compliant.

What is Oracle RAC One Node?

Oracle Real Application Clusters One Node (Oracle RAC One Node) is essentially a single-instance failover solution for Oracle Database Enterprise Edition.

In a RAC One Node configuration, only one node is active at any given time, running the database instance, while another node stands by as a hot spare for failover.

If the active node goes down or requires maintenance, the database can quickly fail over to the standby node, minimizing downtime.

Unlike full RAC (Real Application Clusters,) which has multiple active instances across nodes, RAC One Node provides high availability without the complexity of managing multiple concurrent database instances.

This makes it ideal for use cases where continuous uptime is required but horizontal scaling (active-active load distribution) is not.

For example, a financial services application that can run on a single server might utilize RAC One Node to ensure a backup server can take over instantly in the event of failure, providing near 24/7 availability without requiring two servers to run simultaneously.

Key characteristics of Oracle RAC One Node:

• Active-Passive Cluster: Only one database instance is running (active) at a time, with one designated failover node ready to take over if needed.
• High Availability Focus: Designed to minimize downtime via quick failover, suitable for mission-critical systems requiring reliability (e.g., ERP systems, banking applications).
• Simpler Than Full RAC: Offers easier administration than full RAC, as there’s a single active instance, while still enabling rolling maintenance (you can relocate the instance to the standby node during patching and then move it back).
• Enterprise Edition Option: Available only as an add-on to Oracle Database Enterprise Edition (EE). (Note: Oracle Standard Edition 2 (SE2) includes a similar two-node failover capability at no extra license cost, often referred to as Standard Edition High Availability, but full RAC clustering is exclusive to EE.)

Licensing Model and Key Rules

Oracle RAC One Node is an optional extra-cost feature for Oracle Database EE, which requires a separate license in addition to the base database licenses.

The licensing model for RAC One Node has strict rules that enterprises must follow to remain compliant:

• License Metrics Match the Database: You must license RAC One Node using the same metric and quantity as your Oracle Database EE licenses. If your database is licensed per processor, then RAC One Node must be licensed per processor on the active node. If your database is licensed by Named User Plus (NUP), the RAC One Node option must have an equal number of NUP licenses. This one-to-one alignment ensures consistency and compliance. (You cannot mix metrics; for example, you cannot have the database on processor licensing and the RAC One Node option on NUP.)
• Primary vs. Failover Node: Only the primary (active) node requires full licensing for the RAC One Node option under normal operations. Oracle permits one designated failover node to remain unlicensed until a failover occurs, under a specific rule (the “10-day rule”). This means you initially only pay for licensing the server where the database normally runs. The standby server can have the Oracle software installed and ready to go without a separate license – as long as it’s truly idle except during failover events.
• Oracle’s 10-Day Failover Rule: The failover (secondary) node can be used temporarily without additional licenses for up to 10 cumulative days per calendar year. This rule lets you handle unexpected outages or routine maintenance by failing over to the secondary node without immediate licensing consequences. However, if the standby node runs the database beyond 10 separate days in a year, Oracle requires that you purchase full licensing for that node as well. The 10 days are counted as 10 distinct 24-hour periods of usage – so even short failovers on different days will accumulate. Enterprise ITAM teams must carefully track any failover occurrences to ensure they do not exceed this limit.
• One Unlicensed Spare per Cluster: Oracle’s policy only allows one spare node to be exempt from licensing under the failover rule. In a cluster with more than two nodes, only a single designated standby node can go without a license. Any additional nodes configured for potential failover or load must be fully licensed. This is important for more complex HA architectures – you can’t have multiple unlicensed standby servers waiting; only one gets the free 10-day allowance.
• Included with SE2 for No Cost: As a special case, Oracle Database Standard Edition 2 includes a built-in high availability feature (as of version 19c and later) that is essentially RAC One Node capability on a two-node cluster. For SE2 users, this doesn’t require any extra licensing fee. However, SE2 has its limitations (like maximum 2 CPU sockets and other restrictions), and it does not support full multi-node RAC. Enterprise users mostly running Enterprise Edition should note this inclusion for smaller environments or non-production setups where SE2 could be an option.

Cost and Pricing Considerations

One of the main reasons organizations consider Oracle RAC One Node is the cost savings compared to licensing full RAC for high availability.

RAC One Node’s pricing reflects its single-active-node nature, making it significantly cheaper than the full RAC option.

Below is a comparison of Oracle’s list prices (which are subject to Oracle’s discounting and negotiations in enterprise contracts) for RAC One Node versus full RAC:

The pricing shown is an approximate Oracle list price. Actual pricing may vary based on Oracle’s official price list updates and negotiated discounts.

From the above, an enterprise with a given number of processors can license RAC One Node for approximately half the cost of full RAC. For example, suppose you have an Oracle EE database running on four processors and you need high availability:

• Using Oracle RAC One Node, you would license four processors for the RAC One Node option. At roughly $ 10,000 each, that’s about a $40,000 list price (on top of the base database EE licenses). Your secondary failover server would initially cost $0 for the option until a failover occurs.
• Using full Oracle RAC, you would need to license all processors on both nodes for the RAC option, as both nodes can be active simultaneously. If each node has four processors (eight total), at approximately $ 23,000 each, that’s about $184,000 as the list price for the RAC licenses. Full RAC is almost an order of magnitude more expensive in this scenario, because you’re paying for clustering across all nodes.

Cost Drivers and Considerations:

• *Processor vs NUP: The choice between processor or Named User Plus licensing can greatly affect cost. Processor licensing is straightforward for large-scale or externally-facing systems. In contrast, NUP licensing can be economical if you have a limited, known user population (keeping in mind Oracle’s minimum of 25 NUP per processor). Always calculate both models — sometimes the required NUP count (due to Oracle’s minimums) can erode the cost advantage if you have a large number of processors.
• Support Fees: Remember that annual support is typically calculated as ~22% of the net license fees. So a higher license cost for full RAC also means higher recurring support costs year over year. RAC One Node not only reduces the upfront license spending but also the ongoing support budget.
• Upgrade Costs: If you start with RAC One Node and later need to upgrade to full RAC (to support two active nodes for load or performance reasons), Oracle typically permits an upgrade by charging the list price difference. Essentially, you’d pay the delta to go from the RAC One Node option to the full RAC option on your processors/users. It’s wise to factor this potential future cost into your planning if your growth or uptime requirements might later demand a full RAC deployment.
• Contract Negotiation: Global enterprises often negotiate custom discounts. If RAC features are crucial, it might be possible to negotiate better pricing, especially if bundling licenses or during a larger Enterprise Agreement renewal. However, Oracle is known to charge a premium for high availability and performance options, so it is essential to justify the business value of RAC One Node in cost negotiations.

Use Cases and Deployment Scenarios

Oracle RAC One Node is best suited for scenarios where high availability is needed, but running multiple active database servers is unnecessary or too costly.

Some typical enterprise use cases and examples include:

• Moderate Workload Production Systems: For an ERP or CRM system that runs well on a single server but cannot afford downtime, RAC One Node provides a safety net. The database normally runs on Server A, and if Server A is taken down (due to planned maintenance or an unplanned outage), Oracle RAC One Node will start the database instance on Server B. The business experiences a brief failover interruption instead of a prolonged outage, all without incurring the cost of full RAC licensing on both servers.
• Data Center Maintenance & Patching: Enterprises can use RAC One Node to perform rolling maintenance. For example, before patching the OS or DB software on the primary node, an admin can relocate the database instance to the secondary node (Oracle provides a feature called “OMotion” for online migration in RAC One Node). Users continue working with minimal downtime during the switch. After maintenance, you can fail back to the original node. This allows patching or hardware upgrades with near-zero downtime, a crucial requirement in global operations, while using only one licensed node at a time.
• Cost-Constrained HA Environments: In some cases, a division or application needs high availability but has a limited budget. RAC One Node can be a stepping stone – it delivers higher availability at a fraction of the cost of full RAC. For instance, a manufacturing company might use RAC One Node for a plant floor database that must be up continuously. They license one node and designate another server as standby. Unless failovers become very frequent, they avoid the cost of licensing a second node.
• Testing Clusters and DR: Some enterprises use RAC One Node in non-production or testing environments to simulate failover scenarios without doubling the license count. Also, while Oracle’s licensing for disaster recovery (DR) sites typically requires licensing for any installed Oracle software, certain DR setups that only activate the database in an emergency could potentially leverage the 10-day rule similarly. (Be cautious: extended DR activations likely break the 10-day limit, so DR sites usually need full licensing if they might run production for more than 10 days).

In summary, any environment that demands reliability and quick recovery over raw horizontal scale is a candidate for RAC One Node.

It provides a balance between availability and cost: you get automatic failover for the database without paying for capacity that sits idle most of the time.

Common Pitfalls and Compliance Issues

Oracle licensing is notoriously complex, and RAC One Node introduces special conditions that IT asset management professionals must manage carefully.

Here are common pitfalls and compliance issues to avoid:

• Ignoring the 10-Day Rule: A major compliance risk is losing track of how many days the standby node was used. If you exceed the allowed 10 distinct days per year of running on the failover server and haven’t licensed it, you are out of compliance. Oracle auditors will check cluster logs and could back-charge for a full license (plus penalties). Avoid this by diligently logging every failover event, including date, duration, and reason.
• Unplanned Prolonged Failover: If a primary node failure results in a prolonged switch where the secondary node runs the database for an extended period (e.g., more than 10 days due to the primary being down for repairs), you must promptly address licensing. The safest approach is to contact Oracle or your reseller to discuss licensing the second node if it will exceed the grace period. Don’t assume you can run on the spare indefinitely without consequences.
• Enabling RAC One Node Without Proper Licensing: Sometimes, DBAs may mistakenly enable RAC features in an environment without realizing the licensing implications. For example, installing Oracle RAC (or RAC One Node) binaries on multiple servers and configuring a cluster, but only licensing one, hoping the second will not be counted. Keep in mind: if Oracle’s audit scripts detect RAC or RAC One Node option installed or in use on a server, they will expect it to be licensed unless it falls under the spare node policy. Only install Oracle on intended nodes, and if using a cluster, have documentation to show that one node is designated as a failover with limited usage.
• Mixing up RAC and RAC One Node Usage: Ensure that your technical teams understand the difference. RAC One Node means never running two instances concurrently for the same database. Suppose administrators or automated processes accidentally start the database on both nodes (even briefly, outside of a controlled failover scenario). In that case, you could inadvertently be using full RAC without a license for it. Such mistakes can occur during testing or due to misconfiguration. Controls should be in place to prevent running an active-active cluster when only RAC One Node is licensed.
• Metric Inconsistency: As mentioned, Oracle requires the option licensing to match the database license metric. A pitfall is forgetting this during procurement or environment changes. For instance, if you have an Unlimited License Agreement (ULA) or if you switch to a different database licensing model, you must ensure that the RAC One Node licenses are adjusted accordingly. It’s not allowed (or compliant-wise) to have, say, 100 NUP licenses of Oracle EE and then buy two Processor licenses for RAC One Node — that would be a mismatch and flagged in an audit. Always ensure that option licenses are updated in sync with the database.
• Assuming SE2 Covers EE Deployments: Standard Edition 2’s included failover (SEHA) doesn’t translate to Enterprise Edition environments. An enterprise might deploy some smaller instances on SE2 to leverage the free HA, but if the environment is EE (due to features or size), you cannot use SE2’s free cluster capability there. Each EE database that requires HA must have RAC One Node or RAC licenses. Trying to use SE2 in an EE scenario would violate license agreements.

Optimizing Oracle RAC One Node Licensing

To maximize the value of RAC One Node and minimize costs, enterprises should take a strategic approach:

• Plan Failovers Strategically: Use the allowed failover days wisely. Schedule planned maintenance in a staggered way to avoid unnecessary failovers. For example, if multiple maintenance activities are required, combine them into a single failover event whenever possible (apply all patches while the standby node is online, rather than failing over multiple times). The fewer days you run on the standby, the more cushion you have for unplanned outages within the 10-day rule.
• Leverage Named User Plus in Appropriate Environments: If you have a controlled user base (for instance, an internal application with 40 named users), NUP licensing for both the database and RAC One Node can be far more cost-effective than per-processor licensing. The cost scales with actual usage. Just ensure you still meet Oracle’s minimums (25 users per processor as a floor). For a small user count on a big server, processor licensing might ironically be cheaper due to those minimums. Always crunch the numbers for both metrics to determine which yields the most savings.
• Consider Downgrading Full RAC to One Node: Many enterprises purchased full RAC in the past for high availability but found that they rarely or never run the database on multiple nodes concurrently (essentially using it like One Node). If that’s the case, you might be over-licensed. During your next Oracle contract renewal or audit settlement, explore the possibility of converting some full RAC licenses to RAC One Node licenses. Oracle may allow a reduction or a swap (possibly with some credit or adjustments) since One Node is a lower-cost option. This must be done carefully through Oracle’s approval, but it can yield substantial cost savings on support and license fees if you truly don’t need active-active capability.
• Architect with Limits in Mind: When designing new database environments, decide upfront if RAC One Node meets requirements. If the business can live with one active database instance at a time and just needs quick failover, avoid over-engineering a full RAC cluster. By right-sizing the solution, you save on licensing and also reduce complexity. Conversely, be honest about uptime requirements; if an application truly cannot afford even a brief failover or requires load distribution, skipping full RAC could be more costly in terms of downtime. The key is aligning the tech solution with business needs and not paying for more redundancy than you’ll use.
• Stay Informed on Oracle Policies: Oracle occasionally updates its licensing rules or offers new programs (for example, cloud-specific policies or changes to failover rights). Always check the latest Oracle Partitioning and Failover policies if you’re using virtualization or cloud infrastructure with RAC One Node. Some cloud scenarios (like running Oracle on AWS or Azure) might require special attention since Oracle licensing in the cloud can treat failover instances differently (e.g., if you have instances stopped vs. running). Ensure any “standby” instances in cloud adhere to the spirit of the 10-day rule or Oracle’s cloud licensing terms, which may differ slightly from on-premises policies.

By optimizing how and when you use RAC One Node, you can achieve a balance between high availability and cost efficiency, extracting maximum value from this Oracle offering.

Recommendations (Expert Tips)

• Align License Metrics: Always use the same licensing metric (Processor or Named User Plus) for Oracle RAC One Node as your Oracle Database Enterprise Edition. This avoids compliance issues and simplifies tracking.
• Track Failover Usage: Implement a monitoring log or system to record every failover event and its duration. Keeping failover within Oracle’s 10-day limit on the standby node is crucial – proactive tracking prevents accidental overage.
• Designate One Failover Server: If you have a cluster, clearly designate a single server as the unlicensed failover target. Ensure that no additional nodes are configured to run the database unless they are fully licensed, to comply with Oracle’s one-spare-node policy.
• Plan for Exceeding HA Needs: If your environment may require running the database on two nodes simultaneously (for load balancing or continuous availability), plan to upgrade to full RAC licensing before it becomes necessary unexpectedly. Don’t wait for an audit to catch an unlicensed active node – budget and procure the needed licenses when scaling up.
• Leverage SE2 for Small Deployments: For smaller, non-mission-critical systems, consider using Oracle Standard Edition 2, which includes a free failover cluster feature. This can deliver high availability without extra licensing, as long as you stay within SE2’s limitations (e.g., hardware constraints).
• Regularly Review License Needs: Periodically evaluate your usage of RAC One Node to ensure optimal license utilization. If the failover node has been used very rarely (or conversely very often), reassess licensing. Rare use might mean you could explore other DR solutions; frequent use might mean it’s time for a second licensed node or a different HA strategy.
• Educate DBAs and Ops Teams: Ensure that your database administrators and operations staff understand the licensing constraints. Create internal guidelines so that, for example, they don’t run Oracle instances on two nodes at once under a One Node license or accidentally violate the failover duration limit. Awareness can prevent costly mistakes.
• Audit Readiness: Be prepared for Oracle audits by maintaining documentation, including architecture diagrams that label which node is primary and which is failover, records of any times the failover node was used, and proof of license purchases. Having these ready can make an audit go more smoothly and demonstrate your proactive compliance.
• Consult Oracle or Experts When in Doubt: If you are unsure about how a specific scenario is licensed (e.g., cluster setups in VMware or migrating workloads to the cloud), consult with Oracle licensing specialists or Oracle directly. Getting clarity in writing can save you from compliance surprises down the line.
• Optimize Support Contracts: If you reduce the number of licensed nodes (e.g., move from RAC to RAC One Node, or retire a cluster), don’t forget to adjust your Oracle support contract to reflect it. You should not be paying maintenance on licenses you no longer use. Work with Oracle to ensure your support renewal reflects the current deployed licenses for cost savings.

Checklist: 5 Actions to Take

1. Identify RAC One Node Deployments: Inventory all Oracle Database instances in your enterprise and flag those using (or planning to use) Oracle RAC One Node. Verify the number of nodes in each cluster and identify which node is designated as primary versus failover.
2. Verify Licensing Compliance: For each RAC One Node deployment, confirm that you have purchased the required licenses for the active node (processor or NUP licenses matching your EE count). Check that no license is mistakenly missing for any active database node.
3. Document Failover Policy: Establish an internal policy documenting Oracle’s 10-day failover rule. Set up a tracking mechanism (it could be as simple as a spreadsheet or as formal as an ITSM change management log) to record the date and duration of every failover event. Please communicate this to your operations team so they can log the use of the standby server.
4. Test Failover and Monitor Usage: Conduct a planned failover test for each RAC One Node cluster to ensure the process works and you know how to measure the time the secondary node is in operation. Use these drills to gauge how a failover reflects in your monitoring tools. After testing, verify that the usage was recorded properly in your log.
5. Review Contracts and Plan Next Steps: Review your Oracle licensing agreements or ordering documents, specifically looking for clauses related to clustering or failover. Ensure your understanding of the terms (such as the 10-day rule) aligns with what’s written. If you anticipate changes (such as adding more clusters or requiring a full RAC), initiate the conversation with procurement and Oracle representatives early. Have a plan for scaling up (license additional nodes) or scaling down (possibly dropping full RAC licenses) as your architecture evolves.

FAQ (Oracle RAC One Node Licensing)

Q1: How is Oracle RAC One Node different from full Oracle RAC in practice?
A1: Oracle RAC One Node allows only one active database instance in a cluster, providing high availability through failover to a secondary node if needed. Full Oracle RAC, on the other hand, allows multiple instances (on multiple servers) to be active simultaneously, sharing the workload. Essentially, RAC One Node is an active-passive setup (one active node, one standby node), whereas full RAC is active-active. This makes RAC One Node simpler and cheaper, but it won’t scale performance by adding more servers, unlike full RAC. It’s primarily for reliability, not horizontal scaling.

Q2: Do I need to license the standby server in a RAC One Node configuration?
A2: Not initially. You only license the primary node where the Oracle database runs. Oracle permits one designated standby/failover server to be set up without a license for Oracle RAC One Node, as long as it’s only used in failover situations. Thanks to the “10-day rule,” you can run the database on the secondary node for up to ten days per year without requiring a license. If you exceed ten days of failover usage in a year (cumulatively), you are required to purchase a license for that node. So, the standby is effectively free unless it’s heavily used, in which case it ceases to be “standby” in Oracle’s eyes and must be paid for.

Q3: Is Oracle RAC One Node included in any Oracle Database edition by default?
A3: Yes, it is included at no extra charge in Oracle Database Standard Edition 2 (SE2) (starting with Oracle 19c’s SE2 High Availability feature). In Enterprise Edition, however, Oracle RAC One Node is not included – it’s a separately licensed option. If you’re running Enterprise Edition, you must purchase RAC One Node licenses to utilize this feature. Only SE2 customers get a similar capability built-in, primarily because SE2 doesn’t allow full RAC at all. Always double-check your database edition; if it’s EE, budget for the RAC One Node option if you need that functionality.

Q4: How are Oracle RAC One Node licenses sold and calculated for an enterprise?
A4: They are sold in the same way as other Oracle database licenses, using either the Processor metric or the Named User Plus (NUP) metric. For Processor licenses, you count the number of processor cores on the active node (using Oracle’s core factor table to calculate the number of licenses if applicable) and buy that many licenses of the RAC One Node option. For NUP, you count all distinct users (or devices) that will access the database and ensure you have at least 25 NUP per processor (Oracle’s minimum). The cost is proportional to those counts – roughly $10k per processor or $200 per user at list price. Importantly, you must have the same quantity of RAC One Node licenses as you have for the underlying Database EE. For example, if you have 4 Processor licenses of Database EE on the server, you need 4 Processor licenses of RAC One Node for that server.

Q5: What happens if we want to add another node or make both nodes active?
A5: If you want to have more than one active database instance (for load balancing or additional failover nodes), you are essentially moving beyond the scope of RAC One Node. In that case, you would need to upgrade to full Oracle RAC licensing. Oracle typically would charge the difference in license fees to convert RAC One Node licenses into full RAC licenses for the processors/users in question. Once you have full RAC licensing, you must license every node in the cluster because any of them could be active at any time. Also note that if you add a third node as an additional failover target, Oracle’s rules allow only one unlicensed spare; a second spare node would generally need to be fully licensed or excluded from the cluster configuration. In short, any expansion of active capacity or additional failover nodes will require additional licensing beyond the single-node scope of RAC One Node.

Read more about our Oracle License Management Services.

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit