DR Environment Types and Licensing Requirements
Oracle recognises five distinct disaster recovery configurations, each with fundamentally different licensing implications. The licensing requirement is determined by the activity level of the standby — not its label, not its intent, and not how rarely it is used. Any workload beyond passive redo application transforms a standby from a free DR asset into a fully licensable production system.
| DR Type | How It Works | Activity Level | Licence Required? | Cost Impact (16-core EE server) |
|---|---|---|---|---|
| Cold standby | Server powered off or Oracle not running; activated only during failover | None | No — covered by 10-day rule | $0 (free under 10-day rule) |
| Physical standby (Data Guard) | Database mounted, receiving and applying redo logs; not open for queries | Passive (redo apply only) | No — covered by 10-day rule (if truly passive) | $0 (free while passive) |
| Warm standby | Database periodically opened for read access, maintenance, health checks beyond redo apply | Active (intermittent) | Yes — full licensing required | $380,000 (8 proc × $47,500 EE) |
| Logical standby (Data Guard) | Database open for read/write; SQL Apply converts redo into SQL; queryable by users | Active (continuously open) | Yes — full licensing required | $380,000+ (full EE licensing) |
| Snapshot standby | Physical standby temporarily converted to read-write for testing; reverts to standby mode after | Active (during snapshot period) | Yes — licensed while in snapshot mode | $380,000 (full EE while writable) |
The "Passive" Standby Illusion
The most expensive DR licensing mistake is assuming your standby is passive when it is not. Oracle defines "passive" extremely narrowly: the database must be in mount mode applying redo logs only — no user connections, no application access, no read-only queries, no reporting, no OEM monitoring that triggers Diagnostics Pack usage. A single SELECT statement executed by a DBA checking data consistency transforms the standby from free (10-day rule) to fully licensable. On a 2-socket, 16-core server, that single query creates a $380,000 licensing obligation for Oracle Database Enterprise Edition — plus licensing for any database options used on the primary. Oracle's DBA_FEATURE_USAGE_STATISTICS records this activity permanently, and auditors check standby servers specifically for any evidence of active use.
The 10-Day Failover Rule — Exact Scope and Limitations
Oracle's 10-day rule permits running Oracle software on an unlicensed standby server for up to 10 cumulative days per calendar year during genuine failover events. This is the cornerstone of free DR licensing — but its conditions are far more restrictive than most organisations realise.
| Condition | 10-Day Rule Applies? | Explanation |
|---|---|---|
| Genuine unplanned outage — primary is down | ✓ Yes | Standby activated because primary has failed; this is the intended use case. Each day of activation counts toward the 10-day cumulative total. |
| DR testing / failover drill — primary is still running | ✗ No | Planned DR tests where both primary and standby are active do not qualify. The primary must be genuinely down. Testing requires separate licensing for the standby. |
| Planned maintenance — failover to DR while patching primary | ✗ No | Planned maintenance windows are not unplanned outages. Running production workload on the standby during patching requires full licensing. |
| Read-only reporting on standby | ✗ No | Any reporting or query workload on the standby — even read-only — is productive use that requires full licensing regardless of the 10-day rule. |
| Standby activated for more than 10 cumulative days | ✗ No (exceeded) | Once the 10-day cumulative limit is exceeded in a calendar year, the standby must be fully licensed for the remainder of the year. |
| Cold standby powered off until needed | ✓ Yes | Server with Oracle installed but not running qualifies. Activation during failover starts the 10-day counter. |
| Physical standby in mount mode (redo apply only) | ✓ Yes | Database receiving and applying redo logs in mount mode (not open) qualifies as passive. Failover activation counts toward 10 days. |
The 10-day allowance accumulates across the entire calendar year. If your primary fails for 3 days in March and 4 days in September, you have used 7 of your 10 days. A third outage lasting more than 3 days would exceed the limit. Once exceeded, the standby server must be fully licensed from that point forward — and Oracle may argue retroactive licensing for the entire year. Track every activation day in a formal log with timestamps, incident tickets, and proof that the primary was genuinely down during each activation. This log is your primary defence in an audit. Without it, Oracle can assert that any standby activation exceeded the 10-day limit.
Data Guard Licensing — Free Feature, Not Free Standby
Oracle Data Guard is included with Oracle Database Enterprise Edition at no additional licence cost. The Data Guard software itself — redo transport, redo apply, switchover, and failover capabilities — requires no separate licence. However, the standby database that Data Guard creates and maintains does require licensing if it performs any active work beyond passive redo application.
| Data Guard Configuration | Standby Activity | Licence Required? | Cost Impact and Notes |
|---|---|---|---|
| Physical standby — mount mode | Redo apply only; database not open; no user connections | No (10-day rule) | $0 — the only truly free DR configuration. Must remain strictly passive. |
| Physical standby — read-only open | Database opened read-only for queries (Active Data Guard feature) | Yes — ADG option + full DB EE licensing | $380,000 DB EE + $92,000 ADG option = $472,000 on 16-core server |
| Logical standby | SQL Apply; database open for read and write; queryable | Yes — full DB EE licensing | $380,000+ — logical standby is always considered active |
| Snapshot standby | Temporarily writable for testing; reverts to physical standby after | Yes — while in snapshot mode | $380,000 during writable period; reverts to free when returned to mount mode |
| Switchover (planned role change) | Primary and standby swap roles; brief transition period | No — temporary switchover covered | $0 during brief switchover; once new roles stabilise, standard licensing applies to each |
| Failover (unplanned) | Standby becomes primary during outage; original primary is down | No (10-day rule, if within limit) | $0 within 10-day cumulative limit; full licensing if exceeded |
Active Data Guard — The Most Expensive DR Licensing Trap
Active Data Guard (ADG) is a separately licensed Oracle Database option that enables read-only access to a physical standby while it continues to apply redo from the primary. ADG costs $11,500 per processor at list price and must be licensed on both the primary and the standby server — with the standby also requiring full Oracle Database Enterprise Edition licensing to match the primary.
| ADG Feature | Triggers ADG Licensing? | How It Creates Exposure |
|---|---|---|
| Real-Time Query (read-only standby) | Yes | Opening the standby database read-only while redo apply continues. This is the core ADG feature. Any SELECT statement on an open standby = ADG licensing required. |
| Automatic Block Repair | Yes | ADG-specific feature that repairs corrupted blocks by fetching from the standby. Enabled automatically in some configurations without DBA awareness. |
| Real-Time Cascade | Yes | Allows a standby to forward redo to another standby in real-time. Requires ADG licensing on all servers in the cascade chain. |
| Far Sync Instance | Yes | Lightweight instance that receives and forwards redo; requires ADG licensing even though it hosts no data. |
| DML Redirection | Yes | Allows write operations on an Active Data Guard standby (redirected to primary transparently). Requires ADG licensing. |
| Fast Incremental Backup from Standby | Yes | Offloading RMAN incremental backups to the standby to reduce primary load. ADG-specific feature requiring licensing. |
Worked Cost Scenarios — DR Licensing Exposure
| Scenario | Primary Licence Cost | DR Licence Cost | Total DR Exposure | Annual Support (22%) |
|---|---|---|---|---|
| Passive physical standby (mount mode, 16-core) | $380,000 (licensed) | $0 (free — 10-day rule) | $0 | $0 additional |
| Active Data Guard standby (16-core, read-only queries) | $380,000 + $92,000 ADG | $380,000 DB EE + $92,000 ADG | $472,000 | $103,840/year |
| Logical standby (16-core, open for queries) | $380,000 | $380,000 | $380,000 | $83,600/year |
| Snapshot standby used for quarterly testing (16-core) | $380,000 | $380,000 (licensed for testing periods) | $380,000 | $83,600/year |
| VMware cluster DR — standby on 10-host shared cluster (16-core/host) | $380,000 | $3,800,000 (all 80 proc across cluster) | $3,800,000 | $836,000/year |
Database Options and Packs on DR Servers
If your primary database uses licensed Oracle options or management packs, the standby must be licensed for the same options — even if the standby is not actively using those features. Oracle's position is that the standby could use the feature during failover, so it must be licensed proactively. This applies to Active Data Guard standbys and any actively licensed standby; it does not apply to truly passive standbys under the 10-day rule.
| Option / Pack | List Price (per proc) | DR Licensing Rule | Cost on 8-proc DR Server |
|---|---|---|---|
| Diagnostics Pack | $7,500 | Must match primary if standby is actively licensed | $60,000 |
| Tuning Pack | $5,000 | Must match primary | $40,000 |
| Partitioning | $11,500 | Must match primary | $92,000 |
| Advanced Security (TDE) | $15,000 | Must match primary — TDE encrypted data requires the option on standby | $120,000 |
| Active Data Guard | $11,500 | Must be licensed on BOTH primary and standby | $92,000 (standby) + $92,000 (primary) |
| Advanced Compression | $11,500 | Must match primary if compressed data exists on standby | $92,000 |
DR Licensing in Virtualised and Cloud Environments
| Environment | DR Licensing Rule | Practical Impact | Compliance Strategy |
|---|---|---|---|
| VMware / Hyper-V / KVM | All hosts in the cluster must be licensed if the DR VM could migrate; soft partitioning not recognised | DR VM on shared 10-host cluster = all hosts licensed = $3.8M+ for DB EE | Isolate DR VM on dedicated host with affinity rules; keep host powered off until failover if possible |
| Oracle VM (OVM) | Hard partitioning recognised — licence only assigned resources | Significantly cheaper than VMware; Oracle counts only the OVM partition | Use OVM for DR environments where VMware licensing would be prohibitive |
| AWS / Azure / GCP (BYOL) | 2 vCPUs = 1 processor licence; DR instance must be licensed when running | Stopped/deallocated instances not licensable; running instances must be licensed | Keep DR instances stopped until failover; automate startup only during genuine outage |
| Oracle Cloud (OCI) | 1 OCPU = 1 processor licence; BYOL or licence-included | OCI Pilot Light DR patterns can minimise licensing by keeping instances minimal until activation | Use OCI's DR patterns with minimal compute until failover; scale up only during activation |
| Cross-cloud / hybrid DR | On-premises primary + cloud DR (or vice versa); each environment licensed independently | Cloud DR instance must be licensed under cloud BYOL rules even if primary is on-premises | Ensure BYOL licences cover both primary and DR; or use licence-included cloud options |
Common DR Audit Findings
| Audit Finding | How It Occurs | Typical Cost Impact | Prevention Strategy |
|---|---|---|---|
| Read-only queries on physical standby | DBA opens standby read-only for data validation, reporting, or application testing; DBA_FEATURE_USAGE_STATISTICS records ADG usage | $380K–$500K+ (full DB EE + ADG option on standby) | Block all user connections to standby; disable read-only open; restrict DBA access to mount-mode only |
| 10-day rule exceeded | DR activated for multiple outages totalling more than 10 cumulative days; no tracking log maintained | $380K+ (full licensing from day 11 onward — or retroactively for the year) | Maintain formal activation log with timestamps and incident tickets; set alerts at 7 days cumulative |
| DR used for planned maintenance | Production workload moved to standby during patching window; primary still accessible | $380K+ (planned use is not covered by 10-day rule) | Implement zero-downtime patching on primary; never failover to DR for planned maintenance |
| Database options on unlicensed standby | Primary uses Diagnostics Pack, Partitioning, or TDE; standby inherits these features but is not separately licensed | $100K–$500K+ (options × processors on standby) | If standby is actively licensed, ensure all primary options are also licensed on standby |
| VMware DR cluster not isolated | DR VM runs on shared VMware cluster; Oracle requires licensing all hosts | $1M–$5M+ (cluster-wide EE licensing) | Dedicate a host for Oracle DR VMs; use affinity rules; document isolation |
| OEM Diagnostics Pack on standby | Oracle Enterprise Manager configured to monitor standby database; Diagnostics Pack features (AWR, ADDM, ASH) triggered automatically | $60K–$200K+ (Diagnostics Pack licensing on standby) | Exclude standby databases from OEM monitoring; or restrict OEM to basic monitoring without packs |
Audit-Safe DR Architecture Checklist
DR Compliance Disciplines
Maintain strict standby passivity
Ensure all DR standbys remain in mount mode with redo apply only. Block all user connections. Disable read-only open. Do not use standby for reporting, testing, data validation, or any workload. The moment any query runs, licensing is triggered.
Track 10-day rule usage formally
Maintain a formal activation log documenting every day the standby is activated: date, time, duration, incident ticket, confirmation that the primary was genuinely down. Set automated alerts when cumulative usage reaches 7 days. This log is your primary audit defence.
Isolate DR in virtualised environments
If using VMware or similar hypervisors, dedicate a specific host for Oracle DR VMs. Configure affinity rules to prevent migration to other hosts. Consider keeping the DR host powered off until failover. Document the isolation architecture for audit defence.
Audit DBA_FEATURE_USAGE_STATISTICS on standbys
Run DBA_FEATURE_USAGE_STATISTICS on all standby databases quarterly. Check for any Active Data Guard feature usage, Diagnostics Pack triggers, or other option activation. Feature usage is recorded permanently — any historical usage will be found during an Oracle audit.
Restrict OEM monitoring on standbys
Oracle Enterprise Manager automatically enables Diagnostics Pack features (AWR, ADDM, ASH) when monitoring a target database. Either exclude standby databases from OEM monitoring or configure OEM to use basic monitoring only (CONTROL_MANAGEMENT_PACK_ACCESS = NONE on standby).
Document DR architecture and licensing rationale
Maintain a formal document describing your DR architecture, the licensing basis for each standby (10-day rule, actively licensed, or not applicable), and the controls in place to maintain passivity. This document should be available within 48 hours of an Oracle audit notification.