Exadata Licensing for Disaster Recovery in 2026: Failover Rules, Active Data Guard, and the Cost Levers

Why Exadata DR licensing is the most-asked, least-understood topic

Almost every Exadata deployment has a disaster-recovery (DR) topology. Almost every Exadata buyer assumes the DR site is cheap, or even free, under the standby-licensing rules. Almost every Oracle LMS audit on an Exadata estate finds DR licensing exposure - usually because the standby was promoted to active for testing, or because Data Guard was upgraded to Active Data Guard for read-only reporting, or because the standby was used for backup offload. Each of those triggers a different licensing outcome and a different audit defence.

Exadata licensing for disaster recovery in 2026 is the most-asked question we field on the platform. The answer depends on five variables: the DR topology (cold standby, warm standby, hot standby, active-active), the Data Guard mode (physical, logical, snapshot), whether Active Data Guard is enabled, whether the standby is on Exadata or non-Exadata, and whether the secondary cluster runs continuously or is started only on failover. Each combination has a distinct licensing outcome.

This article decodes the 2026 picture: the failover-rights rule, the 10-day rule, when Active Data Guard becomes chargeable, how DR licensing changes on ExaCC and Database@hyperscaler, the audit surface, and the five negotiation levers at renewal. The wider Database framework is in the Oracle Database Licensing Guide; the compliance framework is in the Oracle Compliance Master Guide; the broader Exadata cost framework is in the ExaCC pricing anatomy piece.

The failover-rights rule and the 10-day exemption

Oracle's licensing rules for DR are documented in the OMA and in the Oracle Software Investment Guide (SIG). Two rules govern the standby-licensing posture:

1. The failover-rights rule: a cold or warm standby that is not running the Oracle Database software does not require a separate Database licence, provided it is genuinely a failover environment - not a production environment - and provided the database is not started for any purpose other than periodic testing.
2. The 10-day rule: the standby may be started for up to 10 days per calendar year for failover testing or actual failover, without triggering additional licensing on the standby cluster. The 10 days is a hard cap; the 11th day triggers full licensing of the standby at its activated core count.

Both rules apply only to cold or warm standbys - environments where the database software is not actively running. The moment Data Guard apply is enabled in a way that runs the database on the standby continuously (managed recovery mode, real-time apply, or read-only mode), the failover-rights rule no longer applies and the standby becomes a hot standby.

Hot standby means: Data Guard physical standby with managed recovery running, or any standby with active database processes. Hot standbys require full Oracle Database EE licensing at the activated core count of the standby cluster, identical to the primary.

Active Data Guard - the option that permits read-only access to the standby while it is in recovery mode - is a separate paid option at $11,500 per Processor list. Enabling Active Data Guard requires the option licensed on both primary and standby. This is the most-audited Exadata DR finding: a customer enables Active Data Guard for reporting offload, forgets to license the standby, and the audit lands at $1M-$3M of remediation.

The five Exadata DR topologies and their licensing

Five DR topologies cover ~95% of Exadata deployments in 2026. Each carries a distinct licensing posture.

The pattern: only cold and warm standbys avoid standby-side licensing. Anything that touches the database for read or apply triggers full licensing of the standby cluster. The 10-day rule is a testing carve-out, not an operational carve-out - customers who run the standby in read-only mode 'for two hours a day for reporting' have triggered full Active Data Guard licensing for the entire year.

The single most common audit finding on Exadata DR: a customer assumes 'we only failover once a year for the DR test, so we're under 10 days' - and the audit pulls the standby's v$log_history showing managed recovery running continuously. Recovery is not failover. Recovery is hot-standby operation. The 10-day rule does not apply to recovery.

Data Guard modes and their licensing impact

Data Guard ships with every Oracle Database Enterprise Edition licence - it is not a separately-licensed option. The Data Guard modes have different licensing impacts:

• Physical standby with managed recovery (no reads): standby requires full EE on activated cores. No additional option.
• Logical standby: standby is open and writeable for non-replicated objects, requires full EE plus any options used (Partitioning, Compression, etc.).
• Snapshot standby: temporary read-write conversion of a physical standby. Requires full EE on standby. The snapshot mode is bounded by the 10-day rule if total duration is under 10 days per year, but the production-use exception applies if the snapshot standby is used for application testing.
• Active Data Guard (real-time read-only): requires Active Data Guard option + full EE on standby.
• Far Sync (zero-data-loss async): the Far Sync instance is a lightweight redo-only instance, free if the underlying redo-apply target is licensed.
• Fast-Start Failover (Observer process): the Observer is free; the standby DB it manages follows the standard mode rules.

