Oracle Active Data Guard (ADG) Licensing: The Definitive Guide for CIOs and IT Leaders

Data Guard vs Active Data Guard: The Critical Licensing Distinction

Oracle's Data Guard technology provides automated replication of a primary Oracle Database to one or more standby databases for disaster recovery and high availability purposes. Oracle Data Guard in its basic form — physical standby database in mount state with redo apply running — is included at no additional cost with Oracle Database Enterprise Edition. This is one of the most valuable no-cost capabilities in the Oracle Database platform.

Oracle Active Data Guard (ADG) extends standard Data Guard by allowing the standby database to remain open for read-only access while simultaneously applying redo from the primary. ADG is the point at which the no-cost benefit ends and a separately licensed, paid Oracle Database option begins. ADG carries a list price of $11,500 per processor (perpetual licence), with annual support charged at 22% of the net licence value, increasing at 8% per year under Oracle's standard terms.

The boundary between free Data Guard and paid Active Data Guard is defined by a single operational state: whether the standby database is open for read-only access while redo apply is in progress. If redo apply is stopped and then the standby is opened in read-only mode for a specific purpose — such as a backup or a point-in-time query — that is standard Data Guard. If the standby is open in read-only mode while it is simultaneously receiving and applying redo from the primary, that is Active Data Guard, and a licence is required.

Features That Require an Active Data Guard Licence

Oracle has a defined list of features and operational states that require an ADG licence. Understanding this list is essential for any organisation operating a Data Guard environment, because several features are enabled by default in some Oracle database versions and patch sets.

Real-Time Query

Real-Time Query is the primary ADG feature and the one most organisations understand as the ADG licence trigger. It allows users and applications to execute read-only queries against the standby database while redo apply continues to keep the standby synchronised with the primary. This is the reporting offload and read scalability use case — offloading SELECT-intensive workloads from the primary to the standby to reduce primary load.

Automatic Block Repair

Automatic Block Repair automatically detects and repairs data block corruption in the primary database by fetching the uncorrupted block from the standby. This feature requires ADG licensing because it involves the standby actively participating in primary database operations, not just passively receiving redo. Many organisations enable Automatic Block Repair as part of their Data Guard configuration best practice without realising it requires ADG licensing.

Far Sync

Oracle Data Guard Far Sync allows zero-data-loss data protection to remote standby databases without the latency penalty of synchronous redo shipping directly to the remote standby. A Far Sync instance — a lightweight Oracle instance that receives redo synchronously from the primary and then ships asynchronously to remote standbys — requires an ADG licence for each Far Sync instance deployed.

DML Redirection

DML Redirection allows read-mostly applications to execute DML (INSERT, UPDATE, DELETE) statements against the standby database. The ADG layer redirects those DML operations transparently to the primary database and reflects the results on the standby. DML Redirection requires ADG licensing and is available from Oracle Database 19c onward.

Active Standby for In-Memory Population

From Oracle Database 12c Release 2 onward, the standby database can populate its In-Memory column store with data from the primary — providing analytics acceleration on the standby using the In-Memory option. Using the In-Memory feature on the standby requires both the In-Memory option licence and the ADG licence.

When ADG Is Not Required

A number of Data Guard operational scenarios do not require an ADG licence. Understanding these clearly is important for designing compliant DR architectures that minimise licence cost.

Physical Standby in Mount State

A physical standby database that remains in mount state — receiving and applying redo from the primary without being opened for user access — does not require an ADG licence. This is the standard Data Guard configuration for pure DR purposes, and it provides the same data protection and automatic failover capability as ADG for environments that do not need to read from the standby.

Snapshot Standby

A snapshot standby database — temporarily converted from a physical standby to an updateable database for testing or development purposes by stopping redo apply and opening the database read-write — does not require ADG licensing, because redo apply is not running while the database is open. The standby is converted back to a physical standby after testing by discarding the snapshot and resuming redo apply.

Opening Standby Read-Only with Redo Apply Stopped

Opening the standby in read-only mode after stopping redo apply — for example, to run a specific query against a point-in-time snapshot of the data — does not trigger the ADG licence requirement, because the standby is not simultaneously applying redo and serving queries. The standby is a static read-only database during this period, which is standard Data Guard functionality.

ADG Licence Cost Structure

Oracle Active Data Guard is licensed as an Oracle Database Enterprise Edition option. Its list price is $11,500 per processor (perpetual licence). The processor definition follows Oracle's standard core factor methodology: the number of physical CPU cores on the server multiplied by Oracle's core factor for that processor architecture (0.5 for most Intel and AMD x86 processors).

Primary and Standby Both Require Licensing

This is the most important and most frequently misunderstood aspect of ADG licensing: Oracle requires the ADG option to be licensed on both the primary database server and every standby database server involved in the Active Data Guard configuration. The primary database participates actively in ADG operations — it coordinates redo shipping, supports Automatic Block Repair queries from the standby, and handles DML Redirection from active standbys. Oracle's policy is that the primary requires the ADG option licence regardless of whether users are directly accessing the primary for ADG-specific features.

For a typical single-primary, single-standby ADG configuration where both servers have four Intel processor cores (two licensed processors each after the 0.5 core factor), the ADG licence requirement covers four processors in total — two for the primary and two for the standby. At $11,500 per processor, the list price for the perpetual licence is $46,000, with annual support of approximately $10,120 per year at 22% of licence value, increasing at 8% per year.

