Home  ›  Blog  ›  Oracle DR Licensing
Oracle · Disaster Recovery

Oracle DR licensing — the 10-day rule and what it does not say.

Oracle disaster recovery licensing is one of the most consistently misunderstood corners of the rulebook. The "10-day rule" is real, narrow, and often invoked far more broadly than it permits. Standby databases licence as production unless very specific conditions are met; Active Data Guard is a separate Option licence on the standby; and most failover testing breaks the exemption. Here is what the rules actually allow.

Updated: April 2026 Reading time: 11 min Audience: DBA Lead, Infrastructure Architect, IT Asset Manager
DR site
The 10-day rule

A failover exemption, not a free DR site.

Oracle's failover policy — informally the "10-day rule" — permits a customer to fail over Oracle workloads to a secondary host for up to 10 days per calendar year without separately licensing that host. The rule applies only when the secondary host is part of a clustered configuration, the failover is for the purpose of disaster recovery, and the secondary host does not run Oracle workloads outside of failover events.

The rule is narrow. It does not cover warm standbys running Data Guard apply in normal operation. It does not cover read-only standby use for reporting. It does not cover storage replication where the secondary host periodically mounts the database. It does not cover annual failover testing exceeding 10 days. And it does not cover any deployment where the secondary host has Oracle running outside of an actual outage.

What "10 days" actually means

Ten days per calendar year, cumulative across all failover events. A two-day failover test in March, a one-day actual failover in July, and a six-day test in December consumes all 10 days. An eleventh day in the same calendar year requires the secondary host to be fully licensed for the entire period. The rule resets at year boundary, not at event end.

Designing a DR architecture for Oracle?

The licensing rules and the technology rules need to be modelled together. They usually aren't.

Contact Us →
Standby databases

Active versus passive, under Oracle's reading.

Physical standby (Data Guard)

A physical standby running Oracle Data Guard apply — even when not open for query — is a running Oracle Database under Oracle's audit position. The standby host must be licensed unless it qualifies under the 10-day failover rule, which requires the standby not to be running Oracle apart from actual failover events. In most enterprise DR architectures, the standby is running continuously, applying redo logs in real time. That use does not qualify for the 10-day exemption.

Active Data Guard

If the standby is opened in read-only mode for reporting workloads — directly, or via Active Data Guard's real-time query — the customer requires the Active Data Guard Option licence on the standby host, in addition to standard Database licensing. Active Data Guard is one of the most commonly under-licensed Options at audit.

Logical standby

Logical standby (Data Guard SQL Apply) opens the standby database in read-write mode while applying redo. The standby is, by definition, an open database. Standard Database licensing applies. The 10-day failover rule does not apply because the database is operating outside of failover events.

Storage replication and snapshot-based DR

Storage-level replication (SRDF, SnapMirror, etc.) where the secondary database is not running between failover events is the most defensible DR architecture under the 10-day rule. The Oracle binary is installed on the secondary; the database is not open; no Oracle process is running until failover initiates. Customers running this pattern qualify for the 10-day exemption cleanly, provided test failovers stay within the limit.

Download the Oracle Compliance & Negotiation Playbook.

The DR architecture matrix and the failover rule's exact wording.

Get the playbook →
RAC, FailSafe and HA

Different rules for different topologies.

Real Application Clusters (RAC)

RAC nodes are active by definition — each node runs an Oracle instance against a shared database. Each node requires full Database EE licensing plus the RAC Option licence. The 10-day failover rule does not apply to RAC; all nodes are licensed in normal operation.

Oracle Clusterware FailSafe

Active-passive failover configurations using Oracle Clusterware (without RAC) qualify under the 10-day failover rule, provided the passive node is genuinely passive — Oracle binary installed, no instance running between failover events.

Third-party clustering

Veritas Cluster Server, IBM PowerHA, Windows Server Failover Cluster and similar third-party clusters can host Oracle failover topologies that qualify under the 10-day rule. The technical configuration must support genuine passive failover — the database not running between events. The same evidence requirements apply.

Cloud DR

Cloud DR follows the same rules.

Oracle's DR rules apply identically to on-premises and cloud deployments. A standby Oracle database on AWS, Azure, GCP or OCI requires licensing on the same basis as on-premises. The 10-day failover exemption applies provided the cloud standby is genuinely passive. Cloud architectures involving auto-recovery, multi-AZ Oracle RDS, or cross-region replicas typically run the standby instance continuously and therefore require full licensing.

See our BYOL to cloud guide for the broader cloud licensing context.

DR exposure in an Oracle estate?

Most DR architectures we audit have at least one licensing gap. Better to find it before LMS does.

Contact Us →

For any enterprise with a significant Oracle DR footprint, an independent review against the 10-day rule and the Active Data Guard boundary is the most efficient way to surface exposure before an audit does.

Oracle DR architecture worth a second look?
The exposure is rarely zero.

Our Oracle team reviews DR and HA configurations against Oracle's audit positions. From there our license cost reduction review removes the standby licences you do not owe.

The Compliance Brief

Weekly compliance intelligence for IT leaders.