What is the Oracle 10 day rule for disaster recovery?
The Oracle 10 day rule lets a fully licensed Oracle node fail over to an unlicensed standby node for up to a total of 10 separate days in a calendar year, covering testing and a genuine outage. The allowance is measured in whole days, and any part of a day on which the standby runs Oracle counts as one of the ten. Once the limit is reached, or where the standby is used outside the terms of the allowance, that standby has to be fully licensed in its own right. The rule exists so that a buyer can prove and exercise a failover capability without paying twice for hardware that sits idle.
In the cloud the rule applies the same way, but the count is by vCPU and the standby is an instance rather than a server. A cold standby in another region that the buyer brings up briefly to test failover falls inside the allowance if the total stays within ten days. The discipline the rule demands is a simple one: keep a dated log of every day the standby runs Oracle, so that the ten day count is provable. Without that record, Oracle can assume the standby ran continuously and license it in full, which is where many disaster recovery findings come from.
Does a warm standby need an Oracle license?
A warm or active standby usually needs an Oracle license, because the 10 day rule covers a cold failover node only. The allowance is built for a standby that is dormant until a failover event, not for one that is mounted, open or applying changes on an ongoing basis. A standby that is continuously running Oracle, even if it carries no user traffic, sits outside the cold failover allowance and is licensable like any other live node. The distinction is the activity of the standby, not its label.
Active Data Guard makes this sharp. A standby that uses Active Data Guard to stay open for read access or to apply redo continuously is a live, licensable use of Oracle, and Active Data Guard is itself a separately licensed option on top of the database. A buyer who set up a standby for read offloading or near zero data loss has very likely moved outside the 10 day rule and into full licensing for both the standby and the option. The buyer move is to know which mode the standby runs in, because that mode decides whether the 10 day allowance applies at all.
| Standby mode | Oracle position | Buyer move |
|---|---|---|
| Cold standby, under 10 days | Inside the allowance | Log every failover day |
| Cold standby, over 10 days | Standby licensable | License or reduce days |
| Warm or mounted standby | Licensable | Confirm activity state |
| Active Data Guard standby | Standby plus option | License both knowingly |
What evidence supports a cloud DR position?
The evidence that supports a cloud disaster recovery position is a dated log of failover days and a clear record of the standby's configuration and activity state. The failover log proves the 10 day count, and the configuration record proves whether the standby was cold, warm or running Active Data Guard. In the cloud these facts are recoverable from instance state history, region replication settings and the database mode, so a careful buyer can reconstruct exactly what the standby did and when. That record is the difference between a provable allowance and an assumption that the standby ran all year.
This evidence matters because Oracle's collection scripts can read a standby as a fully active node, and preliminary findings arrive inflated at list price. A disaster recovery node that genuinely sat cold for all but a few days can be claimed as a second full deployment if no log contradicts it. The buyer move is to keep the failover log contemporaneously, capture the standby configuration, and have both ready before any script output is submitted, so the count reflects the real use rather than the worst case Oracle could assert.
How do you defend a cloud DR finding?
You defend a cloud disaster recovery finding by setting the failover evidence and the standby configuration against the contract, because the policy is not the agreement and the signed terms govern where they conflict. The first front is factual: the failover log and instance history show how many days the standby actually ran Oracle and in what mode, which rebuts an assumption of continuous use. The second front is the contract reading, which decides whether the disaster recovery terms Oracle relies on bind as claimed, since contract language beats policy.
This two front defense is where the largest reductions appear, because disaster recovery findings are often built on the maximum Oracle could assert rather than what happened. An independent line by line review of findings typically cuts claims by 60 to 80 percent, and a standby wrongly counted as a live node is a clean candidate for that scale of reduction once the evidence is in hand. If you have received a disaster recovery finding or are planning cloud failover and want the position settled before it becomes an exposure, a strategy call is the place to start.
The next step
This article is part of our Cloud and OCI Licensing cluster. Read the pillar, the Oracle virtualization licensing guide, for the full picture, and these related reads: Oracle licensing in the cloud, and the cloud evidence file for audits.