Oracle 10-Day Rule for Failover Licensing: What It Covers, What It Doesn't

What Is Oracle's 10-Day Failover Rule?

Oracle's 10-day rule is a specific licence provision documented in Oracle's Data Recovery Licensing policy. It permits an organisation to run Oracle software on an unlicensed spare computer in a failover or disaster recovery environment for up to a total of ten separate 24-hour periods within any given calendar year, without the need to purchase a separate licence for that spare computer.

The policy applies when multiple physical or logical machines are arranged in a cluster and share one logical disk array located within a single data centre. The intent is to allow a modest amount of failover operation — covering short outages and maintenance windows — without requiring organisations to fully licence every passive node in a clustered environment.

The 10-day rule is a meaningful operational allowance for organisations with infrequent, short-duration failover events. It is wholly inadequate as a disaster recovery strategy for organisations with complex DR requirements, geographically distributed environments, or a history of extended outages. Understanding what the rule covers — and what it explicitly does not cover — is essential for any Oracle customer with a disaster recovery infrastructure.

The Four Conditions That Must Be Met

Oracle's 10-day rule is not a blanket allowance. It applies only when four specific conditions are satisfied simultaneously. Missing any one condition means the failover node requires a full licence from day one of operation.

Condition 1: Clustered Configuration

The primary and failover computers must be arranged in a cluster. This means they must share a single logical disk array and be configured for high-availability failover. Standalone servers with replicated data, active-passive configurations using storage replication alone, or geographically separated DR sites connected by data replication do not qualify as clustered environments under Oracle's standard policy definition.

Many organisations operate DR environments that they believe qualify as clusters but that Oracle's technical definition does not cover. A stretched cluster configuration across two data centres connected by synchronous replication may or may not qualify depending on how Oracle's definition of "single logical disk array" is interpreted in the specific contract. Any ambiguity should be resolved in writing with Oracle before a DR event occurs — not after.

Condition 2: Single Data Centre

The cluster must be located within a single data centre. Geographically separated DR sites — a primary data centre in New York with a DR site in Chicago, for example — do not qualify for the 10-day rule even if the DR site is configured as a cluster replica of the primary. Oracle's policy is explicit: the clustered configuration must be within one physical data centre facility.

This condition eliminates the 10-day rule as a coverage mechanism for the majority of enterprise DR architectures, which typically involve geographically separated primary and recovery sites specifically to protect against data centre-level failures. A disaster scenario that takes down the primary data centre — the scenario most DR environments are designed for — takes the primary and failover nodes offline simultaneously if they are co-located, making the geographic separation requirement the decisive point for most real-world DR planning.

Condition 3: One Unlicensed Failover Node

The 10-day allowance applies to a maximum of one unlicensed spare computer per cluster. Organisations with multi-node clusters — where two, three, or more nodes may fail over to spare capacity — can apply the 10-day rule to only one of those spare nodes. Any additional spare capacity requires full licensing from day one of operation.

This condition is frequently overlooked in Oracle RAC (Real Application Clusters) environments where multiple nodes share workload. In a four-node RAC cluster, if the organisation intends to have one spare node available for failover, the 10-day rule covers that one node. The other nodes — whether primary or secondary — all require full licensing.

Condition 4: Same Licence Metric

The failover node must use the same licence metric as the production environment. If the production database is licensed by processor, the failover node — when it becomes active — must be licensable on the same processor metric. If the production environment uses Named User Plus licensing, the failover node must also be capable of operating under the NUP metric. You cannot change the licensing metric to reduce the failover licence cost.

How Oracle Counts the 10 Days

The counting mechanics for the 10-day limit are significantly more restrictive than most organisations assume. Three specific aspects of Oracle's day-counting methodology consistently surprise enterprises when they review their actual failover log against the 10-day limit.

Partial Days Count as Full Days

Oracle counts each separate activation of the failover node as one full 24-hour period, regardless of how long the failover node actually runs on that day. If the failover node is activated for a two-hour maintenance window on a Tuesday, Oracle counts that as one day. A five-minute test of the failover procedure also counts as one day. The duration of each activation is irrelevant — only the number of separate activation events across the calendar year matters.

This counting rule has significant practical implications. Organisations that test their failover procedures regularly — which is operationally sound practice — consume 10-day allowances with each test. An organisation that conducts quarterly DR tests (four activations per year), performs three planned maintenance failovers per year, and experiences two unplanned outages has consumed all ten days by the seventh event, even if the total active time on the failover node is only a few hours across all events.

Days Are Not Required to Be Consecutive

The ten days do not need to be consecutive. Oracle counts each separate activation across the full calendar year. This means a series of brief, non-consecutive activations across January through November can exhaust the annual allowance just as completely as ten consecutive days of continuous failover operation in a single incident.

The Reset Is January 1

