Oracle Active Data Guard Licensing

Oracle Active Data Guard is licensed as follows:

• License Metric and Quantities: It must match the license metric and quantities of the Oracle Database Enterprise Edition license.
• License on Both Environments: Oracle Active Data Guard should be licensed in the primary and standby environments.
• Cost: The license cost for Oracle Active Data Guard is $11,500 per processor

Oracle Active Data Guard Licensing

Oracle Active Data Guard (ADG) is a powerful add-on to Oracle Database Enterprise Edition, enhancing disaster recovery and availability capabilities. However, licensing ADG correctly is critical for compliance and cost management.

This article provides an in-depth explanation of ADG licensing for licensing professionals, including how ADG differs from standard Data Guard, key features, Oracle’s Named User Plus vs Processor licensing models, official licensing rules, common pitfalls, and real-world scenario examples.

Data Guard vs. Active Data Guard: What’s the Difference?

Oracle Data Guard (standard feature) is included with Oracle Database Enterprise Edition at no extra cost. It provides the core ability to maintain one or more standby databases as transactionally consistent copies of a primary database for disaster recovery.

In a Data Guard configuration, the standby database is typically in a mount state, applying redo logs from the primary and ready to take over in the event of a failover.

Data Guard ensures high availability and data protection, but does not allow active use of the standby for query or backup workloads while synchronized.

Oracle Active Data Guard, on the other hand, is a licensed Enterprise Edition Option that extends Data Guard’s functionality. ADG was introduced in Oracle 11g to enable important enhancements to the availability and utilization of standby databases.

With Active Data Guard, a physical standby database can be read-only for reporting, querying, or backup purposes – all while continuously applying redo logs from the primary database.

This means the standby can be used actively (hence “Active” Data Guard) for tasks that would otherwise burden the primary, improving return on investment in the DR infrastructure.

Active Data Guard provides capabilities beyond basic Data Guard, including real-time query against the standby, offloading workloads, and advanced features (detailed below) that improve data protection and minimize downtime.

From a licensing perspective, the key difference is that Data Guard requires no separate license (a feature of Enterprise Edition). In contrast, Active Data Guard must be licensed separately as an option.

Using any Active Data Guard features (such as querying the standby) requires an ADG license.

Moreover, Oracle’s rules state that the primary and standby database servers must be fully licensed for Active Data Guard, using the same licensing metric as the primary database.

This is an important point—simply having an Oracle Database license on standby is not enough if ADG is in use; you need the ADG option license on both sides.

Summary: Data Guard vs Active Data Guard

Key Features of Oracle Active Data Guard

Oracle Active Data Guard offers features that enhance the core Data Guard capabilities, enabling organizations to utilize their standby database more effectively.

Some of the key features included in Active Data Guard are:

• Real-Time Query – Allows read-only workloads (reports, selects, etc.) to be offloaded to a constantly synchronized standby database. This provides up-to-date query results from the standby, adds read scalability, and continuously validates that the standby is ready to fail over if needed.
• Automatic Block Repair—If the primary or standby database encounters a physical data block corruption, it is automatically repaired by fetching the correct block from the other database. This improves data integrity and availability transparently.
• Far Sync – A lightweight synchronous transport option that sends redo to a remote target (a Far Sync instance) with negligible overhead, enabling zero data loss protection even over long distances. Far Sync helps achieve RPO=0 without impacting primary performance by forwarding redo to the actual standby.
• Fast Incremental Backup Offload—Block Change Tracking (BCT) on the standby allows for fast incremental RMAN backups to be taken on the standby database, rather than the primary. This can improve backup performance by up to 20x and avoid impacting the primary database during backup windows.
• Rolling Upgrades—The standby supports rolling database upgrades or patching, minimizing downtime. An Active Data Guard standby can apply updates and switch roles with the primary, allowing continuous service while patching.
• Global Database Services (GDS) – Integrates the standby into a global workload management framework. GDS provides intelligent load balancing and automated service failover across replicated databases (useful in globally distributed database deployments).
• Application Continuity – Works with Active Data Guard to mask database outages from applications by replaying in-flight transactions on failover. This often makes failovers (planned or unplanned) transparent to end-users.
• Real-Time Cascade – Allows a standby database to feed redo data to a secondary standby. In other words, one standby can cascade redo to another standby, enabling multi-tier replication for additional protection without impacting the primary.
• DML Redirection – Available in newer releases (Oracle 19c and later), this feature enables certain DML (writes) on a read-only standby by transparently forwarding those write operations to the primary database. This way, minor updates (e.g., temporary tables or session context) can be done even when connected to a standby, improving application flexibility while maintaining data consistency.

