Oracle Database Licensing · High Availability & DR

Oracle Data Guard and Active Data Guard Licensing: The Included-vs-Paid Line That Oracle's LMS Team Exploits

Oracle Data Guard — the technology that keeps a standby database synchronised with a primary database for disaster recovery and failover — is included in Oracle Database Enterprise Edition at no additional cost. Oracle Active Data Guard — which adds the capability to query that standby database while it is in managed recovery mode, and use it for reporting, backups, and rolling upgrades — is a separately licensed option at $23,000 per processor. The compliance trap is that the line between "included Data Guard" and "licensed Active Data Guard" is not where most DBAs think it is. Opening a standby database for any read-only access — including a single test SELECT statement — while it is in managed recovery mode activates Active Data Guard and triggers the licence requirement. Former Oracle insiders explain exactly where the line is, how Oracle detects it, and how to defend your DR environment against inflated Active Data Guard audit claims.

📅 March 2026 ⏱ 14 min read 🏷 Oracle Database · Data Guard · Active Data Guard · DR Licensing
Compliance Review → Audit Defence Service

What Data Guard Includes: The Free Standby Capability

Oracle Data Guard is Oracle's high-availability and disaster recovery framework for Oracle Database Enterprise Edition. It maintains one or more standby databases as transactionally consistent copies of the primary database, continuously applying redo log data from the primary to keep standby databases synchronised. Data Guard is included in Oracle Database EE — there is no additional licence cost for the base Data Guard capability.

The included Data Guard capabilities are:

Oracle Data Guard: Included in Oracle Database EE (No Additional Licence)

  • Physical standby database creation and management — creating a block-for-block copy of the primary database; applying redo log data in managed recovery mode (MRP); maintaining a transactionally consistent standby copy
  • Maximum Protection, Maximum Availability, Maximum Performance modes — the three Data Guard protection modes that balance data loss risk against primary database performance; all included in EE
  • Switchover and failover operations — graceful switchover to standby for planned maintenance; failover to standby for unplanned primary database failure; included in EE
  • Redo Apply and SQL Apply (logical standby) — both physical redo apply and SQL apply (logical standby) are included; SQL apply maintains the standby as an open database applying SQL statements derived from primary redo
  • Data Guard Broker — the management framework for Data Guard configuration; configures, monitors, and manages the Data Guard environment; included in EE
  • Data Guard Fast-Start Failover (FSFO) — automated failover when primary database failure is detected; included in EE (requires Data Guard Observer)
  • Snapshot standby — converting physical standby to a fully open read-write snapshot for testing, then reverting to physical standby; included in EE (does not require ADG)

The critical point: a standby database in managed recovery mode (applying redo, mounted but not open) is fully covered by the included Data Guard capability. No additional licence is required to maintain, switchover to, or fail over to a physical standby database that is in MRP (Managed Recovery Process) mode.

What Oracle Active Data Guard Adds and Why It's Separately Licensed

Oracle Active Data Guard extends the base Data Guard capability in ways that allow the standby database to serve workloads while simultaneously applying redo from the primary. This is the fundamental distinction: included Data Guard keeps the standby database available for failover but not actively serving workloads while in managed recovery; Active Data Guard makes the standby database simultaneously a recovery target AND an active, queryable database instance.

The features that require an Active Data Guard licence are:

Oracle Active Data Guard: Separately Licensed Features ($23,000/processor)

  • Real-Time Query — opening a physical standby database in READ ONLY WITH APPLY mode; the standby is open for read-only SQL queries while simultaneously receiving and applying redo from the primary; this is the most commonly used ADG feature and the primary licence trigger
  • Active Data Guard Far Sync — a Zero Data Loss (ZDL) configuration where a Far Sync instance (a lightweight Oracle instance that only receives and archives redo — no data files) is used as an intermediate synchronisation point; enables zero data loss protection across geographically dispersed data centres at near-zero performance overhead; requires ADG licence
  • Automatic Block Repair — automatic detection and repair of corrupt data blocks by fetching good blocks from the standby; triggered when primary database encounters a corrupt block; requires ADG licence
  • Lost Write Protection — Active Data Guard's mechanism to detect "lost writes" (when storage systems incorrectly confirm writes that were not persisted); uses standby-side block reads to verify primary writes; requires ADG licence
  • Global Data Services (GDS) — Oracle's service-based workload routing framework for Data Guard and GoldenGate configurations; routes client connections to the most appropriate database (primary or standby) based on service quality objectives; requires ADG licence
  • DML Redirect on Active Standby — allows DML statements (INSERT, UPDATE, DELETE) issued against an ADG standby to be transparently redirected to the primary database; enables applications to connect to the standby without needing to know which database is primary; requires ADG licence

