Oracle Active Data Guard Licensing Explained

What Is Oracle Active Data Guard?

Data Guard itself is Oracle's disaster-recovery technology: it maintains one or more standby databases as transactionally consistent copies of a production primary, shipping and applying redo so the standby can take over if the primary fails. That core capability — including physical and logical standbys, redo transport, and switchover and failover — is part of Enterprise Edition at no additional license cost. It is one of the genuinely free, genuinely valuable features of EE.

Active Data Guard is the paid layer on top. Its headline feature is real-time query: instead of leaving the standby mounted and idle, you open it read-only and use it for reporting, backups, and read offload while redo apply keeps it current to within seconds of the primary. That turns a passive insurance policy into a working second copy of the database — which is exactly why Oracle charges for it as an option. For the broader standby picture, see our Oracle Data Guard licensing guide; this article focuses specifically on the Active Data Guard option and what switches it on.

Active Data Guard vs Basic Data Guard: Where's the Line?

The distinction is precise and worth memorising, because it is the difference between $0 and an option list-priced per processor on both sides. The table below maps the capabilities to the license requirement.

One nuance trips up even experienced DBAs: you may open a physical standby read-only with redo apply stopped on basic Data Guard, but that means the standby falls behind and stops being a real-time copy. The moment you open it read-only and keep apply running, you are using real-time query — and that is Active Data Guard. The convenience that makes the feature worth using is precisely the act that licenses it.

What Triggers the Active Data Guard License?

Most accidental usage comes from real-time query, but the option has several independent triggers, and any one of them is sufficient on its own:

• Real-time query reporting: a DBA or BI team opens the standby read-only "just for reports" while apply continues. Recorded immediately.
• Far Sync: deploying a Far Sync instance for zero-data-loss protection over distance requires Active Data Guard, regardless of whether the standby is ever opened read-only.
• Automatic block media recovery: when the primary automatically repairs a corrupt block from the standby, the feature in use is an Active Data Guard feature.
• Standby block change tracking: offloading fast incremental RMAN backups to the standby uses block change tracking on the standby, which is an Active Data Guard capability.
• DML redirection: from Oracle 19c, allowing limited DML on the open standby (redirected to the primary) is an Active Data Guard feature.

Because these triggers are technical and silent, they are routinely flipped on during proofs of concept, upgrade testing, or a single afternoon of reporting experiments — and never turned off in the feature-usage record. This is the same accidental-option pattern we document for the Partitioning option and the Diagnostics and Tuning Packs. Our license optimization service maps every option trigger across the estate before Oracle measures it.

How Much Does Active Data Guard Cost in 2026?

Active Data Guard is licensed on the same metric — Processor or Named User Plus — as the underlying Enterprise Edition database, and on the same number of processors. Processor counts are derived using the Oracle Core Factor Table: physical cores multiplied by the applicable core factor (typically 0.5 for x86). The table below shows how the per-processor list price compounds once the option is licensed on both primary and standby.

Back-license claims run from the first date the feature usage was recorded, with Oracle adding its standard 22% annual support uplift. A standby opened read-only three years ago for a reporting trial can therefore anchor a three-year claim across both sides of the configuration. Our audit defense team challenges both the scope and the first-use date on exactly these claims.

Do You License Active Data Guard on Both Primary and Standby?

This two-sided rule is where buyers most often underestimate the cost. A standby database always needs its own Enterprise Edition license — the often-misremembered "10-day rule" applies only to a passive failover node taken over for a limited number of days per year, not to an actively used standby. An Active Data Guard standby is, by definition, actively used, so it carries full EE licensing plus the ADG option, and the primary carries the ADG option too. The option is symmetric: both ends of the relationship that uses the feature must be licensed.

How Does Oracle LMS Detect Active Data Guard Usage?

Active Data Guard leaves an unambiguous trail. Oracle's feature-usage tracking writes a row to DBA_FEATURE_USAGE_STATISTICS the first time real-time query or another ADG feature is exercised, capturing the feature name, a usage count, and crucially the FIRST_USAGE_DATE and LAST_USAGE_DATE. Because that record persists even after you stop using the feature, a single test from years ago is still visible to an LMS scan today.

-- Active Data Guard feature usage on the primary
SELECT name, version, detected_usages,
       first_usage_date, last_usage_date
FROM   dba_feature_usage_statistics
WHERE  name LIKE 'Active Data Guard%'
   OR  name LIKE '%Real-Time Query%'
ORDER  BY first_usage_date;

-- Standby open mode (read-only with apply = real-time query)
SELECT database_role, open_mode FROM v$database;

The auditor cross-checks the feature-usage record against the standby's open mode and the Data Guard broker configuration. A standby reporting READ ONLY WITH APPLY, combined with a real-time query row in feature usage, is a closed case on the technical facts. The defensible questions are about scope, processor count, and the accuracy of the first-use date — not whether the feature was ever used. For what you are and are not obliged to disclose, see our note on handling option-usage data in an audit.

How Do You Defend an Active Data Guard Claim?

Even when ADG usage is real, the claim is frequently inflated and challengeable on several fronts:

• Scope challenge: LMS scripts often sweep databases outside the contractual audit scope — decommissioned, non-production, or out-of-territory standbys. Narrowing scope is the first reduction lever.
• Processor recount: ADG claims inherit any base EE overcount. Misapplied core factors, counted hyperthreads, or powered-off hosts inflate both the EE and the ADG figure; a forensic recount reduces both.
• First-use date: DBA_FEATURE_USAGE_STATISTICS dates reset when a database is re-created, cloned, or rebuilt, and Data Pump imports do not preserve original timestamps. A defensible first-use date can shorten the back-license window materially.
• Remediation to basic Data Guard: closing the standby (mounted, apply running, not open read-only) and disabling Far Sync, block change tracking, and DML redirection returns the configuration to free Data Guard. Done before measurement, it eliminates current exposure; done after an audit letter, it limits future liability.

One large manufacturer we advised faced an Active Data Guard claim spanning four standbys; a combined scope, processor, and first-use challenge removed two out-of-scope standbys and reset the back-license clock, cutting the claim by more than half. See our case studies for how these defenses play out and what they settle for.