These features illustrate why many organizations license Active Data Guard – it turns a standby database into an active asset for reporting, backup, and high availability.

However, these capabilities are only available if you have purchased the Active Data Guard option licenses for the relevant environments.

Oracle Licensing Models for ADG: Named User Plus vs Processor

Oracle offers two primary licensing models for database software (including options like Active Data Guard): Named User Plus (NUP) and Processor licensing.

ADG can be licensed under either model, but the choice will depend on your environment and must align with how your Oracle Database is licensed.

• Named User Plus (NUP) Licensing: This model licenses the software based on the number of distinct “named” users (or devices) that have access to the Oracle Database/ADG. A Named User Plus is any individual or non-human device authorized to use the Oracle program, regardless of whether they are actively using it at any given moment. All users and devices accessing the database, whether directly or through any middle-tier, must be accounted for. Oracle requires a minimum number of NUP licenses per processor for the software to be properly licensed. For Oracle Database Enterprise Edition (and its options, such as ADG), the minimum is 25 Named User Plus licenses per processor. In practice, a small deployment (with few users) on a powerful server may require licensing 25 NUP for each processor as a baseline. NUP licensing can be more cost-effective if the user population is limited and known – for example, an internal system with 40 named users might be cheaper to license by NUP than by processors. However, NUP licensing becomes impractical if user counts, such as public-facing systems, become high (or difficult to measure). Important: If NUP licenses ADG, the number of NUP licenses for ADG must be at least equal to the number of NUP licenses for the associated Oracle Database. In other words, you cannot license ADG for fewer users than are licensed on the primary database, since all those database users would potentially use the standby’s ADG functionality.
• Processor Licensing: This model licenses the software based on the number of CPU cores occupied by the Oracle Database instance (in a physical or virtual environment). Oracle defines the number of “processors” to license by multiplying the core count by a core-specific factor (per the official Oracle Core Factor Table). For example, Intel x86 cores have a 0.5 factor, so two cores count as one licensed processor. Under processor licensing, you do not count users at all – unlimited users, but you must license every processor on every server running the Oracle software. Processor licensing is typically chosen for large or externally facing systems where counting users is not feasible, or when the number of users exceeds the point at which NUP would be more cost-effective. It provides simplicity (just cover the CPUs), but can be more expensive for small user counts.

Active Data Guard must use the same licensing model as the primary database it complements. If processors license your Oracle Database EE, ADG must also be licensed by processors; if NUP licenses the database, ADG must be licensed by NUP with the appropriate user counts.

Oracle does not allow mixing metrics for the same solution (no scenario where the DB is processor-based and ADG is user-based, or vice versa).

Furthermore, the quantity of licenses should match: e.g., a database with four processor licenses will require four processor licenses of ADG on that server; a database licensed for 100 Named Users will require at least 100 Named User licenses for ADG.

Oracle Active Data Guard Licensing Rules and Policies

Licensing Oracle Active Data Guard may seem straightforward – it’s “just another option” on top of Oracle Database – but there are specific rules and common misunderstandings.

Below is a clear interpretation of Oracle’s licensing rules for ADG:

• Enterprise Edition Requirement: Active Data Guard is only available with Oracle Database Enterprise Edition. It is an add-on feature to Enterprise Edition; it cannot be used with Standard Edition databases. This means if you run Standard Edition (which lacks Data Guard), ADG is not applicable. Ensure your primary database is Enterprise Edition before considering ADG licensing.
• License Both Primary and Standby: Every environment where Active Data Guard is used must be licensed. Oracle requires that the ADG option be licensed on the primary database server and each standby database server that is part of the Data Guard configuration. This rule surprises some customers, and even though ADG’s main functionality runs on standby, Oracle’s policy is that both sides of the replication must have the option licensed. The rationale is that the primary database actively sends redo data and supports ADG features (e.g., block repair, DML redirection), which is considered part of the ADG usage. Practically, if you have one primary and one standby and enable Active Data Guard, you will pay for two ADG licenses (one for each server). For multiple standby databases, each standby that uses ADG features must also be licensed.
• Matching License Metric and Quantity: As noted, the licensing metric for ADG must match the database. You cannot mix and match (e.g., you cannot license the primary by Processor and the standby by NUP, or vice versa). If your primary database has four processor licenses, the standby must also have four processor licenses of ADG (assuming the standby has at least four cores; see next point). If your primary is licensed for 50 Named Users, the ADG option also needs 50 licenses (per environment). Oracle’s standard contract language stipulates that the number of NUP licenses for any option must equal at least the number of NUP licenses for the associated program (the database). This rule ensures full coverage of all users/CPUs across the board.
• License per Processor/Core on Each Server: When licensing by Processor, you need to account for the hardware on each server. You license each physical core (after applying Oracle’s core factor) used by the Oracle database instance on the primary and standby. If the primary and standby have different hardware or core counts, you license them accordingly (it is not automatically based on the higher of the two; you license what each has running). For example, if the primary runs on a 16-core server and the standby on an 8-core server, and all cores are utilized for the database, you would need 16 cores’ worth of ADG licenses for the primary and eight cores’ worth for the standby. (In Named User terms, you’d need to cover all users that access either database instance.) Each environment’s license can be purchased to match its size, but you cannot license only the smaller system and claim coverage for the larger; each must be properly licensed in its own right. Oracle’s pricing for ADG is the same regardless of whether it is primary/standby: currently, USD 11,500 per processor license for Active Data Guard (list price), or USD 230 per Named User Plus. These list prices would be subject to Oracle discounts, but they give a sense of cost scale.
• Minimum Named User Plus Counts: Note the 25-per-processor minimum requirement for NUP licensing. For instance, even if you only have five actual users of the standby, if the standby’s host is a 2-processor machine, Oracle would require at least 50 Named User Plus licenses (25 per proc * 2) for the ADG option on that standby (and similarly for the primary). In many cases, the number of users of an Oracle database exceeds these minimums, but this rule prevents under-licensing small numbers of users on large servers. Additionally, all human or device users who access the standby for reporting must be included among the Named Users (typically, these are the same users who access the primary system).
• No Partial Licensing of Environments: You cannot license Active Data Guard for only the standby or the primary – the option must be licensed wherever it is installed and/or running. For example, licensing just the standby server for ADG, not the primary, is prohibited (and would violate Oracle’s terms). Likewise, it’s not allowed to license only some of the standbys in a multi-standby configuration – every active standby using ADG must have it licensed. Essentially, if an Oracle Database Enterprise Edition installation is active on a server and you intend to use ADG features, that installation needs an ADG license.
• Oracle’s 10-Day Rule for Failover (Passive DR): Oracle has a licensing policy that provides some relief for purely passive failover scenarios. Suppose a standby database is only used in disaster recovery emergencies or for brief failover testing, and is not open for read/write or actively synced beyond those tests. In that case, Oracle permits licensing the standby separately only when it is activated beyond a certain threshold. Specifically, Oracle’s rules allow a failover environment to run unlicensed for up to 10 separate days (24-hour periods) in a given year. This is often called the “10-day rule.” If the standby is activated (opened) more than 10 days a year, it must be fully licensed. Only one failover node can be exempted in this way, and any usage (even for patching or maintenance) counts against the 10-day limit. However, this failover exception does not cover Active Data Guard usage. When you use the standby for query/backup while the primary is running, it’s no longer a “cold” failover node – it’s actively contributing, thus it requires licensing. The 10-day rule is intended for scenarios where the standby is normally idle and only brought online during a failover or test. If you’re using ADG, by definition, the standby is constantly active (applying redo, open read-only, etc.), so you should plan to fully license it from the start. The failover waiver might save you an Oracle DB license for a passive standby. Still, if you want to benefit from Active Data Guard, you must license the standby, regardless of any failover policies.
• License in All Environments (On-Premises and Cloud): Oracle’s licensing rules for ADG apply equally in on-prem data centers and cloud environments. If you deploy an Oracle database with ADG in the cloud under a BYOL (Bring Your Own License) model, you must allocate your Oracle licenses to cover those cloud VMs or instances just as you would on physical servers. The number of processors or NUP licenses must correspond to the cloud CPU count, considering Oracle’s core definitions (for example, Oracle counts vCPUs differently on authorized cloud platforms). Oracle notes that when using BYOL in Oracle Cloud Infrastructure (OCI) or other authorized clouds, your Active Data Guard licenses must match the number of database licenses in use. Alternatively, if using Oracle’s cloud subscription (where you pay hourly for the service, including licenses), Active Data Guard can be enabled as a subscribed service for an additional cost. However, in any BYOL scenario, ensure you have purchased sufficient ADG option licenses to cover the environment. Always adhere to Oracle’s cloud licensing guidelines and core factors for services like AWS or Azure when allocating licenses (for example, on AWS, Oracle typically counts two vCPUs as equivalent to 1 processor license). The key point is that cloud deployment is not a loophole – Active Data Guard still requires proper licensing, as per Oracle policy, whether on a virtual machine or a physical server.