The wider Data Guard cost-trade analysis sits in the Oracle MAA multi-cloud piece; the GoldenGate alternative is unpacked in the Oracle Database Licensing Guide.

DR licensing on ExaCC, ExaCS and Database@hyperscaler

The cloud Exadata variants change the DR-licensing posture in two material ways. First, on ExaCC and ExaCS under License-Included pricing, the DR rules are bundled into the per-ECPU rate - there is no separate Active Data Guard option to license, because the LI bundle includes it. Second, on BYOL across Database@hyperscaler the same on-prem failover-rights and 10-day rules apply, but the ECPU activation pattern matters: a stopped ECPU on the standby cluster does not incur Database@AWS / Database@Azure billing, so the cost of a cold standby is the storage allocation plus the cluster fee, not the ECPU rate.

The ExaCC LI bundle for DR (as of 2026):

The interesting BYOL pattern on Database@AWS or Database@Azure: provision the standby cluster with the same ECPU count as primary but keep it in 'stopped' state with only the cluster heartbeat running. Database@hyperscaler does not bill ECPUs while the cluster is stopped. The customer pays cluster + storage + Direct Connect / ExpressRoute but not the ECPU rate. On a 32-ECPU primary at $0.99/hr BYOL, the saving on the standby is $0.99 * 32 * 8760 = $277K/year. The standby is genuinely cold from a billing perspective but warm from a recovery-time perspective (a 5-10 minute restart on failover).

The detailed cost model for ExaCC DR is in the ExaCC pricing anatomy; the cross-cloud BYOL portability rules are in the Multi-Cloud BYOL rules.

What Oracle LMS pulls for an Exadata DR audit

Oracle LMS's standard Exadata DR audit script set in 2026 pulls a defined evidence map:

1. v$log_history and v$archive_log on the standby - shows whether managed recovery has been running and for how long.
2. v$database on the standby - shows open mode (MOUNTED, OPEN, READ ONLY, READ ONLY WITH APPLY).
3. DBA_FEATURE_USAGE_STATISTICS filtered on Active Data Guard usage - critical evidence.
4. The Data Guard configuration metadata - shows protection mode, transport mode, apply mode.
5. The standby cluster activated-core count and the cluster start/stop history.
6. Any GoldenGate process configuration if logical replication is in use.

The audit interpretation is mechanical: if Active Data Guard usage appears in DBA_FEATURE_USAGE_STATISTICS, the option is in scope at the standby cluster's full activated core count. If managed recovery has been running more than 10 days in the calendar year on the standby, full EE is in scope at the standby cluster.

The remediation discussion at audit is harder than option remediation because the standby cannot be turned off without breaking the DR SLA. The customer is locked into either licensing or accepting a contractual settlement. The defensive move is pre-emptive: structure the DR topology to maximise the cold-standby footprint and minimise the hot-standby and Active Data Guard footprint. Most Exadata estates can reduce DR licensing exposure 30-50% with topology changes that have no material impact on RPO or RTO.

The audit-defence framework is in the Oracle Audit Guide; the specific Exadata audit playbook sits in the Audit Defense service.

DR licensing optimisation - five concrete moves

Five moves that reduce Exadata DR licensing cost without compromising recovery objectives:

1. Convert hot standby to warm standby where the RPO allows. A warm standby (mounted, no apply running) carries no licensing if started under 10 days/year. The trade-off is the standby is not transactionally current. For batch-driven workloads with hourly or daily redo apply windows, the saving is the full standby EE licence pool.
2. Stop ECPU billing on Database@hyperscaler standbys. A stopped Database@AWS or Database@Azure standby cluster pays cluster fee + storage but not ECPU - saving 70-80% of the running-standby cost. The cluster restarts in 5-10 minutes on failover; the RTO impact is acceptable for most non-critical workloads.
3. Replace Active Data Guard with reporting replicas via GoldenGate. Active Data Guard at $11,500/Proc on both sites is expensive when the only requirement is reporting offload. A GoldenGate-fed downstream reporting database on a smaller platform is often cheaper per-Processor, even with GoldenGate licensing. The architecture is more complex; the cost is materially lower.
4. Consolidate DR onto fewer, larger clusters. Multiple primary databases failing over to a shared standby cluster reduces the standby activated core count. The trade-off is the standby cluster needs more capacity than any single primary, but the total core count is typically 40-60% smaller than the sum of dedicated standbys.
5. Far Sync for sync transport without licensing the destination. A Far Sync instance is free if the underlying destination is licensed. Use Far Sync to provide synchronous redo transport with zero-data-loss to a remote target without the cost of a full intermediate-site database licence.