The Exact Line Between Data Guard (Free) and Active Data Guard (Paid)

The licensing boundary between included Data Guard and the separately licensed Active Data Guard Option is precisely defined — and more strict than most DBAs realise. The trigger for Active Data Guard is opening the physical standby database in READ ONLY mode while managed recovery (redo apply) is active. Not the duration of the open state. Not the volume of queries executed. The trigger is the act of opening the standby for reads while redo apply is running.

The command that crosses the line is:

ALTER DATABASE OPEN READ ONLY; /* whilst MRP is running — triggers ADG licence */

This is in contrast to the commands that remain within the included Data Guard boundary:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; /* stops MRP */
ALTER DATABASE OPEN READ ONLY; /* opens standby after stopping MRP — Data Guard only, no ADG */
/* Note: standby not applying redo when open — full Data Guard, no ADG licence needed */

The included Data Guard allows you to open a physical standby for read-only access after stopping the managed recovery process. The standby database will be open and queryable, but it will not be applying redo from the primary during that period. This is the "manually managed" read-only standby model — it requires operational discipline (stopping and restarting MRP to open and close the standby) but is fully compliant without ADG.

The One-Query Trap: A DBA who opens a physical standby READ ONLY while MRP is running — even for a single test query to verify standby data currency — has triggered an Active Data Guard licence requirement that Oracle's dba_feature_usage_statistics will record. The feature usage entry includes the first date this occurred, and Oracle's LMS audit claim will be backdated to that first usage date. Ensure DBAs understand the ADG licence boundary before any read access to standby databases.

Check Your Standby Database Open Mode Before Oracle's LMS Team Does

Our Oracle Compliance Review audits your Data Guard configuration, standby open history, and dba_feature_usage_statistics across your estate — identifying any Active Data Guard usage before it surfaces in an Oracle audit.

Get DR Compliance Review →

Active Data Guard Pricing and Cost Structure

Oracle Active Data Guard is priced at $23,000 per processor (perpetual list) on the same Processor metric as Oracle Database EE. Annual support is approximately $5,060 per processor at Oracle's 22% support rate. Active Data Guard must be licensed for each processor on the standby database server — not just the primary database server.

This is a frequently misunderstood point: the Active Data Guard licence is required for the standby database host, not the primary. The logic is that ADG provides active workload-serving capability to the standby host, so the standby host processors are what Oracle licences. However, in practice most enterprises also require the ADG licence on the primary host to cover features like Automatic Block Repair and Lost Write Protection, which operate on both sides of the Data Guard configuration.

$23,000 Active Data Guard perpetual list price per processor
$92,000 ADG perpetual cost for 4-processor standby server
$460,000 ADG perpetual cost for 20-processor DR environment

For organisations running Oracle Database EE in active-passive DR configurations with physical standby databases, the ADG licence cost for the standby environment represents approximately 48% of the Oracle Database EE licence cost for the same processor count ($23,000 vs $47,500 per processor). This is a significant cost that Oracle's sales teams frequently omit from initial DR architecture discussions — the "Oracle provides Data Guard for free with EE" message omits the ADG licence requirement for operational standby query workloads.

How Oracle LMS Detects Active Data Guard Usage

Oracle's LMS audit scripts detect Active Data Guard usage through multiple data dictionary views on both the primary and standby databases. The detection is comprehensive and historically retroactive:

