Oracle Database Disaster Recovery Licensing
Oracle Database disaster recovery licensing rules can vary widely depending on how your standby systems operate. It’s crucial to understand these nuances to avoid overpaying or risking non-compliance.
This guide explains the different types of standby setups, clarifies Oracle Data Guard vs. Active Data Guard, and breaks down the “10-day rule.” By the end, you’ll know how to keep your DR environment compliant without overspending.
Read our ultimate Oracle Database Licensing Guide.
Step 1 – Types of Disaster Recovery Environments
Oracle recognizes several types of DR deployment setups, and each one has different licensing implications.
Checklist: DR Deployment Types
- ✔ Cold standby
- ✔ Warm standby
- ✔ Data Guard physical standby
- ✔ Data Guard logical standby
- ✔ Snapshot standby
At a high level, here’s how these DR types differ in terms of activity and licensing:
| DR Type | Activity Level | Licensing Requirement |
|---|---|---|
| Cold Standby | Offline | Covered by 10-day rule |
| Warm Standby | Periodically opened | Usually requires full license |
| Physical Standby | Synced, passive | 10-day rule applies |
| Logical Standby | Queryable (open for read) | Requires additional licensing |
| Snapshot Standby | Updatable temporarily | Licensable (treated as active use) |
Activity level determines licensing — not the label.
Step 2 – Oracle’s 10-Day Rule Explained
Oracle’s “10-day rule” allows a standby database to take over for the primary for up to 10 days per year without requiring additional licenses. It only applies if the standby is normally passive and you activate it during a true outage (with the primary down). It doesn’t cover any routine testing, maintenance, or reporting.
Checklist: 10-Day Rule Requirements
- ✔ DR environment must be normally passive
- ✔ Primary must be down during DR activation
- ✔ Days are cumulative across the year
- ✔ Does not apply to testing, patching, or reporting
To clarify how it works, here are some scenarios and whether the 10-day rule covers them:
| Scenario | Licensed? | Notes |
|---|---|---|
| DR activated for real outage | No | Uses 10-day allowance (emergency failover) |
| DR activated for maintenance | Yes | Planned use counts as normal usage (not emergency) |
| DR used for testing | Yes | Not covered (requires license) |
| DR used for reporting | Yes | Considered production use (license required) |
The 10-day rule is generous — but extremely narrow.
Step 3 – Licensing Passive Standby Environments
A passive standby server stays completely idle until a failover occurs.
Checklist: Passive Standby Conditions
- ✔ Database is not open for queries
- ✔ No read/write activity by applications
- ✔ Not used for any reporting or BI jobs
- ✔ Not used for development or QA testing
- ✔ Only redo apply (log shipping) in progress
In general, any normal workload on the standby counts as active use and triggers a license requirement. Here are some common standby activities and whether they require a license:
| Activity | Considered “Use”? | Licensing Needed? |
|---|---|---|
| Redo apply (log shipping) | No | Covered under primary license |
| DR health checks | No | Covered |
| Querying the standby | Yes | Requires license |
| Opening the standby for QA | Yes | Requires license |
Passive standby is the only path to free DR capacity.
Step 4 – Licensing Data Guard Environments
Oracle Data Guard is a feature that keeps a standby database synchronized with the primary in near real-time. It’s included with Oracle Database Enterprise Edition at no extra cost, but licensing still depends on how you use the standby.
Checklist: Standard Data Guard Licensing Rules
- ✔ Physical standby is passive by default (no user queries running).
- ✔ Logical standby can be opened for queries — which means it requires full licensing.
- ✔ Snapshot standby is temporarily updatable — so it requires licensing when in use.
- ✔ Failovers of a passive standby count toward the 10-day rule allowance.
Here’s how Oracle licensing applies to different Data Guard setups:
| Data Guard Type | Standby Activity | Licensing Required? |
|---|---|---|
| Physical Standby | Passive (redo apply only) | No (unless used > 10 days total) |
| Logical Standby | Open for read/query | Yes (full license needed) |
| Snapshot Standby | Open for write (testing) | Yes (license needed when writable) |
| Switchover | Short-term role swap | No (temporary switch is covered) |
Data Guard is free — but the standby activity is not.
Step 5 – Licensing Active Data Guard
Active Data Guard (ADG) is an optional paid add-on that extends Data Guard. It allows a standby database to be open read-only for queries while still applying changes from the primary in real-time. Because ADG is a separately licensed option, strict rules apply to using it.
Checklist: Active Data Guard Requirements
- ✔ Must license all standby processors (or all named users) for Active Data Guard.
- ✔ Standby must use the same license metric as the primary (processor vs. NUP count).
- ✔ Read-only reporting still requires full licensing (the standby isn’t free just because it’s read-only).
- ✔ Cannot mix ADG and a free standby approach – if ADG is enabled, that standby needs full licensing.
For example, here are some Active Data Guard capabilities and whether they trigger the need for the ADG license:
| Feature or Action | Requires License? | Why |
|---|---|---|
| Read-only queries on standby | Yes | Considered workload on standby |
| Automatic block repair | Yes | ADG-only feature (requires ADG option) |
| Real-time apply with query | Yes | Uses standby CPU resources (active use) |
| Normal switchover/failover | No | Covered by base DB licensing |
The moment you query the standby, licensing changes completely.
Step 6 – Licensing DR in Virtualized and Cloud Environments
Virtualized and cloud DR setups introduce additional licensing complexity. Oracle’s policies on counting processors in VMs or cloud instances can lead to unexpected costs if you’re not careful.
Checklist: DR Cloud/VM Considerations
- ✔ Standby VMs require licensing unless kept truly passive (powered off until failover).
- ✔ Oracle doesn’t accept most VM CPU limits as a licensing boundary (soft partitioning).
- ✔ In AWS and Azure, Oracle counts 2 vCPUs as equivalent to 1 processor license.
- ✔ In Oracle Cloud (OCI), 1 OCPU is treated as 1 processor license (a more favorable ratio for customers).
Cloud does not simplify DR licensing — it amplifies mistakes.
Step 7 – How Options and Packs Affect DR Licensing
When it comes to database add-ons (options and management packs), Oracle requires the same licensing on the standby as on the primary. If your production database uses a paid option or pack, the DR environment needs to be licensed for that same feature as well. This holds true even if the standby isn’t actively using that feature. Oracle assumes the standby could use the feature, so it needs to be fully licensed to be compliant.
Checklist: Options That Must Be Licensed on DR (if used on primary)
- ✔ Diagnostics Pack
- ✔ Tuning Pack
- ✔ Partitioning
- ✔ Advanced Security
Options multiply cost across primary and standby equally.
Read about licensing in the cloud, Oracle Database Licensing in Cloud Environments.
Step 8 – Designing an Audit-Safe DR Licensing Strategy
The best way to avoid surprises in an Oracle audit is to design your DR architecture with Oracle’s license rules in mind. A few precautionary steps can save you huge headaches and bills later. Make sure your standby remains a truly passive backup unless you intentionally license it for more.
Checklist: Compliance Best Practices
- ✔ Document the DR architecture and roles of each server clearly.
- ✔ Log every DR activation day (keep track of each day the standby was used).
- ✔ Disable any user queries or application access on the passive standby.
- ✔ Restrict Oracle Enterprise Manager (OEM) monitoring on the standby to avoid pack usage.
- ✔ Monitor Data Guard settings regularly to ensure the standby remains passive.
- ✔ In virtualized setups, use hard partitioning or dedicated hosts to isolate DR CPU resources.
For example, here are some best practices and how they help ensure compliance:
| Action | Benefit | Risk Avoided |
|---|---|---|
| Restrict standby access | Prevents accidental query use | Avoids triggering ADG licensing |
| Keep activity logs | Provides proof for 10-day rule | Prevents disputes in audits |
| Disable OEM pages/features | Stops unintended pack usage | Avoids unlicensed option usage |
| Align license metrics | Ensures standby matches primary | Prevents audit penalties for mismatch |
Most DR audit issues come from unintentional use — not intentional misuse.
5 Expert Takeaways
- The 10-day rule is powerful — but narrow.
- Any query, reporting, or testing on DR requires full licensing.
- Active Data Guard is expensive — understand when it’s truly needed.
- Cloud DR deployments must use cloud-specific CPU conversion rules.
- Audit-safe DR architecture depends on strict access and activity control.
The safest DR plan is one that matches Oracle’s licensing logic — not assumptions..
Read about our Oracle license management services
