Oracle DR standby licensing is one of the most misunderstood areas of Oracle compliance — and one of the most profitable findings in an LMS audit. Many enterprises assume a disaster recovery or standby server is "free" because it only runs in an emergency. Oracle's actual rules are narrow: a single failover node is permitted up to 10 days a year under the 10-day rule, but the moment a standby database is mounted, open, or running Data Guard, it must be fully licensed exactly like production. Misreading the line between "passive DR" and "running standby" is how a single failover server turns into a seven-figure back-licence claim.
Short answer: Oracle DR standby licensing depends on whether the standby Oracle instance is running. A failover node may run unlicensed for up to 10 separate days per calendar year under Oracle's 10-day rule, but any standby that is mounted, open, or applying redo through Data Guard must be fully licensed — identically to the primary, across all its processors.
Oracle DR standby licensing follows one principle: if Oracle software is installed and running on a server, that server must be licensed — regardless of whether it is "primary," "standby," or "DR." There is no general disaster-recovery exemption in Oracle's contracts. The only relief Oracle grants is two narrow allowances: the 10-day failover rule for clustered single-node failover, and the fact that an offline server storing only backup files needs no license.
A standby is a secondary Oracle database that receives changes from a primary so it can take over if the primary fails. The licence question turns entirely on the standby's state. A standby database that is mounted or open and continuously applying redo is, in Oracle's view, a running Oracle instance — and must carry the same Database Enterprise Edition and option licences as the primary, counted by Processor across all its cores. A node that sits idle with Oracle installed but not running falls into a grey zone Oracle resolves aggressively in audits. For the underlying Processor and Core Factor mechanics, see our Oracle Database Licensing Guide.
Oracle's 10-day failover rule lets one unlicensed node in a clustered failover environment run the Oracle workload for up to a total of 10 separate calendar days per year without a separate licence. It is the single genuine DR concession in Oracle's licensing — and it is hedged with conditions that most enterprises unknowingly break.
The rule applies only when all of the following hold: the failover node and the primary are part of the same cluster and share one storage array (a single set of disks); only one node is actively running the Oracle program at any time; and the failover is temporary, with the workload returning to the primary once it is repaired. Any part of a calendar day on which the failover node runs the workload counts as one full day, and the 10 days are cumulative across the year — not per incident.
DR testing burns your 10 days. Oracle counts planned DR tests against the 10-day allowance. An organisation running a monthly failover test uses up to 12 days on testing alone — exceeding the limit before a single real disaster — and a standby running on day 11 must be fully licensed for the entire year. Across our engagements, exhausting the 10-day rule through routine DR testing is among the three most common standby compliance gaps we find (Oracle Licensing Experts, 2026).
Critically, the 10-day rule applies to failover — a clustered configuration where the standby is normally idle — not to Data Guard, where the standby is continuously running. Conflating the two is the most expensive mistake in DR licensing.
Yes. An Oracle Data Guard physical or logical standby must be licensed identically to the primary. Oracle Data Guard is the Enterprise Edition feature that ships redo from a primary database to one or more standby databases and applies it to keep them synchronised. Because the standby is mounted or open and continuously applying that redo, it is a running Oracle instance — and the 10-day failover rule does not apply to it.
The common misconception is that "Data Guard is included with Enterprise Edition, so the standby is free." Both halves are half-true and dangerously combined. Data Guard the feature is indeed included in Database EE at no additional licence cost. But the standby server still requires full Database EE licences across its processors, plus matching licences for every option in use on the primary — Partitioning, Advanced Security, Diagnostics Pack, Tuning Pack, and so on. A two-node Data Guard pair is, for licensing purposes, two fully licensed databases.
This is why DR architecture decisions are licensing decisions. The choice between a continuously-running Data Guard standby and an idle clustered failover node can double or halve the licence count for the same recovery objective. Our Oracle License Optimization team models both against your recovery time and recovery point objectives before you commit.
We map every standby, failover node, and backup server, classify each by running state, and quantify the gap between what you've licensed and what Oracle would claim. Engage our Oracle Audit Defense team before any LMS data leaves your environment.
Yes. Active Data Guard is a separately licensed Oracle Database option, priced per Processor or Named User Plus on top of Enterprise Edition. Active Data Guard extends basic Data Guard by allowing the standby to be open read-only while it applies redo, enabling real-time reporting queries against the standby. Basic Data Guard keeps the standby mounted (not open for queries) and does not require the extra option.
Active Data Guard is required, and must be licensed on the standby, whenever you use: real-time query (open read-only standby with active redo apply), automatic block media repair, far sync instances, or fast incremental backups offloaded to the standby. Oracle's LMS scripts specifically detect Active Data Guard usage because customers frequently enable real-time query for reporting convenience without realising it converts a "free" standby feature into a licensable option across every standby processor.
| Configuration | Standby state | 10-day rule? | Licence required |
|---|---|---|---|
| Clustered single-node failover | Idle until failover | Yes (≤10 days/yr) | None if within 10 days |
| Data Guard (basic) | Mounted, applying redo | No | Full Database EE + options |
| Active Data Guard | Open read-only + apply | No | EE + options + Active Data Guard |
| Cold DR, software installed | Installed, not running | No | Full licence (Oracle's position) |
| Backup-only server | No Oracle binaries | N/A | None |
A cold or passive DR server — one where Oracle is installed but not running until a disaster — is, in Oracle's position, fully licensable. Oracle's licensing rules attach to software that is "installed and/or running," and Oracle's auditors treat the mere installation of Oracle binaries on a powered standby as creating a licence obligation, even if the database is shut down.
There is one genuine exception and one practical mitigation. The exception is the 10-day failover rule, which covers a clustered cold node that activates ≤10 days per year. The mitigation is to keep Oracle binaries entirely off the DR server until they are needed — storing only RMAN backup files — so that no Oracle software is installed in the steady state. The trade-off is recovery time: installing and restoring from cold adds hours to your recovery objective. This is a deliberate cost-versus-RTO decision, and it is exactly the kind of architecture choice Oracle's contract language penalises if made carelessly. Our analysis of application-tier DR rules in Oracle EBS Disaster Recovery Licensing covers the same logic for E-Business Suite.
A server that stores only RMAN backup files, with no Oracle Database software installed or running, does not need a licence. The moment Oracle binaries are installed to perform a restore, validate a backup, or run the database for recovery testing, that server must be licensed — unless the activity falls within the clustered 10-day failover allowance.
This catches two common practices. First, "DR rehearsal" servers where teams periodically restore and open the database to verify recoverability: each open is a running instance and consumes the 10-day allowance (or requires a full licence outside a clustered failover setup). Second, RMAN backups that are restored and validated on a dedicated catalog or test box with Oracle installed — that box is licensable. Storing the backup is free; running Oracle to use it is not. The distinction Oracle enforces is binary: Oracle software present and runnable equals a licence requirement.
You contain Oracle DR exposure by matching the DR architecture to the cheapest licensing model that still meets your recovery objective, and by documenting the running state of every secondary server as audit evidence. The following steps, applied together, form a defensible DR licensing position.
For DR that spans clouds — where authorized-cloud per-vCPU rules change the math — see Oracle DR Licensing Across Multiple Clouds and the Oracle Cloud Licensing Guide.
Oracle's LMS team looks for running Oracle instances on any server you have not licensed — and standby and DR servers are their first target, because customers so often assume these are free. Oracle's audit scripts collect the database open mode, instance status, Data Guard configuration, Active Data Guard feature usage, and the number of days each instance has been up, precisely to test your DR licensing position against the 10-day rule and the running-state principle.
Specifically, Oracle reviews: v$database open mode and v$instance status on every server (to prove the standby is mounted or open), Data Guard broker and configuration views, the DBA feature-usage statistics that record Active Data Guard real-time query and block-repair usage, and instance uptime to challenge any claim that a "passive" server only ran within 10 days. Feature-usage history is the most damaging artifact — it records that Active Data Guard was used months ago even if it is disabled today.
The single most consequential mistake is letting Oracle's scripts run against your DR environment unsupervised, then submitting raw output. That output defines the scope of Oracle's claim. Before responding to any DR-related data request, engage Oracle Audit Defense. In one virtualised engagement we reduced an Oracle audit claim from $22M to $1.8M through evidence-based technical challenge of exactly this kind of state-and-usage counting — see the Healthcare Compliance Remediation case study. The same discipline applies when the disputed servers are standbys.
It depends on whether the DR server is running Oracle and how often it is activated. A standby where the Oracle instance is mounted or open must be fully licensed. A cold failover node may qualify for Oracle's 10-day failover rule and avoid a separate license, but only if it shares storage with the primary, runs the failover for no more than 10 separate days per calendar year, and only one node is active at a time.
Oracle's 10-day failover rule lets an unlicensed node in a clustered failover environment run the Oracle workload for up to a total of 10 separate calendar days per year without a separate license. The nodes must be part of the same cluster sharing one disk array, only one node may be active at a time, and once the primary is repaired the workload must fail back. Day 11 requires the failover node to be fully licensed.
Yes. A Data Guard physical or logical standby must be licensed identically to the primary, because the standby database is mounted or open and continuously applying redo. Data Guard itself is included with Oracle Database Enterprise Edition at no extra license cost, but the standby server still needs full Database EE and matching option licenses across its processors.
Yes. Active Data Guard is a separately licensed Oracle Database option, priced per Processor or Named User Plus on top of Enterprise Edition. It is required whenever the standby is open read-only while applying redo (real-time query), used for automatic block repair, or used for fast incremental backups offloaded to the standby. Basic Data Guard redo transport and apply with a mounted standby does not require it.
A server that only stores RMAN backup files, with no Oracle Database software installed or running, does not need a license. The moment Oracle binaries are installed to perform a restore or to run the database for recovery testing, that server must be licensed unless the activity falls within the 10-day failover rule. Storing backups is free; running Oracle to use them is not.
Yes. Oracle counts DR testing days toward the 10-day failover allowance. A full day or any part of a day on which the failover node runs the production workload, including planned DR tests, counts as one of the 10 days. Organizations that run monthly DR tests can exhaust the allowance through testing alone and trigger a full license requirement for the standby.
Complete framework for licensing Oracle failover, Data Guard, Active Data Guard, RAC, and backup environments — including the 10-day rule evidence requirements, audit challenge methodology, and RTO-versus-licence cost models. Download free.
Download Free Guide →Stay ahead of Oracle's standby and DR audit program. Weekly intelligence on compliance risk, the 10-day rule, and licence optimization from former Oracle insiders now working for enterprise buyers.
Oracle Licensing Experts Team — Former Oracle licensing executives, LMS auditors, and contract managers, now working exclusively for enterprise buyers. Not affiliated with Oracle Corporation. About our team →