Oracle's ten-day failover allowance almost never covers a paired ODA running Data Guard, which means most DR standbys need real licenses on real cores. This page shows exactly where the rule breaks, how much the standby costs at list, and how Capacity-on-Demand core activation gets you defensible DR at a fraction of primary-site licensing.
Oracle's ten-day failover allowance almost never covers a paired ODA running Data Guard, which means most DR standbys need real licenses on real cores. This page shows exactly where the rule breaks, how much the standby costs at list, and how Capacity-on-Demand core activation gets you defensible DR at a fraction of primary-site licensing.
Every ODA DR conversation I have sat in for the last two decades opens the same way: someone on the infrastructure side says "we are covered by the ten-day rule," and nobody has read the two sentences that decide the question. Oracle's Licensing Data Recovery Environments policy grants the right to run licensed programs on an unlicensed spare computer for up to a total of ten separate 24-hour periods in any given calendar year, but only where the machines are "arranged in a cluster and share one logical disk array located in a single data center." Those two conditions, single data center and one shared logical disk array, are not decoration. They are the entire scope of the allowance, and a paired ODA running Data Guard fails both by design. If your standby sits in a second site with redo shipped over a WAN, there is no shared disk array and there is no single data center. The architecture that makes the DR investment worth funding is the same architecture that disqualifies it from the free failover right.
The second clause is worse, because it applies even to customers who somehow keep both appliances in one room. Oracle's position is that any server where the software is installed and/or running must be licensed. A physical standby in mount state with redo apply running is, on Oracle's reading, installed and running. The allowance is written for a cold spare that sits idle until the primary dies. A recovering standby is never idle, so the ten-day clock never starts, and there is nothing to count down from. This is not an aggressive LMS interpretation invented for audits; it is the plain consequence of the policy text combined with the general Oracle Database licensing rule that installation triggers the license. Treat the ten-day rule as unavailable to your ODA pair and plan the standby as a licensed system from day one, then use core activation to control what "licensed" costs.
The architecture that makes the DR investment worth funding is the same architecture that disqualifies it from the free failover right.
Assume for a moment that you have engineered around the site and storage clauses and genuinely believe the allowance is available. The counting mechanics will still catch you, because they are far harsher than the phrase "ten days" implies. Oracle counts 24-hour periods, and any portion of a period consumes the whole period. Oracle's own example in the policy is unambiguous: a failover node down for two hours on Tuesday and three hours on Friday has consumed two of the ten periods, not five hours of a 240-hour budget. The periods do not need to be consecutive, so a year of short, well-managed switchovers burns the allowance faster than one long outage. In practice, five hours of actual runtime across a year can exhaust two-fifths of the entitlement if the events land on four separate calendar days. Any organisation running quarterly switchover drills plus genuine incidents will cross ten periods well before December.
What happens at period eleven is the part buyers consistently underestimate. The consequence is retroactive, not prospective. Exceed the allowance and Oracle does not bill you for period eleven onward; it treats the standby as a licensed deployment for the whole calendar year and requires full Processor or Named User Plus licenses covering all cores active on the standby appliance, backdated, with support arrears layered on top. On a 64-core X11-L that has been running unlicensed all year, the exposure is the full standby license stack plus roughly 22 percent annual support against a backdated effective date, and the same option and pack parity you carry on the primary. The cores you activated on the standby, not the cores you used, set the number.
The final trap is evidential. The burden of proof sits with the customer, not with Oracle. If you cannot produce dated incident tickets, switchover logs, and a clean record of when redo apply started and stopped, an auditor will not credit you with a partial year. In my experience, undocumented events default to Oracle's assumption, which is continuous deployment. Instrument your DR runbook now: log every activation with start time, stop time, ticket reference, and the sign-off that returned the primary to service.
Here is the part that catches experienced infrastructure teams: Oracle's data recovery licensing policy does not treat a DR test as a cheap draw against your ten-day allowance. Testing, reporting, and backups taken on the standby are excluded from the exception entirely. That is not a nuance, it is a category difference. A genuine failover, where the primary is down and you activate the standby to keep the business running, consumes one 24-hour period. A quarterly DR drill, where the primary is perfectly healthy and you are proving your runbook to an auditor, consumes nothing, because it never qualified in the first place. It simply sits outside the allowance and establishes that the standby was installed and running for a licensable purpose. Four drills a year do not burn four of your ten days. They establish four documented instances of unlicensed use.
A DR drill does not consume ten-day credit, it consumes nothing, because it never qualified for the exception in the first place.
The exposure compounds when someone opens the standby read-only to validate that the data actually arrived. In our negotiation experience, this is the single most common way clients discover an Active Data Guard liability they never intended to create. A physical standby in mount state applying redo is included with Enterprise Edition. The moment that database is opened read-only while managed recovery is running, you have activated Real-Time Query on Physical Standby, and that is the paid Active Data Guard option. One SELECT statement, run once, by a DBA confirming row counts during a Saturday test window, is sufficient.
The detection mechanism is what makes this unforgiving. Usage is written permanently to DBA_FEATURE_USAGE_STATISTICS under the string "Active Data Guard - Real-Time Query on Physical Standby". That view is not a rolling window and it is not cleared by patching, restart, or role transition. Oracle's standard audit collection scripts read it directly. A single validation query executed three years ago by a contractor who has since left surfaces in the LMS output today, with a first-usage date and a last-usage date attached. You will be asked to explain it, and "it was only a test" is precisely the answer the policy already rules out.
Start from the baseline and be honest about it. Basic Data Guard, meaning a physical standby held in mount state with redo apply running, is included with Oracle Database Enterprise Edition at no additional license cost. That is the good news and it is where most vendor conversations stop. The bad news is that the included feature says nothing about the hardware underneath it. Oracle's position is consistent and long standing: any server on which Oracle software is installed and/or running must be fully licensed. A standby ODA has the database binaries installed, the instance mounted, and redo apply active. It is running. The second appliance therefore needs Enterprise Edition licenses on every activated core, at the same edition as the primary. This is the mechanism that doubles the bill, and it is not Active Data Guard that causes it. Basic Data Guard on unlicensed metal is enough.
Parity extends past the base edition to every option and management pack in the primary stack. If the primary uses Partitioning, Advanced Compression, or Diagnostics and Tuning, the standby needs the same options at the same core count, because redo apply reconstructs partitioned and compressed structures on the target. Diagnostics and Tuning is the quiet one: on an ODA, several packs are enabled by default, and you should confirm what is actually running before you size anything. Our guide to which options and packs get enabled by default on an ODA covers the specific parameter settings to check.
| Component | List price (2026 Technology Price List) | Standby ODA planning basis |
|---|---|---|
| Database Enterprise Edition | Per processor, plus 22% annual support | Full parity with primary on all activated cores |
| Basic Data Guard (mount state, redo apply) | Included with EE | No incremental license, hardware still requires EE |
| Active Data Guard | 11,500 USD per processor, 230 USD per NUP | Plan on both primary and standby processors |
| Active Data Guard annual support at 22% | 2,530 USD per processor per year | Applied to both sides under conservative planning |
| Options in use on primary (Partitioning, Advanced Compression, Diagnostics and Tuning) | Per processor each | Same option, same core count, on the standby |
On the Active Data Guard figure, the published sources are not unanimous. Three independent 2026 references put it at 11,500 USD per processor and 230 USD per NUP, against one outlier claiming 23,000 USD. We use 11,500 USD because it is corroborated three to one, and we recommend verifying against the current Oracle Technology Global Price List PDF before you sign anything. On the question of which side pays, the sources also split, with some arguing the standby host alone and others insisting on both primary and standby processors. Model it as both. If your Oracle account team later concedes the narrower reading in writing, you have found budget. If you modelled the narrow reading and Oracle asserts the broad one during an audit, you are negotiating from a hole.
Once you accept that a Data Guard standby needs real licenses, the only remaining question is how many cores you have to license, and that is where Capacity-on-Demand (CoD) does the work. ODA appliances ship with every core enabled by default. Nobody at Oracle will phone to tell you this. If you rack an X11-L, power it on, and run the software install without touching core counts, you have just created a 64-core deployment and, at the standard 0.5 Intel core factor, a 32 processor license obligation on a box whose only job is applying redo. The buyer has to actively reduce cores before deployment. Per Oracle's ODA 19.28 Capacity-On-Demand Licensing documentation, Enterprise Edition on any X11-family appliance can be deployed with as few as 2 enabled cores, which is a single processor license after the core factor. Standard Edition 2 has a different floor: it starts at 8 enabled cores, which counts as one SE2 processor license because SE2 is licensed per socket and ignores core factors. All CoD changes move in multiples of two. There is no odd-core option, so plan your DR core budget in even increments and confirm the setting during deployment, not after. If you are still choosing between editions for the pair, read our comparison of Standard Edition 2 versus Enterprise Edition on an ODA before the hardware order goes in, because edition choice constrains your CoD floor permanently.
| ODA model (X11 family) | Physical cores shipped | EE minimum enabled cores | EE processor licenses at minimum | SE2 minimum enabled cores |
|---|---|---|---|---|
| X11-S (single server) | 32 | 2 | 1 | 8 |
| X11-L (single server) | 64 | 2 | 1 | 8 |
| X11-HA (two servers) | 128 (2 x 64) | 2 per server | 1 per server | 8 per server |
The practical DR pattern we see work: primary sized to actual production demand, standby enabled at the smallest core count that sustains redo apply and meets your recovery time objective under load. In our negotiation experience, a well-tuned redo-apply-only standby commonly runs at 4 to 8 enabled cores against a primary at 16 to 32, which is a genuine reduction rather than the doubling Oracle's default configuration produces. Options and packs still need parity on whatever cores you do enable, so the options enabled by default on an ODA deserve a line-by-line review on the standby too. CoD cuts the multiplier, not the option list.
CoD has one characteristic that turns a cost lever into a liability trap: core activation is irreversible. You can increase enabled cores on an ODA. You cannot decrease them. Oracle's CoD terms permit upward scaling only, and once a core is activated on a specific appliance, that appliance carries the higher license requirement permanently, regardless of what you do afterwards. Now apply that to a real DR event. Your primary site goes dark. You fail over to the 4-core standby, discover it cannot carry production load, and scale it to 32 cores to keep the business running. Two weeks later the primary is restored and you fail back. The standby returns to redo-apply duty at a fraction of its capacity, but you now own 16 processor licenses on that appliance forever. A fourteen-day outage has permanently converted into a seven-figure support-bearing liability at list prices. Nobody in the incident bridge is thinking about license terms at 3am, which is exactly why the decision must be made before the incident.
A fourteen-day outage becomes a permanent license liability, because the core count on that appliance can never come back down.
Design around it deliberately. Four moves, in order of leverage. First, decide now what "acceptable degraded service" looks like on the standby, and size DR cores to that, not to full production parity, so scaling up is a conscious exception rather than a reflex. Second, put a failback window in your runbook with a named owner, because every day on the scaled standby is a day you cannot argue was temporary. Third, negotiate written language with Oracle, ideally at hardware purchase or your next renewal, covering how post-incident core reductions or license reallocation between appliances will be handled; Oracle will not offer this, but we have seen it conceded when it is a stated condition of a multi-appliance deal rather than a post-incident request. Fourth, model the worst case in your business case before you sign the hardware order: primary cores plus emergency standby cores plus full option parity, at list, with 22 percent support. If that number is survivable, proceed. If it is not, your DR architecture needs changing, not your licensing paperwork. Our ODA licensing buyer guide covers the wider set of core-scaling traps that surface after the appliance is in the rack.
Work this in order, because the discovery steps protect you from the negotiation steps going badly. First, run DBA_FEATURE_USAGE_STATISTICS on every standby database you own, not just the ODA pair, and look for "Active Data Guard - Real-Time Query on Physical Standby." That view is permanent and cumulative: a single read-only SELECT from a 2019 reporting test is still sitting there, and Oracle's audit scripts will find it. You want that finding in your hands months before an LMS engagement, because the remediation options differ enormously depending on who discovers it. Our breakdown of why the Active Data Guard standby is never free covers what to do when the flag is already set.
Then the commercial move. Buy the DR appliance, the standby database licenses, and the ADG option in the same transaction as primary capacity. In our experience negotiating these deals, discount leverage collapses once the primary purchase order is signed, and a DR add-on bought six months later routinely lands 15 to 25 points worse. Pair that with the CoD scaling mechanics in our ODA licensing buyer guide and price the standby at minimum viable cores from day one.
In practice, no. Oracle's policy limits the allowance to machines arranged in a cluster sharing one logical disk array in a single data center, which a WAN-replicated ODA pair in a second site cannot satisfy. A mounted standby applying redo is also treated as installed and running, so the exception never attaches. Plan on licensing the standby appliance.
The Data Guard feature is included with Enterprise Edition at no additional license cost, but the standby appliance itself is not free. Any server with Oracle software installed and running requires full processor or NUP licenses for its enabled cores, at the same edition and with the same options and packs as the primary.
The 2026 Technology Price List figure is 11,500 USD per processor or 230 USD per Named User Plus, plus 22 percent annual support. One outlier source quotes 23,000 USD; the lower figure is corroborated more widely, so verify against the current PDF. Assume ADG must be licensed on both primary and standby processors when budgeting.
No, and that is the trap. Oracle's data recovery policy excludes testing, reporting, and backups from the exception, so a DR test does not draw down credit, it sits outside the allowance and can create full-license exposure. If the standby is opened read-only during the test, that also triggers Active Data Guard.
No. Capacity-on-Demand core activation is a one-way ratchet: once you increase the enabled core count, you can only increase it further. Scaling a minimally licensed DR ODA up to production capacity during an outage creates a permanent license obligation on that appliance, so model the worst-case failover before you buy.
Keep the standby in mount state with redo apply only, avoid any read-only access so Active Data Guard is never triggered, and activate the minimum CoD core count needed to sustain redo apply (2 cores for Enterprise Edition, 8 for Standard Edition 2). Match options and packs to the primary at that reduced core count, and negotiate DR capacity in the same deal as the primary.
Most Oracle Database estates carry 20 to 30 percent removable spend. The buyer side playbook for edition right sizing, option pruning, and third party support.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
