Standard Data Guard vs. Active Data Guard: The Core Distinction
Active Data Guard carries an $11,500 per-processor list price — and Oracle requires you to license both the primary and standby databases the moment any ADG feature is activated. The critical distinction that determines licensing obligation is whether you are using passive standby replication or activating any active standby features. Understanding this boundary is essential because the licensing model shifts dramatically once you cross it. For broader context on Oracle options licensing, see the Oracle Knowledge Hub.
Standard Data Guard, included free with Oracle Database Enterprise Edition, enables you to maintain a physical standby database for disaster recovery purposes. In this configuration, the standby database receives redo logs from the primary and applies them automatically to maintain a synchronized copy. The standby is read-only and serves no function except failover capacity in the event of primary database unavailability. This is the traditional, free tier of Data Guard functionality that organizations have relied on for decades.
Active Data Guard (ADG) represents a completely different licensing position. ADG converts the passive standby database from a pure disaster recovery clone into an active business resource. Once any ADG feature is engaged, you have triggered a separate paid license requirement on both the primary and standby databases at matching processor counts. This is where audit exposure emerges, because many organizations activate ADG features incrementally, sometimes unknowingly, without realizing that their licensing status has changed.
The free-to-paid transition happens at the feature level, not the product level. You can run passive Data Guard indefinitely at no additional cost. But the moment you query the standby database for read-only reporting, use automatic block repair, apply Oracle's Far Sync component, enable DML redirection to the standby, or leverage fast incremental backups via block change tracking from the standby, you have activated ADG. At that moment, your licensing obligation is immediate and backdated to the moment of first usage.
What Triggers Active Data Guard Licensing
Active Data Guard is not a single monolithic feature. Instead, it is a collection of capabilities that, once enabled, require the ADG license. Understanding the full scope of what triggers ADG licensing is critical because some of these features are easy to activate accidentally, and others are enabled by default in newer Oracle versions.
Real-time query access to the standby database is the most straightforward trigger. If your standby database is opened for read access while redo logs are being applied from the primary, you have activated ADG. This includes any user queries, reporting jobs, analytics workloads, or application access to the standby. The standby can serve as a live reporting database, removing that workload from the production primary system.
Automatic block repair is another key ADG feature. When Oracle detects a corrupted block during a read operation on the primary, it can automatically request a good copy of that block from the standby database and repair it in place. This is a powerful feature for production resilience, but it requires ADG licensing and is triggered the moment Oracle performs that repair operation. The activation is recorded in DBA_FEATURE_USAGE_STATISTICS.
Far Sync is an intermediate standby database that improves the robustness of synchronous replication architectures. If you deploy a Far Sync instance to improve redo log transmission guarantees, you have activated ADG on that Far Sync instance. Far Sync is particularly common in cloud deployments and hybrid architectures where network latency to a distant geographic standby is problematic.
DML redirection enables write operations against the standby database that are automatically redirected back to the primary. This allows applications to connect to the standby and issue inserts, updates, and deletes as if it were the primary, with Oracle transparently redirecting those operations. This is a powerful architecture for zero-downtime maintenance and rolling upgrades, but it triggers ADG licensing immediately.
Fast incremental backup via block change tracking is another ADG trigger. When you enable block change tracking for incremental backups on the standby database, you activate ADG. This feature allows significantly faster incremental backups because Oracle tracks which blocks have changed since the last backup, reducing the amount of data that must be scanned and transmitted.
Rolling upgrades use ADG features to perform database version upgrades with zero downtime by upgrading the standby first, then switching roles. The process itself requires several ADG capabilities, including real-time query access during the upgrade window.
ADG Pricing and Licensing Metrics
Active Data Guard is priced at $11,500 per processor at standard Oracle list prices, or $230 per Named User Plus (NUP). Most organizations license ADG on a per-processor basis because processor licensing is substantially cheaper for large deployments, but some smaller environments may find NUP licensing more economical.
Annual support fees for ADG escalate at 8 percent per year on the net license fee you paid. This means that the cost of ownership compounds over time. A 10-processor ADG license purchased at list price today ($115,000) will generate approximately $25,300 in support costs annually, and that support cost will increase 8 percent each year. Over a five-year period, support costs alone exceed the initial license purchase price.
Both the primary and standby databases must be licensed for ADG at matching processor counts. You cannot license only the standby for ADG. Working with Oracle licensing advisory specialists can help you model the true cost before Oracle forces the conversation. If your primary database runs on 12 processors and your standby runs on 12 processors, you must purchase 24 processor licenses of ADG (12 for primary, 12 for standby). This doubling is a critical cost driver for ADG deployments.
Virtualization introduces complexity into processor counting. If you are running your primary database on a VMware cluster with 40 physical cores and your standby on a different VMware cluster with 20 physical cores, you must license based on the processor count of each cluster, not individual servers. This can lead to situations where licensing becomes more expensive than the underlying infrastructure cost justified.
The Primary and Standby Licensing Requirement
Oracle's licensing model for ADG explicitly requires licensing of both the primary and standby databases. This is not optional or negotiable. Many organizations assume they can purchase ADG licenses only for the standby server, but that is not permitted under the Oracle Database Licensing Agreement.
The requirement applies regardless of whether both databases run the same software version, the same database instance name, or the same configuration. The moment you enable any ADG feature, both databases require matching ADG licenses at their respective processor counts.
If your primary runs on 8 processors and your standby runs on 16 processors (a common scenario when the standby is running in a less expensive geographic region with consolidated hardware), you must license 24 processors of ADG in total. You cannot discount either database based on its usage level or criticality to the business.
The 10-Day Passive Failover Exception
Oracle does provide a limited exception to the ADG licensing requirement for genuine disaster recovery scenarios. This exception permits a standby database to operate free for up to 10 separate 24-hour periods per calendar year, provided the standby is operating in passive mode with no ADG features enabled.
The intent of this exception is to allow organizations to test their disaster recovery process annually without incurring unexpected license costs. The standby can be opened in read-only mode for testing purposes, data integrity checks can be run, and failover procedures can be validated. Once you exceed the 10-day threshold in a calendar year, or if you activate any ADG feature during that failover window, the free exception expires and you immediately owe ADG licensing going back to the moment of first usage.
This exception is strict in its application. The days do not roll across calendar year boundaries. In a single calendar year, if you use the exception 10 times for 24 hours each (10 total days), you cannot use the exception again until January 1 of the following year. Each day must be a separate, distinct 24-hour period. Running the exception for 12 hours, then 12 hours again on the same calendar day counts as one day, not two.
Virtualisation: The VMware and Hyper-V Trap
Virtual machine deployment introduces significant licensing complexity for ADG because Oracle counts physical processor cores on the underlying hypervisor, not virtual CPUs assigned to the instance. If your primary database runs on a VMware cluster with 64 physical cores and your standby runs on the same cluster, Oracle's licensing position is that you must license the standby for 64 processors, not the number of vCPUs allocated to the standby instance.
This creates a scenario where virtualizing your standby database on the same cluster as your primary database can substantially increase licensing costs. It also incentivizes purchasing separate, dedicated physical hardware for standby databases—a counterintuitive outcome that drives infrastructure spending.
Hard partitioning of VMware clusters using features like vSphere DRS, resource pools, and CPU affinity does provide some relief from this rule, but only if Oracle agrees that your partitioning is sufficiently isolated. Most standard VMware deployments do not qualify for relief. The safe approach is to assume that a standby running on the same VMware cluster as any other Oracle database will trigger licensing liability based on all physical cores in that cluster.
Hyper-V encounters similar challenges. If your standby instance runs on a Hyper-V host with 24 physical cores, and that host hosts other virtual machines, Oracle's licensing position includes counting those physical cores even if only a fraction are allocated to the standby database instance.
How Oracle Audits ADG Usage
Oracle's auditing methodology for ADG relies on the DBA_FEATURE_USAGE_STATISTICS view, a dictionary view that records every feature usage event with exact timestamps. If you've received an audit notification, our Oracle audit defence specialists can assess your exposure immediately. When you query the standby database for the first time, Oracle records that event. When automatic block repair occurs, that event is logged. When you enable any ADG feature, the activation is recorded.
The critical point for audit defense is that DBA_FEATURE_USAGE_STATISTICS is persistent. Disabling an ADG feature after you have used it does not erase the historical record. Oracle's audit procedures include examining this view to identify when features were first activated and how frequently they were used. Even if you disable ADG months before an Oracle audit notification arrives, the historical usage logs provide complete evidence of past usage.
This means that the moment of first activation, not the moment of audit discovery, determines when your licensing obligation begins. If you used real-time query access on the standby for two weeks before disabling it, then did not use ADG for the next year before an audit, Oracle will claim that your obligation dates from the moment of first usage, not from the audit date.
Oracle's audit queries examine DBA_REGISTRY as well, which contains feature registration history for the database. This provides a secondary source of usage confirmation beyond DBA_FEATURE_USAGE_STATISTICS, making it difficult to dispute Oracle's evidence of feature activation.
ADG in Oracle Cloud (OCI)
Active Data Guard licensing applies to Oracle Cloud deployments as well. If you run a primary database in OCI and a standby in OCI, the same licensing rules apply. The cost structure is different (costs are built into your OCI subscription rather than separate license purchases), but the requirement to license both primary and standby still applies.
Some Oracle Cloud Infrastructure (OCI) services include basic Data Guard at no additional charge, but if you activate any ADG feature, you will incur additional per-compute cost for the ADG capability. Understanding the boundary between free Data Guard and paid ADG in OCI is critical for cloud cost management and budget planning.
Five Priority Actions for ADG Compliance
1. Inventory your current deployment. Identify every primary-standby pair in your environment and determine whether any ADG features are currently activated. Run queries against DBA_FEATURE_USAGE_STATISTICS and DBA_REGISTRY on both primary and standby to identify feature activation events. Document the current licensing status in a spreadsheet.
2. Disable any unintended ADG features immediately. If you discover that real-time query access, automatic block repair, or block change tracking are enabled but not required for your business, disable them immediately. This prevents further exposure accumulation, though historical usage will remain in the audit trail.
3. Quantify the cost of proper licensing. Calculate the cost of licensing ADG across your standby databases. For each standby, multiply processor count by $11,500 list price, then multiply by 2 (primary plus standby), then add annual support costs at 22 percent, escalating 8 percent per year. Compare that cost against the cost of discontinuing the ADG features that triggered the requirement. If licensing ADG makes commercial sense, Oracle contract negotiation can secure discounts of 40-60% off list price.
4. Document business justification for each ADG use case. For each standby database where you are activating ADG features, document why that feature is business-critical. This documentation is essential audit defense material. If you cannot articulate why a feature is required for business continuity or performance, you should disable it.
5. Establish prospective compliance controls. Create a change control process that prevents new ADG features from being activated without explicit business and licensing approval. Train your database administration team to understand the licensing implications of Data Guard configuration changes. Implement alerting on DBA_FEATURE_USAGE_STATISTICS so that new feature activations are detected immediately.