Understanding Oracle's Disaster Recovery Licensing Framework

Oracle Database Enterprise Edition includes the right to maintain a passive physical standby database for disaster recovery purposes. This is a significant benefit — maintaining a synchronised physical copy of your production database to provide rapid failover capability is fundamental to any serious DR strategy. However, the conditions under which that standby can be kept "free" from a licensing perspective are narrower than most organisations realise, and the penalties for exceeding those conditions are commercially severe.

Oracle's DR licensing framework is governed by its Data Recovery Licensing policy document, which sets out the conditions under which a standby database node does not require separate licence coverage. The key concept is the distinction between a passive standby — one that receives redo log data from the primary but is not open for any user access — and an active standby that is open for queries, reporting, or other workloads. A passive standby can receive a limited failover exemption; an active standby requires a full Active Data Guard licence.

In one engagement, a global financial services group assumed their OCI-hosted DR instance qualified for the 10-day failover exemption. It did not. The audit claim reached $3.4M. Working with our Oracle licensing advisory specialists, the final settlement was $680,000 — our fee was less than 3% of the exposure.

The 10-Day Rule: What It Covers and What It Does Not

Oracle's 10-day rule — formally described in the Data Recovery Licensing policy — provides an allowance for up to 10 separate 24-hour periods per calendar year during which a standby node can be activated (become the primary database) without requiring separate licence coverage for that standby node. This is designed to accommodate genuine disaster recovery failover events, planned maintenance switchovers, and DR testing.

The 10-day rule has strict conditions:

  • The primary and standby must be in the same data centre, sharing a single logical disk array. Oracle explicitly requires shared storage in a clustered configuration — geographically separated DR sites do not qualify.
  • Only one standby node per clustered environment receives the 10-day allowance, even if multiple standby nodes are configured.
  • Each activation counts as one day, regardless of whether the failover was active for 1 hour or 23 hours on that calendar day.
  • If the failover exceeds 10 cumulative days in a calendar year, the exemption is void for that year, and Oracle treats the standby as requiring full licence coverage from the first day of failover that year.

The most critical limitation: the 10-day rule does not apply in public cloud environments. Oracle explicitly excludes cloud-hosted DR configurations from the 10-day rule's scope. If you run a standby database in OCI, AWS, or Azure as your DR target — even in a completely passive, non-accessible state — you cannot claim the 10-day rule exemption when you activate it.

"Many organisations discover their cloud DR configuration carries full licence obligations only when Oracle's LMS team cites the cloud exclusion from the 10-day rule during an audit. The cost can be as significant as the primary database licence itself."

Data Guard vs Active Data Guard: The Licence Boundary

Oracle Data Guard is included with Oracle Database Enterprise Edition at no additional cost. It provides the physical and logical standby database infrastructure that underpins Oracle's DR and high availability story. However, the boundary between the free Data Guard and the separately licensed Active Data Guard is frequently crossed without awareness.

What Is Included in Data Guard (Free)

Under the base Data Guard licence (included with EE), customers are entitled to maintain a standby database that receives and applies redo data from the primary, is closed to any user queries or access, and activates only in genuine failover scenarios. The standby may be in recovery mode — applying redo — but it must not be open for queries. Background processes that support standby maintenance (MRP, RFS) run without requiring Active Data Guard.

What Requires Active Data Guard

Active Data Guard is required whenever the standby database is opened in read-only mode for any purpose — queries, reporting, offloading backups, testing applications against production data, or any other active access. Active Data Guard list price is $11,500 per processor, licensed against the primary database processor count (you licence the primary, not the standby). Annual support at 22% adds $2,530 per processor per year, increasing at 8% per year.

Common ways Active Data Guard usage is triggered without awareness include: issuing a SELECT statement against the standby for a quick data check, connecting backup software to the standby to offload backup I/O from the primary, enabling Automatic Block Repair (which is an Active Data Guard feature), or running the standby in "open read only with apply" mode in any automated infrastructure management tool.

Oracle Cloud Infrastructure (OCI) DR Licensing

OCI provides the most commercially favourable licensing environment for Oracle Database DR configurations. Key advantages include the ability to pause BYOL database instances and stop licence consumption when the instance is not running, and OCI's simplified 2 vCPUs = 1 processor licence rule without the Core Factor Table.

