Oracle's failover and disaster-recovery rules are governed by short, specific language in the licensing documentation — and misreading them is a frequent source of audit findings. The headline rule most buyers have heard is the "10-day rule," but it is narrower than its reputation suggests, and it does not cover standby databases, Data Guard, or most modern DR designs. Getting DR licensing right is a core part of Oracle audit defence because DR servers are exactly where unlicensed-but-installed Oracle binaries tend to accumulate.
What the 10-day rule actually covers
Oracle's policy permits, under defined conditions, the use of an unlicensed spare server in a clustered failover environment for up to a limited number of separate days per calendar year, where the failover node uses shared storage with the primary and only one node is active at a time. The widely cited figure is ten separate 24-hour periods per year. The allowance is designed for true active-passive cluster failover (for example, a node taking over within a shared-storage cluster), not for a continuously running standby copy.
Three conditions are routinely missed. First, the rule applies to a cluster sharing one disk array — not to two independent servers replicating data. Second, the clock counts any portion of a day as a full day. Third, once the failover node exceeds the allowance, or if the primary is not repaired and returned to service, the failover node must be fully licensed.
Standby, Data Guard and replicated DR are different
This is the single most important distinction for buyers. The 10-day allowance does not apply to a physical or logical standby database, because a standby is mounted, recovering, and — in Oracle's view — installed and/or running. A Data Guard standby that is open read-only, or that applies redo continuously, generally must be fully licensed, at the same edition and with the same options and packs as the primary. If the primary uses Partitioning, Advanced Compression, or Diagnostics and Tuning packs, the standby needs them too.
| DR architecture | Typical licence treatment | Common trap |
|---|---|---|
| Active-passive cluster (shared storage) | 10-day rule may allow unlicensed passive node | Exceeding 10 days; counting partial days as zero |
| Data Guard physical standby | Fully licensed, matching edition + options | Assuming the 10-day rule applies |
| Active Data Guard (open read-only) | Fully licensed + Active Data Guard option | Missing the separately licensed ADG option |
| Backup-only / cold restore | Backup copy may be unlicensed if never opened | Opening the DB to "test" it triggers licensing |
| Remote mirror (storage replication) | Target licensed once Oracle is installed/run | Treating storage replication as "just backups" |
Backups and "testing" the DR site
A genuinely cold backup — Oracle binaries not installed, or installed but never started — can sit unlicensed. The exposure appears the moment someone opens the database to verify the DR site works. A single DR test that opens the standby instance can, on Oracle's reading, convert an unlicensed copy into a licensable one. Buyers should treat DR test procedures as a licensing event and document exactly what was opened, for how long, and under which allowance.
Buyer takeaway: Most DR audit findings come from two assumptions — that the 10-day rule covers standby databases (it does not) and that a standby can run a cheaper edition or fewer options than the primary (it cannot). Map every DR node to a specific contractual allowance before the auditor does. Our Oracle audit defence team reconstructs DR licensing position as a standard first step.
Designing DR to minimise licence cost
The cheapest defensible DR design depends on recovery objectives. Where an organisation can tolerate a cold restore, an unopened backup avoids licensing entirely. Where near-zero data loss is required, a fully licensed Data Guard standby is the honest cost of that requirement and should be budgeted as such — not discovered in an audit. The expensive mistakes happen in between, where a "standby just in case" quietly runs licensable Oracle that nobody recorded.
Related: VMware soft-partitioning risk and reading LMS script output. Anchor: Oracle audit defence.
How DR findings appear in an audit
Disaster-recovery exposure rarely announces itself. It accumulates quietly: a standby built "temporarily" during a migration and never decommissioned, a DR test that opened a database and was never accounted for, or a replicated target that the storage team considers "just a mirror." In an audit, the LMS data collection picks up Oracle installed and run on those nodes, and the finding lands as though the capacity had always been licensable. The defensible response is to map every node that has ever had Oracle installed to a specific contractual basis — a purchased licence, the 10-day failover allowance, or a genuinely cold backup that was never opened — and to retire anything that fits none of those categories before it becomes a number in a claim.
Common questions
Can a Data Guard standby run Standard Edition to save money if the primary is Enterprise Edition?
No. A standby must match the primary's edition and carry the same separately-licensed options and management packs that the primary uses. Mixing editions across a Data Guard pair is a frequent and costly misconfiguration.
Does the 10-day rule reset every year?
The allowance is measured per calendar year, and any portion of a day counts as a full day. It applies only to true shared-storage cluster failover, not to standby replication, and it does not cover routine DR testing that opens the database.