Oracle / Disaster Recovery
Oracle disaster recovery licensing. The 2026 rules.
Oracle disaster recovery licensing turns on one narrow exception and a set of cloud counting rules. Read the rules before the next audit reads your standby estate.
Oracle disaster recovery licensing turns on one narrow exception and a set of cloud counting rules. Read the rules before the next audit reads your standby estate.
Oracle disaster recovery licensing turns on the failover rule, what Active Data Guard requires, and how standby maps in the cloud. This guide covers the rules, the audit traps, and the buyer side moves.
Oracle lets you run a passive standby node for up to 10 separate days in a calendar year without a license for that node. The node must be truly passive. It cannot run production work outside the failover event.
The rule sits in Oracle ordering documents rather than in a single price list line. Read the wording in your own contract, because the right travels with the agreement, not with marketing material. Oracle frames the policy in its Software Investment Guide.
One physical node. One Oracle program set. Up to 10 days of live failover per year. The clock counts any day the standby runs the production workload, including tests. Every cluster node other than that single passive standby needs full licenses.
Active Data Guard is a paid database option, not a free feature. The moment a standby opens for read only queries, reporting, or offloaded backups, it is doing work. That node then needs the same Database edition, the same options, and the Active Data Guard option itself. Oracle documents the capability on its Data Guard product page.
Real time read only access to a physical standby, automatic block repair, and offloaded backups. Each of these turns the standby into an active node for licensing purposes.
It does not waive the base Database license on the standby. It does not extend the 10 day failover window. Active Data Guard is an addition on top of full licensing, never a substitute for it.
Standby type and what it costs to license
| Standby configuration | Passive failover only | License required |
|---|---|---|
| Mounted, not open | Yes, up to 10 days | No license inside the window |
| Open read only with Active Data Guard | No | Full Database plus Active Data Guard |
| Open for reporting or backups | No | Full Database edition and options |
| Second standby node | No | Full license regardless of use |
White Paper ยท Oracle
The Oracle Buyer Side Framework
The moves we use across Oracle Database, Java and ULA estates. Read it free.
The metric changes with the platform. On Oracle Cloud Infrastructure, license included and bring your own license both exist. On AWS and Azure, the Oracle cloud policy counts vCPUs, and the standby node counts the same as any other node unless it meets the failover exception.
Autonomous Database and Base Database Service offer standby configurations with metered or owned license pricing. Oracle frames cloud counting in its cloud licensing policy and supports moving owned licenses through bring your own license.
The standard system integrator pitch is that a disaster recovery standby is free because it only runs during an outage. We disagree. In roughly 6 of 10 estates we reviewed, the standby was mounted and open for reporting or backups, which makes it an active node that Oracle can license in full at audit. The free standby is a narrow exception with strict conditions, not a default state. The buyer side move is to design the standby to stay genuinely passive, log every failover day, and price Active Data Guard before deployment rather than after a finding lands on the desk.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
A disaster recovery standby is free only when it does nothing. The moment it reports, queries, or backs up, it is a licensed node.
Seven levers recur in well managed Oracle disaster recovery estates.
A standby is free only when it stays passive and runs for no more than 10 failover days a year. A mounted and closed node qualifies. A node open for reads, reporting, or backups does not and needs full licenses.
Oracle allows up to 10 separate failover days in a calendar year for one passive standby node. Any day the standby runs the production workload, including a test, counts toward the limit.
No. The failover exception covers a single passive standby node. A second standby node needs full licenses regardless of how rarely it runs.
Yes. Opening a physical standby for real time read only access uses the Active Data Guard option, which is licensed on top of the base Database edition and options on that node.
On AWS and Azure the Oracle cloud policy counts vCPUs, with two vCPUs equal to one processor license where hyperthreading is on. A running standby counts like any other node unless it is the one passive failover node.
No. The Oracle processor core factor table does not apply on authorized cloud environments such as AWS and Azure. The vCPU rule governs the count instead.
The most common finding is a standby treated as free that was in fact mounted and open. Without a failover day log, the auditor assumes continuous use and licenses the node in full.
Inventory every standby, confirm which node meets the failover exception, and build a failover day log. Document how each standby operates so you can prove passive status rather than argue it after a finding.
Oracle ULA exit moves, Java audit defense posture, certification framework, and the buyer side moves across the Oracle Database, Java, and EBS estate.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