For BYOL customers using physical standby Data Guard on OCI, Oracle's position is that a fully stopped OCI instance (one that is not running) does not consume licences. If you terminate the standby OCI instance between DR tests and restart it only during actual failovers or scheduled tests, you may be able to manage your active licence consumption carefully. However, simply having the instance stopped but not terminated does not necessarily eliminate the licence obligation — Oracle's position on this should be confirmed in writing as part of your OCI contract.

Oracle's OCI Full Stack Disaster Recovery service, updated in October 2025 with standardised templates and enhanced automation, provides a managed DR orchestration layer that supports cross-region and cross-cloud failover. For customers using licence-included OCI Database services (not BYOL), the Oracle licence is bundled into the hourly consumption charge — meaning you pay Oracle for the cloud service only while it is running, with no separate perpetual licence obligation for the DR instance. This is commercially attractive for organisations that do not already have a significant on-premises Oracle EE licence estate.

AWS and Azure DR Licensing

DR configurations on AWS and Azure are governed by Oracle's Authorised Cloud Environment (ACE) policy. The 2 vCPU = 1 processor licence rule applies on both platforms, and the Core Factor Table does not. However, a key commercial risk is that on AWS and Azure, Oracle licence obligations may begin as soon as Oracle binaries are present and the instance is powered on, even if the database is in passive standby mode. There is no equivalent of OCI's stopped-instance licensing treatment on these platforms.

For organisations using AWS RDS for Oracle or Azure SQL Managed Instance (licence-included services), the DR model is fundamentally different: the cloud provider manages the Oracle licence as part of the managed service, and multi-AZ or geo-redundant configurations are covered by the service pricing without additional Oracle licence obligations. For BYOL configurations on EC2 (AWS) or Azure VMs, the licensing obligation starts with instance launch and must be calculated based on the vCPU count of the standby instance, even before any failover occurs.

Do your Oracle DR configurations carry hidden licensing costs?

Redress Compliance audits DR architectures and quantifies cloud licensing exposure before Oracle does.
Get a DR Licence Review →

Oracle Support and DR Environments

A frequently overlooked aspect of Oracle DR licensing is the support fee treatment of standby databases. In general, Oracle support fees are calculated on the primary database licence. If the standby database requires its own separate licence (because the 10-day rule does not apply, the standby is active, or it is in a cloud environment), that separate licence also carries its own annual support charge — at 22% of the perpetual licence fee, increasing at 8% per year.

For a large enterprise Oracle Database environment with multiple DR targets, this support multiplication effect is significant. A 64-processor primary database with active cloud-hosted DR instances in both OCI and a secondary cloud platform, each requiring full licence coverage, can result in support obligations three times the original primary licence support cost — growing at 8% annually across all three licence sets. Modelling the full lifecycle support cost before designing a multi-cloud DR architecture is essential and consistently undervalued in DR planning exercises.

Strategies for Managing Oracle DR Licensing Costs

The most effective strategies for managing Oracle DR licensing costs start with the architecture design, not the negotiation. If your DR architecture qualifies for the 10-day rule exemption (same data centre, shared storage, single standby node, passive standby), the licensing cost is essentially zero outside of active failover windows. If the architecture is cloud-based, the costs must be factored in explicitly.

For cloud DR, OCI licence-included Database services eliminate the separate perpetual licence obligation and convert the DR cost into a variable operational charge. This is frequently cheaper than maintaining BYOL perpetual licences for standby environments that are rarely activated — particularly when combined with OCI's stopped-instance billing model. If you already have a ULA or PULA that covers Oracle Database EE, cloud DR instances covered by that agreement can be deployed without additional licence cost during the ULA term, making ULA coverage one of the most powerful tools for managing cloud DR licensing exposure. Oracle's support fees under a ULA are typically fixed during the ULA term regardless of how many instances are deployed — making it the most efficient structure for organisations with expanding cloud DR footprints.

Key Questions to Answer Before Designing Your DR Architecture

Before finalising your Oracle DR architecture, ensure you can answer these licensing questions with confidence. First, is the standby in the same data centre as the primary, sharing physical storage? If yes, the 10-day rule may apply. If no, it does not. Second, will the standby ever be opened for any user access — even read-only? If yes, Active Data Guard is required. Third, is the DR target a cloud environment? If yes, the 10-day rule is explicitly excluded. Fourth, does your ULA or other agreement cover the cloud DR deployment? Fifth, what is the total 10-year cost of your DR architecture including primary and standby support fees at 8% annual growth? If you cannot answer these questions from existing documentation, a confidential review from Redress Compliance is the fastest route to clarity.