The license-optimisation playbook sits in the Licence Optimisation Master Guide; the support-cost reduction overlay is in the Support Cost Reduction Guide; the broader MAA architecture is unpacked in the Oracle MAA multi-cloud piece.

Five contract levers for Exadata DR licensing

Contract negotiation at Exadata renewal can lock in better DR economics. Five levers:

1. Contractual definition of 'failover testing' as 30 days/year instead of 10. Oracle's standard 10-day rule is contractually negotiable on enterprise Exadata deals. A 30-day annual carve-out gives material flexibility for routine DR exercises.
2. Pre-paid Active Data Guard at 70-80% discount. If your roadmap includes any reporting offload from the standby, lock the ADG option price at the deal at the steep discount. Standalone ADG renewals run 40-55% discount.
3. Stopped-ECPU pricing clause on Database@hyperscaler standbys. Get the cluster-fee-only pricing for stopped standbys explicitly stated in the contract. Oracle's default is to bill the cluster baseline.
4. BYOL pool flexibility for standby use. Negotiate the contractual right to use the BYOL pool on either primary or standby cluster on demand, without re-allocation paperwork. This is critical for active-active configurations and for planned failover testing.
5. Audit scope carve-out for DR. Limit the LMS audit pull on the standby cluster to a defined evidence set. Without the carve-out, Oracle pulls the full Database EE evidence set on the standby as if it were a primary.

The wider negotiation framework is in the Oracle Negotiation Guide.

What to do next on Exadata DR licensing

Exadata DR licensing rewards topology discipline. Most Exadata customers can cut DR licensing exposure 30-50% by reclassifying the standby - from hot to warm, from continuously-applied to scheduled-apply, from continuously-running to stop-on-Database@hyperscaler. The trade-off in recovery time is acceptable for most workloads; the cost saving is material.

The action sequence we recommend:

1. Document the current DR topology, mode-by-mode, for every database on every Exadata cluster.
2. Identify the Active Data Guard usage in DBA_FEATURE_USAGE_STATISTICS. Quantify the audit exposure.
3. Score each database on the failover-time tolerance. Identify the candidates for warm-standby conversion.
4. Model the post-optimisation DR cost - typically 30-50% lower than baseline.
5. Implement the topology change before the next Oracle support renewal. Lock the new posture in the contract.

For deal-specific support, the independent Compliance Review, Licence Optimisation and Audit Defense services run this end-to-end. Further reading: Exadata IORM workload isolation, Exadata storage cell licensing, Oracle MAA multi-cloud.

Frequently asked questions

Does a cold standby Exadata cluster require Oracle Database licensing?

No. Under the failover-rights rule, a cold standby that is not running the Oracle Database software does not require a separate Database licence. The standby may be started for up to 10 days per calendar year (the 10-day rule) for testing or actual failover without triggering full licensing. The 11th day triggers full Database EE on the standby cluster at its activated core count.

Does Data Guard require a separate option licence?

No. Data Guard is included with every Oracle Database Enterprise Edition licence. Active Data Guard - the option that permits read-only access to the standby while in recovery mode - is a separate paid option at $11,500 per Processor list, required on both primary and standby. Logical standby, snapshot standby, Far Sync and Fast-Start Failover do not require additional options beyond the Database EE entitlement.

If I run managed recovery on the standby continuously, do I need to licence it?

Yes. Managed recovery on the standby means the database is running and applying redo continuously - that is a hot standby. Hot standbys require full Database EE licensing at the activated core count of the standby cluster. The 10-day rule does not apply to recovery; it applies only to failover testing or actual failover events. This is the single most common Exadata DR audit finding.

How does Database@AWS or Database@Azure change the standby licensing maths?

Stopped Database@hyperscaler clusters do not bill ECPU. A standby cluster provisioned at the same ECPU count as primary but kept stopped pays cluster fee + storage + Direct Connect / ExpressRoute, but not the ECPU rate. The saving on a 32-ECPU BYOL standby at $0.99/hr is approximately $277K/year. The trade-off is a 5-10 minute restart on failover. For most non-critical workloads the RTO impact is acceptable.

What is the audit risk if Active Data Guard appears in DBA_FEATURE_USAGE_STATISTICS?

Material. The audit interpretation is that the Active Data Guard option is in scope at the standby cluster's full activated core count. On a 96-core ExaCC half-rack standby that is $11,500 * 96 = $1.1M of remediation at list, before any contract settlement discount. The defence requires either licensing ADG on both primary and standby, or disabling the feature and documenting the disable in a runbook before the audit notification arrives.

Related Oracle licensing reading