Short answer: Oracle dual use rights permit one passive failover node to run Oracle programs free for up to 10 separate days per calendar year, provided it shares a single storage cluster with the primary and only one node is active at a time. Every other standby, DR, or backup server with Oracle software installed and running must be fully licensed.
Oracle dual use rights are the narrow set of allowances in Oracle's licensing policies that let a second machine run Oracle programs without a separate license — primarily for failover and limited backup scenarios. The term covers two distinct ideas that buyers routinely confuse: the failover allowance (the "10-day rule") for clustered environments sharing storage, and the backup exception for cold, powered-off copies of Oracle binaries.
These rights are not written into your Oracle Master Agreement. They live in the Oracle "Software Investment Guide" and the partitioning and licensing policy documents that Oracle treats as contractually binding by reference. That distinction matters: Oracle can revise these policy documents at any time, and a generous reading from five years ago may no longer hold. When an Oracle License Management Services (LMS) auditor evaluates your disaster recovery estate, they apply the policy text exactly — not the relaxed interpretation your infrastructure team assumed when the architecture was designed.
The buyer-side reality is blunt: Oracle's failover and DR rules are written to keep the exemptions small and the licensable surface large. Most "free" DR nodes that companies believe they operate are, on inspection, fully licensable. Understanding where the real line sits is the difference between a clean audit and a seven-figure back-license claim. Our Oracle license optimization team rebuilds DR architectures specifically to stay inside the genuine exemptions.
The 10-day failover rule is Oracle's primary dual-use allowance. It permits a single unlicensed node in a clustered failover configuration to run Oracle programs for up to 10 separate 24-hour periods per calendar year when the primary node fails. It exists so that genuine high-availability clusters are not penalised every time a node fails over for a few hours.
The conditions are strict, and all of them must hold:
A "day" is the trap most teams miss. If the primary fails at 11pm and the failover node runs until 2am, Oracle counts that as one day used — or arguably two, spanning the calendar boundary. Worse, many teams periodically start the failover instance to test the cluster or run a validation. Each of those test events consumes a day from the same 10-day budget. A quarterly DR test plus two real failovers can quietly exhaust two-thirds of the allowance before any unplanned outage occurs.
Audit reality: Oracle LMS scripts capture the last startup time of every Oracle instance. An auditor can see that your "passive" failover node started six times last year — and ask you to prove each event stayed inside the 10-day rule. If you cannot, the node is treated as fully deployed and licensed for the entire period.
Our Oracle audit defense team reviews your cluster topology, storage configuration, and instance start logs to confirm what is genuinely exempt — before Oracle does it for you.
Yes. A standby database is a continuously maintained copy of the primary, kept in sync by Oracle Data Guard, and it has Oracle software installed and running. Under Oracle's Processor and Named User Plus definitions — "all processors where the Oracle programs are installed and/or running" — a standby is a licensable deployment, full stop. It does not matter that the standby never serves an end user in normal operation.
This catches teams who reason that "the standby is just for emergencies." Data Guard standbys are not idle: they receive and apply redo continuously, which is Oracle software running. The only configuration that escapes a separate license is a genuinely cold backup — a server where the Oracle binaries are installed but the instance is shut down, with the data restored only during an actual failover counted under the 10-day rule.
The licensing must also match the primary exactly. If the production database runs Enterprise Edition with Partitioning, Advanced Compression, and Diagnostics Pack, the standby must carry the identical edition and options on the same processor count. A frequent and costly error is licensing the standby for base Enterprise Edition while production runs three priced options — leaving the options unlicensed on the standby and exposed in an audit.
Yes. Active Data Guard is a separately priced Oracle Database Enterprise Edition option, distinct from the free Data Guard feature bundled with Enterprise Edition. Basic Data Guard lets you maintain a closed (mounted but not open) standby for free aside from the base license. The moment you open that standby read-only while it continues applying redo, you are using Active Data Guard — and it must be licensed on every processor of the standby.
Active Data Guard activates in ways that surprise administrators. Opening the standby read-only for reporting is the obvious trigger, but so are fast incremental backups taken on the standby (block change tracking on an open standby) and certain automatic block-repair features. These are convenient capabilities that DBAs enable to offload work from production — without realising each one converts a free standby into a licensable Active Data Guard deployment.
For a deeper breakdown of how this option is metered and where the hidden triggers sit, see our guide to Oracle Active Data Guard licensing. For the broader rules on database editions and options, the Oracle database licensing guide is the pillar reference.
There is no general disaster recovery exemption in Oracle licensing. Whether a DR server needs a license depends entirely on whether Oracle software is installed and running on it — not on how the business labels the server. The three classic DR postures map cleanly to three licensing outcomes.
A cold DR site keeps Oracle binaries installed but the instance shut down, with data restored only during an actual disaster. If it shares storage with the primary it can fall under the 10-day rule; if it is a remote site with its own storage, it is exempt only while the instance stays off and is licensed for any period it runs. A warm standby — instance up, applying redo, ready to open quickly — is a running deployment and must be fully licensed. A hot standby open for reads is both fully licensed and Active Data Guard licensed.
The most common audit trap is the geographically separate DR site that the team believed was covered by the 10-day rule. Because that rule requires shared single-cluster storage, a remote DR site on independent storage does not qualify — even if it sits idle 360 days a year. Across our engagements, this single misunderstanding is the most frequent driver of unexpected DR-related back-license claims (Oracle Licensing Experts engagement data, 2026). When DR exposure is uncovered mid-audit, our audit defense and Oracle negotiation teams work to reclassify and reprice it rather than accept Oracle's opening figure.
Use this matrix as a first-pass test of each node in your high-availability and DR estate. When a node falls into a "license required" row, it must carry the same edition and priced options as the primary.
| Configuration | Oracle software state | Shared storage? | License required? |
|---|---|---|---|
| Clustered failover node (10-day rule) | Passive; runs only on failure | Yes — single array | No, if ≤10 days/yr |
| Failover node exceeding 10 days | Runs >10 days/yr | Yes | Yes — full license |
| Cold backup / cold DR (remote) | Binaries installed, instance off | No | No, while powered off |
| Data Guard physical standby (mounted) | Running, applying redo | No | Yes — base EE |
| Active Data Guard (open read-only) | Open + applying redo | No | Yes — EE + ADG option |
| Warm standby DR | Instance up, ready | No | Yes — full license |
The 10-day rule is the only configuration above where a running-on-failure node stays unlicensed, and only when shared single-array storage and the once-active constraint both hold. If a vendor or internal architect tells you a remote DR node is "free under failover rights," ask to see the shared-storage condition satisfied. It almost never is.
We document every node, confirm what qualifies for dual-use rights, and quantify the exposure — then build the optimization or negotiation plan to remove it. See real outcomes in our case studies.
Oracle's 10-day failover rule lets a single unlicensed node in a clustered failover environment run Oracle programs for up to 10 separate days per calendar year when the primary fails. The node must share a single storage array with the primary, only one node can be active at a time, and the allowance does not accumulate or carry over between years.
Yes. A physical or logical standby maintained by Data Guard must be fully licensed for the same programs and options as the primary, because Oracle software is installed and running on it. Only a cold, powered-off backup with no running Oracle binaries avoids a separate license requirement.
Yes. Active Data Guard is a separately priced Enterprise Edition option. Opening a standby read-only while applying redo, or running fast incremental backups on the standby, activates Active Data Guard and requires the option licensed on every processor of the standby — on top of the base Database license.
No. There is no blanket disaster recovery exemption. A DR server with Oracle software installed must be licensed unless it qualifies as a cold backup under the 10-day failover rule or stays fully powered off with no running Oracle binaries. Warm and hot standby DR nodes require full licenses.
Only rarely. The 10-day rule requires the failover node to share a single storage cluster with the primary. Most geographically separate DR sites use independent storage and therefore do not qualify, so the remote DR node must be fully licensed even if it sits idle most of the year.
Backing up Oracle data files at the storage layer is fine. But starting the Oracle instance on the failover node to run RMAN, validate the database, or test failover consumes one of the 10 permitted days. Routine open-and-test cycles can silently exhaust the allowance and create audit exposure.
Oracle LMS measurement scripts capture instance startup history and alert log evidence. An auditor reconstructs every time the failover instance started during the audit period. If your records cannot show each event fell inside the 10-day allowance, Oracle treats the node as a full deployment licensed for the entire period.
Policy changes, audit tactics, and licensing benchmarks for Oracle stakeholders at 2,000+ enterprises globally. Corporate email required.