Oracle LMS Active Data Guard Detection Points

  • dba_feature_usage_statistics — records "Active Data Guard" feature usage with FIRST_USAGE_DATE and LAST_USAGE_DATE; captures the first time a standby was opened READ ONLY while MRP was active; Oracle's audit claim is backdated to FIRST_USAGE_DATE
  • v$database.open_mode — on the standby, shows current open mode (READ ONLY WITH APPLY = ADG active; MOUNTED = managed recovery, no ADG; READ ONLY = read only without apply, no ADG)
  • Data Guard Broker configuration files (dgmgrl.conf) — broker configuration specifies the standby's configured open mode; a broker configuration with LOG_SHIPPING enabled and standby_open_mode = READ ONLY with APPLY indicates ADG configuration intent
  • Alert log analysis — standby alert logs contain messages indicating when the standby was opened READ ONLY WITH APPLY; Oracle's USMM may request alert log extracts to establish the historical ADG usage period
  • Oracle Enterprise Manager repository — if OEM is used to manage Data Guard, the OEM repository contains configuration history that can indicate ADG usage periods

The FIRST_USAGE_DATE in dba_feature_usage_statistics is Oracle's primary evidence source for ADG audit claims. This date reflects the first time the standby's open mode included active redo apply — which in many environments occurred years before the organisation knew ADG required a separate licence. Oracle's standard LMS audit demand includes ADG licence cost from FIRST_USAGE_DATE to the date of audit settlement.

Hot Standby Licensing: The DR Environment Cost Debate

Beyond Active Data Guard specifically, Oracle's licensing rules for DR environments more broadly are a source of ongoing commercial tension. Oracle's published policy is that standby databases in a Data Guard configuration — even those used purely for DR purposes — must be fully licensed for Oracle Database EE. There is no DR discount, no passive-server discount, and no provision for lower-cost standby licences in standard Oracle agreements.

This means a four-processor production Oracle EE database with a four-processor physical standby requires eight processor licences of Oracle Database EE (four for primary, four for standby) even though the standby server never serves production workloads. The cost: 8 processors × $47,500 = $380,000 in perpetual licences. Annual support: $380,000 × 22% = $83,600.

Some Oracle Enterprise Agreements and ULA structures include language that modifies the DR standby licensing requirement — for example, allowing one passive standby database to be maintained without additional licence cost, or licensing the DR standby environment at a reduced rate. These contractual provisions must be explicitly negotiated. Oracle's standard terms do not include them. Our Oracle Contract Negotiation advisory consistently includes DR standby licence terms as a key negotiation objective in EA and ULA structures — enterprises that negotiate these terms save $100,000–$500,000+ in standby environment licence costs over the life of the agreement.

The "10 Days per Year" Rule — What It Doesn't Cover: Some DBAs believe Oracle allows standby databases to be used for up to 10 days per year for testing without requiring full licensing. This rule is specific to very limited testing scenarios and does not apply to operational Data Guard standby databases. Do not rely on the 10-day rule for production DR environments. Review your Master Agreement and Technical Support Policies for the specific terms that govern your deployment.

Common Active Data Guard Compliance Traps

Based on our experience in Oracle DR environment compliance reviews, the most frequent Active Data Guard compliance gaps arise from:

  • DBAs opening standby for data verification during DR tests — DR tests routinely involve opening the standby database to verify data integrity. If the standby is opened READ ONLY while MRP is still running (to avoid the downtime of stopping and restarting MRP), ADG is triggered. DBAs should stop MRP before opening standby for test purposes.
  • Oracle Enterprise Manager automatic diagnostic operations — OEM's automatic diagnostic and performance features may initiate connections to standby databases that open them in READ ONLY WITH APPLY mode as part of configuration validation. These OEM-initiated connections create ADG usage records in dba_feature_usage_statistics.
  • Automated backup operations routed to standby — RMAN backups can be routed to physical standby databases for performance reasons (to offload backup I/O from the primary). If the standby is opened READ ONLY WITH APPLY for the backup window, each backup operation creates an ADG usage event.
  • Migration of standby open mode from READ ONLY to READ ONLY WITH APPLY — when a DBA changes the standby open mode from READ ONLY (allowed without ADG when MRP is stopped) to READ ONLY WITH APPLY (requires ADG) to improve standby currency, this is the precise trigger for ADG licence activation.
  • Rolling upgrades using ADG — Oracle's recommended rolling upgrade process uses Active Data Guard to maintain zero downtime during Oracle Database patch application. Running the upgrade process without an ADG licence creates exposure for the upgrade period.
Oracle Asserted Active Data Guard Licence Obligations in Your DR Environment?

