An independent advisory on how Oracle licences disaster recovery and failover environments — the 10-day rule, Data Guard, Active Data Guard, virtualised DR, and how to design an audit-safe standby architecture without overspending.
Disaster recovery is a non-negotiable requirement for any enterprise running Oracle Database in production. But Oracle's licensing rules for standby and failover environments are among the most misunderstood areas in the entire Oracle licensing landscape — and among the most expensive when misinterpreted.
The core challenge is deceptively simple: activity level determines licensing, not the label you put on the server. Calling a server "DR" or "standby" does not exempt it from licensing. The moment any workload runs on that server — queries, reports, testing, or even certain monitoring activities — Oracle considers it an active deployment that requires full licensing.
Oracle's DR licensing rules can vary widely depending on how your standby systems operate. Understanding these nuances is crucial to avoid overpaying or risking non-compliance. This guide explains the different types of standby setups, clarifies Oracle Data Guard versus Active Data Guard, breaks down the "10-day rule," and shows how to keep your DR environment compliant without overspending.
For the complete picture on Oracle database licensing fundamentals, read our Oracle Database Licensing Guide.
"The most common DR licensing mistake we encounter is the assumption that a standby database is automatically free. It is not. Oracle's rules are precise — and their audit scripts are designed to detect every second of active use on your standby systems."
— Fredrik Filipsson, Co-Founder, Redress ComplianceOracle recognises several types of DR deployment setups, and each one has different licensing implications. Understanding which category your standby falls into is the first step toward compliance.
| DR Type | Activity Level | Licensing Requirement | Use Case |
|---|---|---|---|
| Cold Standby | Offline — powered off or dormant | Covered by 10-day rule | Lowest-cost DR; manual failover |
| Warm Standby | Periodically opened for data refresh | Usually requires full licence | Faster recovery; some data lag |
| Physical Standby (Data Guard) | Synced via redo apply; passive | 10-day rule applies if truly passive | Near-zero data loss; automatic failover |
| Logical Standby (Data Guard) | Open for read — queryable | Requires full licence | Reporting offload; data transformation |
| Snapshot Standby | Temporarily open for read/write | Requires licence when writable | Testing patches or changes on real data |
Critical principle: Activity level determines licensing — not the label. A server you call "DR" but use for quarterly reporting is a production server in Oracle's eyes and must be fully licensed.
Oracle's "10-day rule" is one of the most frequently cited — and most frequently misapplied — provisions in Oracle licensing. It allows a standby database to take over for the primary for up to 10 days per calendar year without requiring additional licences. But the conditions are strict.
| Requirement | Detail |
|---|---|
| Normally passive | The DR environment must be idle under normal operations — no queries, no reporting, no testing |
| Primary must be down | The standby can only be activated during a genuine outage when the primary is unavailable |
| Days are cumulative | All activation days across the year count toward the 10-day total — they do not reset per incident |
| Emergency only | Does not cover planned maintenance, patching windows, or routine testing |
| Scenario | Requires Licence? | Why |
|---|---|---|
| DR activated during a genuine production outage | No | Uses 10-day emergency failover allowance |
| DR activated for planned maintenance on primary | Yes | Planned use is not an emergency — counts as normal usage |
| DR used for annual DR testing / fire drill | Yes | Testing is not covered by the 10-day rule |
| DR used to offload month-end reporting | Yes | Any reporting is considered production use |
| Passive standby applying redo logs only | No | Redo apply alone does not constitute "use" |
"The 10-day rule is powerful — but its scope is extremely narrow. We see organisations routinely exceed it without realising, particularly when they use the standby for DR testing or roll over to it during planned maintenance windows. Every activation day must be documented."
— Fredrik Filipsson, Co-Founder, Redress ComplianceDR licensing is one of the top areas Oracle auditors target. Download our guide to discover the compliance traps Oracle is trained to find — and how to close them before they become costly.
Download Free →A passive standby server stays completely idle until a failover occurs. This is the only configuration that can operate without additional Oracle licences (subject to the 10-day rule). But the definition of "passive" is strict.
| Activity | Considered "Use"? | Licensing Needed? |
|---|---|---|
| Redo apply (log shipping) | No | Covered under primary licence |
| Automated DR health checks | No | Covered — monitoring infrastructure, not querying data |
| Querying the standby database | Yes | Requires full licence |
| Opening standby for QA or dev testing | Yes | Requires full licence |
| Running reports against the standby | Yes | Requires full licence |
| Using Oracle Enterprise Manager packs on standby | Yes | Requires pack licensing on the standby |
Common trap: Running Oracle Enterprise Manager (OEM) Diagnostics Pack or Tuning Pack against the standby — even for monitoring purposes — constitutes use of those licensed options and requires licensing on the standby servers. Restrict OEM monitoring to basic metrics only.
In practice, maintaining a truly passive standby requires operational discipline. Your DBAs must understand that any normal workload on the standby — no matter how brief — triggers a licensing obligation. This is why clear access controls and documentation are essential.
Oracle Data Guard is a feature included with Oracle Database Enterprise Edition at no extra licence cost. It keeps a standby database synchronised with the primary in near real-time using redo log shipping and apply. However, while Data Guard itself is free, the licensing of the standby database depends entirely on how that standby is used.
| Data Guard Configuration | Standby Activity | Licensing Required? | Notes |
|---|---|---|---|
| Physical Standby | Passive — redo apply only | No (10-day rule applies) | The only free DR path. Database is mounted but not open for queries |
| Logical Standby | Open for read — queryable | Yes — full licence | SQL apply reconstructs transactions; standby is open for reporting |
| Snapshot Standby | Open for read/write temporarily | Yes — licence needed when writable | Useful for testing but triggers full licensing during writable window |
| Switchover | Planned role swap between primary and standby | Covered if within 10-day limit | Short-term role reversal for maintenance; must document carefully |
| Failover | Emergency promotion of standby to primary | Covered under 10-day rule | Counts against annual 10-day allowance |
The key distinction: Data Guard is free — but the standby activity is not. Physical standby with redo apply only is the sole configuration that avoids additional licence costs. The moment the standby is opened for any purpose — queries, reporting, testing — it becomes a licensable deployment.
For detailed guidance on Oracle's official Data Guard documentation, see Oracle Data Guard on oracle.com.
A North American insurance company maintained a Data Guard physical standby for DR purposes. During an audit, Oracle's LMS scripts detected that the standby had been opened for read-only queries by the BI team for two hours every month-end. Despite the limited duration, Oracle classified this as Active Data Guard usage, generating a $1.2M compliance claim for unlicensed ADG processors across the standby cluster.
Active Data Guard (ADG) is an optional paid add-on to Oracle Database Enterprise Edition. It extends standard Data Guard by allowing the standby database to be open read-only for queries while simultaneously applying redo from the primary. This is powerful for offloading reporting workloads — but it comes at a significant licensing cost.
| Requirement | Detail |
|---|---|
| Licence the standby processors | All processor cores (or all Named Users) on the standby servers must be licensed for ADG |
| Match the primary metric | The standby must use the same licence metric as the primary (Processor or NUP) |
| Read-only is not free | Even read-only reporting on the standby requires full ADG licensing |
| No mixing | You cannot use ADG on some standbys and claim the 10-day rule on others for the same database |
| Feature or Action | Requires ADG Licence? | Why |
|---|---|---|
| Read-only queries on standby | Yes | Workload on standby = active use |
| Automatic block repair | Yes | ADG-exclusive feature |
| Real-time apply with concurrent queries | Yes | Uses standby CPU resources for queries |
| Far Sync instance | Yes | ADG feature for zero data loss over WAN |
| Normal switchover or failover only | No | Covered by base DB licensing and 10-day rule |
"Active Data Guard is one of the most expensive Oracle options that organisations enable without fully understanding the cost implications. At list price, ADG costs $11,500 per processor — and it must be licensed on every core of the standby. For a 32-core standby (16 licences at 0.5 core factor), that is $184,000 in ADG licences alone, on top of the base database licensing."
— Fredrik Filipsson, Co-Founder, Redress ComplianceOracle auditors specifically look for Active Data Guard usage on standbys labelled as "passive." Learn how to structure your DR architecture to withstand audit scrutiny.
Download Free →Virtualised 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 not planned carefully.
| Environment | Licensing Rule | DR Impact |
|---|---|---|
| VMware / Hyper-V (Soft Partitioning) | Oracle requires licensing all physical cores in the entire cluster — not just the VM | A standby VM in a shared cluster could require licensing every host in the cluster |
| Oracle VM (Hard Partitioning) | Only the cores pinned to the Oracle VM need licensing | Allows cost-effective DR by limiting licensable cores to the VM boundary |
| AWS / Azure / GCP | 2 vCPUs = 1 processor licence (with hyper-threading). Core Factor Table does not apply | Cloud DR instances must be licensed when running — even if only used during failover |
| Oracle Cloud (OCI) | 1 OCPU = 1 processor licence; Support Rewards may offset costs | Most favourable DR licensing ratio; BYOL friendly |
VMware trap: If your Oracle DR standby runs as a VM within a VMware or Hyper-V cluster, Oracle may claim you must licence every physical core across every host in that cluster — even if the standby VM is currently powered off but could migrate. Isolating Oracle DR on dedicated hosts or using Oracle-approved hard partitioning is the safest approach.
For cloud DR architectures, the key question is whether the standby instance is running and consuming cloud resources. A powered-off cloud instance does not require licensing, but the moment it boots — even for a failover test — it becomes licensable. Cloud providers make it easy to spin up DR instances on demand, but Oracle's licensing clock starts ticking the moment the instance is active.
One of the most costly surprises in Oracle DR licensing is the requirement to licence every option and pack on the standby that is licensed on the primary. Oracle requires the same licensing coverage on the standby as on the production database — even if the standby is not actively using those features.
| Option / Pack | List Price per Processor | DR Licensing Requirement |
|---|---|---|
| Diagnostics Pack | $7,500 | Must be licensed on standby if licensed on primary |
| Tuning Pack | $5,000 | Must be licensed on standby if licensed on primary |
| Partitioning | $11,500 | Must be licensed on standby if any partitioned tables exist |
| Advanced Security (TDE) | $15,000 | Must be licensed if encryption is applied to the data |
| Active Data Guard | $11,500 | Required whenever the standby is opened for read queries |
| Real Application Clusters (RAC) | $23,000 | Required if the standby uses RAC for high availability |
The financial impact is significant. Consider a production database running on a 16-core server (8 processor licences at 0.5 core factor) with Diagnostics Pack, Tuning Pack, and Partitioning enabled. The standby must mirror those licences exactly — adding $192,000 in option licensing alone (8 × $24,000 across three options), on top of the base database licence cost.
"Options and packs are the hidden cost multiplier in DR licensing. We routinely find that organisations have enabled Diagnostics Pack or Tuning Pack on their standby databases through Oracle Enterprise Manager — sometimes unknowingly — and are sitting on six-figure compliance exposures they don't even know about."
— Fredrik Filipsson, Co-Founder, Redress ComplianceA global logistics company faced an Oracle audit that identified unlicensed Diagnostics Pack and Partitioning usage across three standby databases in a VMware environment. Oracle's initial claim was $3.8M. By engaging independent advisors to challenge the VMware cluster scope, demonstrate that Diagnostics Pack had been inadvertently enabled via OEM (not actively used for tuning), and negotiate a compliance resolution, the company settled for $420K in additional licences.
A practical framework for identifying hidden licensing costs — including DR option sprawl — and building governance to prevent them from recurring.
Download Free →The best way to avoid surprises in an Oracle audit is to design your DR architecture with Oracle's licence rules built in from the start. Most DR audit findings stem from unintentional use — not deliberate non-compliance.
| Action | Benefit | Risk Avoided |
|---|---|---|
| Restrict standby access | Prevents accidental query use by BI teams or developers | Avoids triggering ADG licensing obligation |
| Keep activation logs | Provides documented proof for the 10-day rule | Prevents disputes during audits about how many days the standby was active |
| Disable OEM packs on standby | Stops unintended Diagnostics/Tuning Pack usage | Avoids unlicensed option usage on standby |
| Align licence metrics | Ensures standby uses same metric (Processor or NUP) as primary | Prevents audit penalties for metric mismatch |
| Isolate Oracle DR on dedicated hosts | Limits licensable cores to the physical boundary of the DR server | Avoids full-cluster licensing in virtualised environments |
| Document DR architecture | Clear records of server roles, Data Guard configuration, and access controls | Enables rapid, confident response when Oracle's LMS scripts are deployed |
When designing or reviewing your Oracle DR setup, use this decision logic to determine your licensing obligation:
| Question | If Yes | If No |
|---|---|---|
| Is the standby ever opened for queries? | Licence for Active Data Guard + full DB EE | Continue to next question |
| Is the standby ever used for testing or QA? | Licence the standby fully for the duration of use | Continue to next question |
| Is the standby in a VMware/Hyper-V cluster with other VMs? | Consider isolating on dedicated hosts or licensing full cluster | Continue to next question |
| Are any database options or packs enabled on the primary? | Those same options must be licensed on the standby | Standby may qualify under 10-day rule |
| Is failover activation documented and within 10 days/year? | No additional licence required (passive DR) | Full licensing is needed |
A European bank was licensing Active Data Guard across four standby databases — costing over $890K annually in support fees alone. An independent licensing review determined that only one database genuinely required read-only standby queries for regulatory reporting. The other three were rearchitected as passive physical standbys with strict access controls, eliminating the ADG licensing requirement and saving $890K per year in ongoing support costs.
Our independent Oracle licensing advisors can review your entire DR architecture, identify compliance gaps and cost-saving opportunities, and build an audit-safe licensing position — without Oracle knowing.
Free, independent research to help you manage Oracle licensing risks and costs.
Full licence reconciliation, compliance assessment, and optimisation — including DR licensing reviews.
Learn More →Expert-led audit response — scope management, findings challenge, and negotiation support.
Learn More →Independent negotiation advisory for renewals, new purchases, ULAs, and DR licensing provisions.
Learn More →