The 10-Day Failover Rule
Oracle DR licensing hinges on a single, frequently misread provision: the 10-day failover rule. It permits you to run Oracle Database on an unlicensed spare node for up to 10 separate calendar days in a given year — but only under tight conditions. The primary and the spare must sit in a physical or logical cluster sharing a single logical disk array in one data centre, and the primary production server must be down when the spare is activated.
Two details catch teams out. First, Oracle counts calendar days in aggregate, not hours: even 15 minutes of activation consumes a whole day, and two separate five-day outages exhaust the entire annual allowance. Second, if a disaster takes the primary out for three days, you have only seven failover days left for the rest of that year. The rule is a narrow concession, not a general DR licence — a point the advanced Oracle licensing guide places alongside the other capacity-based traps Oracle uses to expand a licence requirement.
When the Rule Does Not Apply
The bigger risk is that most enterprise DR designs fall outside the 10-day rule entirely. The concession is voided in four common configurations.
| DR configuration | 10-day rule? | Licensing consequence |
|---|---|---|
| Standby in a different data centre | No | Standby requires full licensing |
| Cloud DR node, on-premises primary | No | Cloud node licensed under cloud rules |
| Active Data Guard (open read-only) | No | Standby fully licensed + ADG option |
| Standby used for reporting or test | No | Standby fully licensed as production |
The cross-site case is the one that surprises most enterprises, because geographic separation is exactly what good DR design demands — yet it removes the very concession that made the standby look free. A cloud DR node paired with an on-premises primary is licensed under the relevant cloud counting rules instead, which is why DR planning and the Oracle on AWS BYOL rules have to be considered together rather than in isolation.
Backup and test environments tucked into the DR estate carry their own exposure. A standby periodically opened to validate recovery procedures, or cloned to provide a test copy, is no longer a passive failover target — that activity is a licensable use in its own right, distinct from the 10-day failover allowance. RMAN backup servers and snapshot copies that mount Oracle data follow the same logic. The safe assumption is that any Oracle instance that runs for a purpose other than waiting to take over from a downed primary needs to be licensed, and the burden of proving the exception sits with you, not Oracle.
Data Guard vs Active Data Guard
The mechanism that keeps a standby in sync is Oracle Data Guard, which ships and applies redo logs to a physical or logical standby. Data Guard is included with Oracle Database Enterprise Edition at no additional cost — a genuinely free capability. The cost arrives with its more capable sibling.
Active Data Guard opens the standby read-only so it can serve queries, reporting and offload workloads while still applying redo. It is a separately licensed option, and because the standby is now actively running, the standby itself must also be fully licensed. The distinction is where most DR cost surprises originate: a team enables read-only reporting on the standby to relieve the primary, not realising it has just converted a free Data Guard standby into a fully licensable Active Data Guard environment. The full mechanics are covered in our dedicated guide to Oracle Data Guard licensing.
The most common DR finding in an Oracle audit is a standby that has quietly drifted from passive recovery into active reporting use. The configuration the business runs has outgrown the configuration it licensed — and Oracle's auditors look for exactly that gap.
Warm, Cold and the Cost of Getting It Wrong
The passive end of the spectrum still carries nuance. A warm standby — continuously synchronised and running in recovery mode — is treated by Oracle as a running environment and typically requires a full licence, even with no users connected, because the software is installed and operating continuously. A genuinely cold standby — installed but only started during a disaster — generally needs no licence until it is activated, at which point the 10-day rule governs how long it can run.
Getting the classification wrong is expensive. Exceeding the 10-day allowance, or running primary and standby concurrently, voids the exemption and triggers full licensing of the standby — potentially with backdated fees stretching across the period of non-compliance. The remedy is documentary discipline: log every failover day, define each standby's mode explicitly, and reconcile the running architecture against the licensed architecture before an auditor does it for you. That reconciliation often surfaces standby entitlement that can be harvested or redeployed, and it is a standard part of the trigger-aware review described in how often Oracle audits and why.
There is also a design choice worth making deliberately rather than by accident. If your DR requirements genuinely need read-only reporting or near-zero recovery time, licence Active Data Guard openly and size for it — trying to get the capability while avoiding the licence is the fastest route to a backdated claim. If, on the other hand, the standby only ever needs to wait passively for a true disaster, hold it as a genuinely cold node and protect the 10-day concession by keeping it powered down outside real failover events. The expensive mistakes happen in the middle, where a node drifts from one intent to the other without anyone re-checking the licence position.
For the full methodology, the Oracle Negotiation Playbook documents the DR-licensing and audit-defence framework, and the Oracle vendor intelligence hub tracks the policy detail. If you are designing, migrating or defending a DR estate, request a confidential briefing before the architecture is locked in — DR is where good engineering and Oracle's licence rules most often pull in opposite directions.