The 10-day allowance resets at the start of each calendar year — January 1 — not at the organisation's Oracle contract anniversary date. An organisation that exhausts its 10-day allowance in October is non-compliant for any further failover activation in November and December, even if the contract anniversary and associated support renewal is in August. The calendar year is the controlling period, regardless of contract timing.

What Happens When the Limit Is Exceeded

When a failover node has been activated for more than ten days in a calendar year, Oracle requires full licensing for that node. The licence requirement is retroactive — Oracle's standard position is that the node should have been licenced from the point at which the tenth day was exceeded, not only from the point at which the organisation became aware of the exceedance.

In practice, this means an organisation that exceeds the 10-day limit due to an extended outage faces a licence obligation for the entire period the unlicensed node was active beyond the tenth day, plus ongoing support at 22% per year — increasing at 8% annually — on the licence value. If the failover node has the same processor count as the production environment and Oracle Database Enterprise Edition is the product in use, the retroactive licence cost can easily reach six figures for an extended outage.

Oracle's audit scripts track system uptime and activation history. The information needed to establish 10-day rule exceedance is routinely collected during Oracle LMS audits and is difficult for the audited organisation to dispute without comprehensive operational logs of its own.

Maintenance Downtime and the 10-Day Rule

A point of frequent confusion is whether planned maintenance downtime — where workloads are deliberately failed over to allow maintenance work on the primary node — counts toward the 10-day limit. Oracle's policy explicitly states that downtime for maintenance purposes does count toward the ten separate 24-hour periods limitation.

This is a significant operational constraint. Many organisations fail over to the DR node for planned maintenance more frequently than they experience unplanned outages. OS patching, hardware maintenance, firmware upgrades, and application maintenance windows all involve deliberate failover events. Each one consumes a day from the annual 10-day allowance, leaving fewer days available for genuine disaster recovery events.

Organisations that use the failover node for planned maintenance multiple times per year should conduct a day-count analysis at the start of each year to determine how many of the ten days are likely to be consumed by planned maintenance before any unplanned outage occurs. If the planned maintenance calendar alone would exhaust most of the 10-day allowance, the failover node should be licenced.

Structuring DR Environments for Oracle Compliance

Given the limitations of the 10-day rule, many enterprise Oracle customers require a more comprehensive DR licensing strategy. The options available depend on the product, deployment model, and recovery time objective requirements.

Full Licensing of the DR Node

The most straightforward approach is to fully licence the DR node using the same metric and quantity as the production environment. Full licensing eliminates all 10-day rule counting concerns, permits any number of failover activations for any duration, and removes the restriction to a single data centre. The cost is a second full licence position — processor or named user plus — for every product running on the DR node.

Oracle Data Guard (Passive Standby)

Oracle Data Guard in physical standby mode — where the standby database remains in mount state and is not open for read-only access — does not require separate Oracle Database licence entitlement for the standby node, provided the standby is used only for failover purposes and not for any user or application access. This is the most cost-effective DR option for Oracle Database customers who need continuous data protection without incurring a second full database licence.

The critical compliance requirement is that the standby must remain in mount state. The moment it is opened for read-only queries — even for a single DBA checking replication health — the organisation is using Active Data Guard, which requires a separately licensed Oracle option. Oracle's audit scripts detect the database open mode and will flag read-only access on a standby as unlicensed ADG usage regardless of whether the access was intentional.

Oracle OCS (Oracle Cloud Services) for DR

Oracle Cloud Services offers DR as a managed service, allowing on-premises Oracle environments to replicate to Oracle Cloud Infrastructure with Oracle-managed failover. Under an OCS arrangement, the cloud DR environment is covered by the service agreement rather than requiring separate perpetual licence entitlement. For organisations with OCI relationships, this approach can provide comprehensive DR coverage without the complexity of managing a second licence position on-premises.

Common Mistakes and How to Avoid Them

Assuming DR sites qualify as single data centre clusters: Geographic DR separation is the most common reason the 10-day rule does not apply. Verify that your DR configuration meets Oracle's single data centre requirement before relying on the 10-day allowance.

Not tracking failover activations across the year: The 10-day limit is a cumulative annual count. Without a log of every failover activation — including duration and date — organisations cannot determine their current position relative to the limit. Implement operational logging of every DR activation from January 1.

Consuming days on planned maintenance without accounting for unplanned events: Planned maintenance failovers count toward the 10-day limit. If your maintenance calendar will consume eight or nine days, there are effectively no days remaining for a genuine DR event.

Running more than one unlicensed failover node: In multi-node environments, only one spare node qualifies for the 10-day allowance. Additional spare nodes require full licensing.

Opening the Data Guard standby for read access: The transition from passive Data Guard (no licence required) to Active Data Guard (separate paid option required) happens the moment the standby is opened for read-only access while redo is being applied. Many DBAs do this without realising the licensing consequence.