By following these rules—the same metric, licensing both primary and standby, counting all processors or users, and respecting minimum requirements—you can ensure compliance with licensing Active Data Guard.

Misinterpreting these rules can lead to costly mistakes, which we will examine in the next section.

Common Pitfalls and Misunderstandings

Licensing Oracle products can be complex, and Active Data Guard is no exception. Several common pitfalls frequently catch organizations off guard.

Below are some typical misunderstandings and mistakes related to ADG licensing (and how to avoid them):

• Assuming Data Guard = Active Data Guard: Perhaps the most common mistake is enabling Active Data Guard features without realizing they require a separate license. For example, opening the standby database for read-only reporting does require the ADG option. Some organizations mistakenly assume that since Data Guard is included with Enterprise Edition, they can use the standby in read-only mode freely – this is not true. Pitfall: Enabling ADG functionality (such as real-time query) on a standby without purchasing ADG licenses will put you out of compliance. Always differentiate: basic Data Guard (log shipping, managed failover) is free with EE, but “Active” Data Guard capabilities are a separately licensed product.
• Not Licensing the Standby Environment: Another error is to only license the option on the primary database, assuming the standby doesn’t need it because it’s “just a copy.” Oracle requires both primary and standby to be licensed for ADG. Failing to license the standby (or all standbys in a multi-standby setup) is a compliance violation. Similarly, undercounting the processors on standby is an issue; sometimes companies license ADG for the primary’s cores but overlook the fact that the standby server might have an equal (or even greater) number of cores that also need licensing. Pitfall: Only licensing part of the environment (e.g., just the primary or using the core count of one server for both) will result in under-licensing. Always perform separate calculations for each server in the Data Guard configuration.
• Mixing License Metrics: Oracle licensing experts warn against mixing metrics to save costs. One cannot, for instance, license the primary database using NUP licenses and then attempt to license Active Data Guard on the standby by processors (or vice versa). All Oracle Database options must follow the base license metric. Trying to mix them violates Oracle policy and can create a messy compliance situation during an audit. Pitfall: Combining different metrics (NUP vs Processor) for the database and ADG option is not allowed and will be flagged in an audit. Ensure your ADG licensing method mirrors your database licensing method exactly.
• Ignoring User Minimums or Counting Rules: When using NUP licensing, a common mistake is miscounting users or failing to meet the minimum license requirements. For example, if you have 8 DBAs who occasionally query the standby, you might think you need just 8 NUP licenses for ADG; however, the minimum requirement is 25 per processor. Your standby has two processors; you need at least 50 NUP licenses. Or conversely, some may double-count users unnecessarily – remember that Named User Plus is per named individual, not per server, so if the same user accesses both primary and standby, they count once (but you need enough licenses to cover them on each deployment). Pitfall: Violating Oracle’s user counting rules (under-counting or not meeting minimums) can lead to compliance issues. Always count all individuals and devices with access and ensure that the 25-per-processor minimum threshold is met.
• Virtualization and Hard Partitioning Miscalculations: Oracle’s licensing can become especially tricky in virtualized environments. A notable pitfall is licensing only the virtual CPUs allocated to the Oracle VM or container, rather than the underlying physical cores, when Oracle does not approve the virtualization technology for sub-capacity licensing. Oracle generally requires that, if soft partitioning (non-approved virtualization, such as VMware) is used, all physical cores on the host must be licensed, not just the subset assigned to the VM. Organizations sometimes mistakenly license ADG for, say, four vCPUs of a standby VM, when the host has 16 physical cores – this would be non-compliant. The correct approach would be to use a permitted hard-partitioning method or license the full host. Pitfall: Treating virtualization incorrectly, such as licensing only vCPUs in VMware, can result in a significant shortfall during an audit. Engage Oracle licensing specialists or refer to Oracle’s partitioning policy if you run ADG in a virtual environment, to ensure you count processors accurately.
• Overlooking Feature Dependencies: While not a licensing rule per se, another common mistake is failing to recognize when a feature you enable implicitly requires ADG. For instance, enabling Automatic Block Repair or DML Redirection on a standby database may not be an obvious setting, such as opening the database in read-only mode. Still, these are Active Data Guard features under the hood. Using them without licenses is just as problematic. Always cross-check new features you plan to use on a standby: if it’s listed as an Active Data Guard feature, ensure you have the licenses in place. Oracle documentation and price lists enumerate which features belong to ADG – consult those or an independent licensing advisor when in doubt.

