What is the Oracle 10 day failover rule?
The 10 day rule lets a single unlicensed node in a cluster take over for a failed licensed node for up to 10 separate days in a calendar year without needing its own license. The node must be a genuine failover, sitting in the same cluster and sharing storage with the production node it covers, and it must take over only when production fails. Each calendar day on which the failover node runs Oracle counts as one of the ten, regardless of how many minutes within that day were used, and the count resets each calendar year.
The boundaries are strict, and they are where exposure lives. The allowance covers exactly one failover node, not several. It covers failover only, so if the node does any other work, such as reporting, batch, or test, the allowance does not apply and the node must be licensed. And it is capped at ten days, so a long outage that runs the failover node for an eleventh day takes the whole node outside the allowance. Treating the rule as a general permission to run a warm spare is the mistake that produces a finding.
The 10 day rule is narrow. One failover node, same cluster, shared storage, failover use only, capped at 10 separate calendar days a year. Step outside any one of those and the node needs a full license.
When does a standby need to be licensed?
A standby database needs a full license whenever it is open for reads or actively applies redo, because that makes it a running Oracle environment rather than a dormant copy. Data Guard in its various modes draws the line here. A physical standby that simply receives redo and holds it can sit differently from one that is open read only for reporting or that runs in an active apply mode, and the open or active configurations are generally licensable the same as production. The feature that makes a standby readable while it applies redo is itself a licensable option in many configurations, so the standby can carry both a base license requirement and an option requirement.
The treatment is contract dependent, and that phrase is doing real work here. Your agreement, not the policy paper, defines what counts as installed and running, and the definitions can be narrower or broader than the marketing description of a feature. Before you accept that a standby is licensable, or concede that it is not, the controlling text is the signed contract read against what the standby is actually configured to do.
Does the 10 day rule cover a disaster recovery site?
The 10 day rule does not automatically cover a separate disaster recovery site, because the allowance is written for a failover node in the same cluster sharing storage, not for a remote standby in another location. A remote disaster recovery environment is usually a distinct installation that needs its own licenses, unless your contract grants specific standby or disaster recovery rights. This is one of the disaster recovery mistakes that quietly builds exposure: an organisation assumes the ten day allowance stretches across the estate, when in fact it is tied to a specific cluster topology. For the detail, read disaster recovery licensing and the 10 day rule.
Where do standby findings go wrong?
Standby findings go wrong when an auditor treats every non production copy as production, or every cluster node as a fully licensed node, without testing what each environment is actually doing. The preliminary report arrives inflated at list price, and standby is fertile ground for inflation because the configurations are subtle. A dormant standby may be counted as if it were open. A genuine failover node within its ten days may be counted as a permanent installation. A reporting standby may be assigned a base license but not credited against the option you already hold. Each of these is a measurement dispute, and measurement disputes are exactly what independent line by line review resolves, which is why such review typically cuts a claim 60 to 80 percent.
What is the buyer move?
The buyer move is to map every standby and failover node to what it actually does, then license only what the contract requires for that real configuration. Document which node is the single failover, prove it shares storage and serves failover only, and keep a clean record of any days it ran so the ten day count is defensible. Separate the dormant standbys from the open or active ones, and read your agreement on what each owes. Where a finding assumes the worst about a standby, answer it with configuration evidence and contract language. For the surrounding mechanics, read Real Application Clusters licensing and the core factor table explained, then work up to the Oracle database licensing guide.
FAQ
What is the Oracle 10 day failover rule? It lets one unlicensed cluster node take over for a failed licensed node for up to 10 separate days a year. Beyond that, or for any other use, the node must be licensed.
Does a Data Guard standby need a license? Usually yes. A standby that is open for reads or actively applies redo is a running environment and is generally licensed like production. The exact treatment is contract dependent.
Does the 10 day rule cover disaster recovery sites? Not by default. It applies to a failover node in the same cluster sharing storage, not a remote site. A remote standby usually needs its own licenses unless your contract says otherwise.