Our Oracle Audit Defence team reviews ADG usage history, challenges FIRST_USAGE_DATE claims, and analyses your Master Agreement DR terms to establish a defensible position against Oracle's ADG audit demand.

Get Audit Defence →

Defending Against Oracle's Active Data Guard Audit Claims

Active Data Guard audit claims are defendable on several grounds, and the best outcomes come from combining technical challenges to Oracle's usage evidence with contractual analysis of your DR licensing terms:

FIRST_USAGE_DATE challenge: Oracle's ADG licence claim is backdated to the FIRST_USAGE_DATE in dba_feature_usage_statistics. If this date reflects a brief, inadvertent ADG usage event — say, a DBA who opened the standby READ ONLY WITH APPLY for 30 seconds during a DR test and then reverted to MRP-only mode — the duration and functional impact of that usage can be challenged in settlement negotiations. Oracle's claim that a 30-second inadvertent activation triggers years of back-licensing from that date is commercially disproportionate and negotiable.

DR testing vs production use: If ADG usage occurred exclusively during scheduled DR tests — not as a continuous production read workload — this limits the functional benefit Oracle can demonstrate for the back-licence claim. Oracle's licence obligation arises when the feature is used, but the commercial settlement value of brief test usage is significantly lower than continuous production reporting workloads.

Contract term analysis: Review your Master Agreement, ULA certification report (if applicable), and EA Order Forms for any provisions relating to standby database licensing or DR environment terms. Some agreements explicitly limit Oracle's right to assert ADG back-licensing for certain DR test scenarios.

The Healthcare: Compliance Remediation case study included an Active Data Guard component where Oracle's initial ADG back-licence claim was based on a FIRST_USAGE_DATE from DR testing activities three years prior. Our defence team demonstrated that the usage was exclusively during annual DR tests (four occurrences over three years, each for less than two hours), and negotiated the settlement to cover only the test periods rather than three years of continuous ADG usage at the full licence rate. The settlement was $84,000 versus Oracle's initial demand of $690,000.

Engage our Oracle Audit Defence service or our Oracle Compliance Review to establish your ADG position before Oracle's LMS team formalises the audit claim. Proactive review of your standby database configurations — and correcting any inadvertent ADG activations — before an audit notification is always the most cost-effective approach.

Key Takeaways

  • Oracle Data Guard (standby for failover/recovery only) is included in Oracle Database EE — no additional licence required for physical standby maintenance, switchover, and failover
  • Oracle Active Data Guard requires a separate licence at $23,000 per processor — triggered the moment a physical standby database is opened READ ONLY while managed recovery (MRP) is active, regardless of query volume or duration
  • The precise compliance boundary: opening standby READ ONLY after stopping MRP = included Data Guard; opening standby READ ONLY while MRP is running = Active Data Guard licence required
  • Oracle LMS detects ADG usage via dba_feature_usage_statistics FIRST_USAGE_DATE — audit claims are backdated to the first instance of ADG activation, potentially years in the past
  • Common inadvertent ADG triggers include DR test procedures, OEM automatic diagnostic operations, RMAN backups routed to standby, and rolling upgrade procedures
  • ADG audit claims are negotiable — brief, inadvertent test-only ADG usage settles significantly below Oracle's headline back-licence demand when challenged with forensic evidence of the usage scope and duration

Oracle Database Licensing Masterclass

Comprehensive guide to Oracle Database EE, Data Guard, Active Data Guard, RAC, and all separately licensed options — including the DR environment licensing rules, compliance methodology, and audit defence framework.

Download Free Guide →
Oracle Licensing Intelligence

Oracle HA & DR Licensing Alerts

Active Data Guard audit activity has increased significantly as Oracle's LMS team targets DR environments. Our newsletter tracks Oracle Data Guard and ADG compliance developments for enterprise buyers.

No spam. Unsubscribe anytime. Not affiliated with Oracle Corporation.

Oracle Licensing Experts Team — Former Oracle executives, LMS auditors, and contract managers with 25+ years of Oracle licensing experience, now working exclusively on the buyer side. Not affiliated with Oracle Corporation. Learn about our team →

Free Research

Download our Oracle OCI Licensing Guide — expert analysis from former Oracle insiders, 100% buyer-side.

Download the OCI Licensing Guide →