Knowing these pitfalls can help organizations avoid the most common compliance issues. As independent licensing firm Redress Compliance notes, clear documentation and understanding your standby usage (active vs. passive) are crucial to prevent “license confusion” and unexpected exposure.

Next, we’ll explore how these rules play out in a few real-world scenarios.

Best Practices and Recommendations

Licensing professionals should approach Oracle Active Data Guard with care to ensure compliance while maximizing value.

Here are some best practices and recommendations, distilled from industry advisory experience:

• Perform a License Assessment Before Enabling ADG: Before turning on Active Data Guard in any environment, thoroughly assess your Oracle licensing. Determine the number of processor or NUP licenses required for each environment (primary and standby). Verify that your primary database is properly licensed (with no shortfalls), and then calculate the ADG requirements. It’s wise to involve your Oracle account manager or an independent licensing consultant to validate the interpretation. Catching a licensing requirement upfront is far better than discovering a gap during an audit.
• Document Your Environments and Usage: Maintain clear documentation of where Active Data Guard is deployed, which databases utilize it, and for what purpose. Document the hardware specs (cores, processors, core factors) and the licensing counts for each server. Also, record the purpose of each standby (e.g., DR only, reporting, backups) so that during any internal review or external audit, you can explain which ones should or shouldn’t have ADG licenses. Distinguishing between purely passive standby databases and those with active ADG usage is important to avoid confusion. This documentation will serve as the basis for any compliance evidence provided to Oracle.
• Match Metrics and Track Changes: Ensure the license metric type (NUP vs Processor) is consistent across a given primary-standby pair for all Oracle components. If you change the primary database’s licensing model or hardware (for example, moving to a larger server or from NUP to Processor in a renewal), update the ADG licensing accordingly to match. Keep an eye on core factor changes when upgrading hardware – adding CPUs could double the required ADG licenses if not planned. Regularly reconcile your Oracle Support renewals to ensure you’re renewing the correct number of ADG licenses in line with the database licenses.
• Internal Audits and Monitoring: Conduct periodic internal audits or reviews of Oracle usage. Oracle’s License Management Services (LMS) provide scripts that can detect feature usage – run these internally to see if any Active Data Guard features have been used in environments you haven’t licensed. This can catch accidental usage (for example, a DBA opening a standby read-only out of convenience). Proactively identifying such gaps allows you to remediate (either by acquiring licenses or ceasing the usage) before Oracle’s auditors come knocking. Licensing compliance should be viewed as an ongoing process, rather than a one-time setup.
• Optimize and Right-Size Your Licensing: If cost is a concern, consider ways to optimize. For example, suppose your standby has significantly fewer users than the primary. In that case, it might be worth evaluating NUP licensing (provided it aligns with the primary model and meets minimums) to see if that could be cheaper than processor licensing across both. Or, if you have multiple standbys but only need one active for reporting, you could license ADG on just that one and keep others in pure Data Guard mode. These decisions should be made carefully, weighing the risk and operational needs against the license cost. Ensure any optimization follows Oracle’s policies (no mixing metrics, etc.). In some cases, consolidating standby workloads or reducing the number of standby databases can save on ADG licensing if those standbys were only marginally useful.
• Stay Informed and Get Expert Advice: Oracle’s licensing policies can evolve (for instance, changes in cloud licensing or core factor tables). Stay updated with the latest Oracle licensing documentation and advisories. It’s helpful to consult resources from independent firms, such as Redress Compliance and SoftwareOne, which publish guides on Oracle licensing. These can provide interpretations and examples beyond Oracle’s datasheets. If your organization has a complex setup (e.g., virtualization, hybrid cloud, many options), consider engaging an independent Oracle licensing expert or firm to review your architecture. They can offer an objective assessment and suggest compliance strategies without the conflict of selling you more software. Their insights might help you avoid expensive mistakes and even find cost-saving opportunities within Oracle’s rules.
• Prepare for Oracle Audits: Given Oracle’s rigorous audit practices, it is essential to prepare in advance. Keep all proof of purchase and entitlement for your ADG licenses organized and readily available. Maintain records of your server configurations and usage of ADG features. If audited, respond with accurate data, showing that you’ve licensed ADG wherever it’s in use and understand the rules, which will position you well. An audit should not reveal surprises if you’ve followed the above best practices. The goal is to be audit-ready at any time.