Named User Plus Minimum

If the Oracle Database Enterprise Edition is licensed using Named User Plus (NUP) metric, the ADG option must also be licensed using NUP. Oracle's minimum NUP count for Oracle Database Enterprise Edition and all its options is 25 named users per processor. For a configuration covering four processors, the minimum NUP requirement is 100 named users for both the database and the ADG option. Even if the actual user population is significantly smaller, the minimum applies.

Discounts in Enterprise Deals

Oracle database options — including ADG — are routinely included in enterprise database negotiations and ULA discussions. Organisations purchasing significant Oracle Database Enterprise Edition footprint, or those certifying out of a ULA that includes Oracle Database, frequently negotiate ADG licensing as part of the broader deal at discounts of 50 to 70% off list price. The key condition is that ADG must be explicitly named in the agreement — it is not automatically included in a general Oracle Database EE licence or ULA unless specifically added.

How Oracle Detects Unlicensed ADG Usage in Audits

Oracle's LMS (License Management Services) audit scripts collect detailed information about Oracle Database configuration and feature usage. For ADG specifically, the audit scripts identify the database open mode (whether the standby is open for read-only access), the redo apply state (whether MRP — managed recovery process — is running while the database is open), and the history of ADG feature usage through Oracle's Automatic Workload Repository (AWR) and feature usage statistics.

Oracle databases track feature usage internally. Every time an ADG-licensed feature is invoked — a query against an open standby, an Automatic Block Repair event, a Far Sync instance receiving redo — the usage is recorded in the database data dictionary. Oracle's audit scripts read this usage history and produce a report of all features that have been used in the audit period, typically the last 12 months.

An organisation that has been using ADG features without a licence for 12 months of the audit period faces a retroactive licence obligation for that entire period — not just from the point the audit was initiated. The retroactive assessment covers the full audit window, typically back to the start of the applicable licence period. This is why ADG exposure discovered in an Oracle audit is frequently larger than expected: a single year of unlicensed ADG usage on a four-processor configuration can produce a claim of $46,000 in retroactive licence fees plus one year of support at $10,120, before any audit settlement premiums.

Compliance Strategies for Data Guard Environments

Audit Your Current Data Guard Configuration

The starting point for ADG compliance management is an accurate assessment of how your Data Guard standbys are currently configured and used. Query the V$DATABASE view to confirm the database open mode of each standby (MOUNTED vs READ ONLY), query V$MANAGED_STANDBY to confirm whether MRP is running, and review DBA_FEATURE_USAGE_STATISTICS for the ADG features tracked in the database data dictionary.

Remediate Inadvertent ADG Usage

If the audit reveals that ADG features have been used without a licence, the organisation has two remediation paths: procure the ADG licence retroactively, or configure the Data Guard environment to eliminate the unlicensed usage going forward. The second path requires stopping redo apply before opening the standby for any read access, disabling Automatic Block Repair, and removing any Far Sync instances that are in use without ADG licensing.

Both paths should be implemented immediately once unlicensed usage is identified. Oracle's audit teams give credit for self-disclosure and remediation in their settlement discussions. Continued unlicensed usage after identification significantly worsens the settlement outcome.

Include ADG in ULA and Database Negotiations

Organisations with Oracle Database ULA or PULA agreements should review whether Active Data Guard is included in the unlimited licence scope. If it is, every ADG deployment under the ULA carries no incremental licence cost during the unlimited period, and the certification count at ULA exit reflects the full ADG deployment. If ADG is not in the ULA scope, every standby deployment using ADG features creates a separate paid option licence requirement outside the ULA.

When negotiating Oracle Database agreements — ULA, PULA, or standard perpetual licences — explicitly include ADG in the licence scope if you operate or plan to operate read-active standbys. The incremental cost of adding ADG to a large Oracle Database deal is significantly lower than purchasing ADG separately later, and a ULA that includes ADG eliminates all per-deployment counting concerns during the ULA term.

Common ADG Licensing Mistakes

Opening the standby for DBA health checks: DBAs routinely open standby databases briefly to check replication health, review alert logs, or validate synchronisation. Each of these opens — even brief ones — triggers ADG licensing requirements if MRP is running. Establish operational procedures that stop MRP before opening the standby for any purpose.

Enabling Automatic Block Repair without awareness of the licence requirement: Automatic Block Repair is presented in Oracle documentation as a Data Guard best practice and is sometimes enabled by default in Data Guard configuration tooling. Review whether it is enabled in your environment and ensure ADG licensing is in place if it is.

Far Sync deployments without ADG licence: Far Sync instances are deployed by Oracle architects as a zero-data-loss solution for remote DR sites. Each Far Sync instance requires an ADG licence. Organisations that deploy Far Sync as a pure replication relay without understanding the licence requirement create hidden compliance exposure.

Assuming ADG is included in Oracle Database EE licensing: ADG is an option, not a feature, of Oracle Database Enterprise Edition. Enterprise Edition provides the base database and a number of no-cost features. ADG is not one of them — it requires separate, paid option licensing. Never assume inclusion without verifying the specific licence entitlement.

Not licensing the primary in an ADG configuration: Many organisations licence only the standby for ADG, reasoning that ADG functionality is used on the standby side. Oracle's policy is unambiguous: both primary and standby require ADG option licensing. Licensing only the standby produces an immediate under-licence position for the primary.