Oracle Active Data Guard Licensing FAQ

What is Oracle Active Data Guard? It is an add-on feature to Oracle Database Enterprise Edition that utilizes a physical standby database to provide advanced data protection, disaster recovery, and improved database availability.

Do I need to license Oracle Active Data Guard for the primary and standby databases? To ensure compliance, Oracle Active Data Guard must be licensed for these databases.

What is the cost of licensing Oracle Active Data Guard? The cost is $11,500 per processor or $230 per Named User Plus (NUP). Licensing is required for both the primary and standby environments.

How do I decide between processor licensing and NUP licensing? Processor licensing is ideal for environments with a large number of users or where it is impractical to manually count them all. NUP licensing can be more cost-effective if you have a limited number of users.

Is Active Data Guard included with Oracle Database Enterprise Edition? No, It is an optional add-on that requires a separate license from the Oracle Database Enterprise Edition license.

What features does Oracle Active Data Guard offer? Features include real-time query, fast incremental backups, automatic block repair, Active Data Guard Far Sync, application continuity, and rolling database upgrades with minimal downtime.

Do I need an Oracle Active Data Guard license for read-only operations on standby databases? It must be licensed if the standby database is used for read-only operations, such as reporting.

How is Active Data Guard licensed in a cloud environment? It is licensed through the Bring Your Own License (BYOL) model or Oracle Cloud subscription-based pricing for cloud environments. The licensing metrics must match the database licenses.

What is the difference between Oracle Data Guard and Oracle Active Data Guard? Oracle Data Guard is included with the Enterprise Edition and provides basic disaster recovery capabilities. Active Data Guard extends these capabilities by allowing real-time query, reporting, and backups on standby databases.

How do I license Active Data Guard if I have a standby database with fewer processors than the primary? Each processor in the primary and standby environments must be licensed, regardless of their differences in processor count.

Can I license Active Data Guard just for the standby environment? No, as the primary and standby environments are part of the data protection and availability solution.

What is the role of the Oracle Core Factor Table in licensing? The Oracle Core Factor Table determines the licenses required based on the processor type. For example, Intel processors may have a core factor of 0.5, which affects the total number of processor licenses needed.

Is there a minimum number of licenses required for Named User Plus (NUP)? Yes, Oracle requires a minimum number of NUP licenses depending on the type of database environment. This minimum must be met for both the primary and standby databases.

What happens if I use Active Data Guard features without proper licensing? This is considered non-compliance, which can lead to penalties during an Oracle audit, including back payments and fines.

How can I ensure compliance with Oracle Active Data Guard licensing? To ensure compliance, match the licensing metrics of Active Data Guard to your Oracle Database Enterprise Edition license, and license both environments (primary and standby). Consult the Oracle Core Factor Table for accurate license calculation.

Read more about our Oracle License Management Services.

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit