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 that enhances 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, ready to take over in case of 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 backing up – all while continuously applying redo 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 provides features that augment the base Data Guard capabilities and enable organizations to use their standby database more productively.

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 transparently improves data integrity and availability.
• 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 fast incremental RMAN backups to be taken on the standby database instead of 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+), this feature permits 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 legal if you have purchased the Active Data Guard option licenses for the environments involved.

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, directly or through any middle-tier, must be counted. 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 like ADG), the minimum is 25 Named User Plus per processor. In practice, a small deployment (with few users) on a powerful server may need to license 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 cheaper. 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 also must be licensed by processors; if NUP licenses the database, ADG must be NUP licensed 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 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: Remember the 25-per-processor minimum rule using 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 is larger than these minimums, but this rule prevents under-licensing small numbers of users on big servers. Also, all human or device users who access the standby for reporting must be counted among the Named Users (typically, they’re the same users who access the primary).
• 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. If a standby database is only used in disaster recovery emergencies or for brief failover testing, and not open for read/write or actively synced beyond those tests, Oracle permits not licensing the standby separately until 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 the benefits of Active Data Guard, you must license the standby despite 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 – but 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 needs to be properly licensed 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 minimums—you can ensure compliance in 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 (real-time query, etc.) 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, under-counting the processors on the standby is an issue; sometimes companies license ADG for the primary’s cores but overlook 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: If using NUP licensing, a common mistake is miscounting the users or forgetting 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, but if the minimum 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 meet the 25-per-processor minimum threshold.
• 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 the virtualization technology is not Oracle-approved for sub-capacity licensing. Oracle generally requires that if soft partitioning (non-approved virtualization like 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, e.g., licensing only vCPUs in VMware, can cause a large shortfall in 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 mistake is not realizing when a feature you enable implicitly requires ADG. For instance, enabling Automatic Block Repair or DML Redirection on a standby database might not be an obvious setting, such as opening the database read-only. 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.

Real-World Active Data Guard Licensing Scenarios

To solidify the concepts, let’s examine a few typical scenarios and how Oracle’s ADG licensing applies in each:

Scenario 1: Single Standby for Failover (Passive DR Only)

Situation: An organization has one primary Oracle Database and one standby in a separate data center purely for disaster recovery. The standby is not used for reporting or queries; it’s only open during DR drills or an actual failover.

Licensing Implication: If the standby remains passive (redo apply only, no read-only usage) and is only activated during emergencies or brief tests, the company might decide not to purchase Active Data Guard. Basic Data Guard (included with EE) covers log shipping and failover capability.

In this scenario, Active Data Guard licensing is not required because none of the ADG features are being utilized – the standby is never opened read-only while the primary is active. The main licensing concern is the Oracle Database license for the standby server.

Oracle’s failover policy (the “10-day rule”) could apply: the standby could be considered a failover node that doesn’t need separate licensing unless it’s used more than a cumulative 10 days per year.

To be safe, many companies still fully license the standby database (especially if it’s continuously applying logs, which technically means the Oracle software is running). However, if the budget is tight and the needs for high availability are modest, they might use the 10-day rule to avoid licensing the standby database.

However, when any Active Data Guard feature is desired (e.g., running a report on the standby), this scenario transitions into the next scenario, and ADG licenses must be obtained.

In essence, for a pure failover standby with no active use, you don’t enable ADG, and thus you save on ADG option costs (possibly even saving on the DB license if you adhere strictly to the failover node policy). But this comes at the cost of not leveraging the standby for additional value.

(Note: Even in this passive scenario, understand Oracle’s software installation rules. If the standby is constantly on and recovering, many firms interpret that as requiring a database license. The “10-day” free failover allowance tends to apply to truly idle standby that is only started during failover/tests, not one performing continuous recovery. Always verify with Oracle or a licensing expert if considering not licensing a standby.)

Scenario 2: Standby for Read-Only Reporting (“Active” Data Guard)

Situation: A financial services company runs a mission-critical Oracle Database (Enterprise Edition) for online transactions. They maintain a synchronized physical standby database.

To maximize utility, they open the standby database in read-only mode during normal operations to offload heavy reporting queries and analytics, ensuring the primary isn’t slowed down by these workloads. The standby still receives and applies redo in real-time so that it’s up to date.

Licensing Implication: This is a textbook use case for Oracle Active Data Guard – real-time query on the standby. To comply, the organization must license Active Data Guard for both the primary and the standby servers. Each server will need the ADG option licenses in the same metric/quantity as the database. For example, suppose the primary database is licensed for eight processors of Oracle EE.

In that case, eight processors of ADG should be licensed on the primary, and if the standby server has eight processors as well, another eight processors of ADG should be licensed on the standby. The total licensing here effectively doubles the ADG cost of a single server because two servers are involved.

To illustrate with actual numbers: Suppose the primary has four processors (after core factor) and the standby has four processors. Active Data Guard is priced at $11,500 per processor. So the primary would need ADG licenses costing 4 × $11,500 = $46,000, and the standby would also need 4 × $11,500 = $46,000, for a total of $92,000 in ADG list license fees to enable this configuration (plus annual support).

If the standby had fewer processors, you’d license correspondingly fewer on that side – e.g., if the standby has two processors, that side would cost $23,000. Named User Plus could be used instead if the user population is known and limited (with the requirement that the same user licenses cover both environments).

For instance, if only 50 named analytics users ever access the databases, one could license 50 NUP for ADG covering those users. At $230 per Named User (list), that’s $11,500 for the ADG option – but you would need to license both primary and standby with those 50 users, effectively 100 NUP licenses total if counted separately.

In practice, Oracle would require at least 50 named user licenses of the ADG option (matching the 50 for the DB) and would consider them to cover both sites as long as it’s the same 50 users (named licensing isn’t typically double-counted for identical users on two installations).

The safe interpretation is that you purchase the option for each installation. The key is that reporting on a standby is exactly what Active Data Guard is sold for and is 100% licensable.

Beyond cost, note that by licensing ADG, the company gets more than just read-only capability – they also benefit from ADG features like automatic block repair and others listed earlier, which add to reliability.

Many firms find this worth the additional expense, as it significantly increases the standby system’s ROI. Just be sure to factor the ADG option into your Oracle license counts when budgeting for a DR configuration that will be used for reporting.

Scenario 3: Standby for Backup Offloading

Situation: An organization’s primary Oracle Database is heavily used 24/7. To minimize the impact on the primary during backups, backups are taken from the standby database.

The standby continuously applies redo and uses block change tracking to perform fast incremental backups. End-users may not use the standby for queries, but the backup tools can provide read-only access.

Licensing Implication: This scenario still involves Active Data Guard, although interactive querying might be minimal. An Active Data Guard feature is the ability to do fast incremental backups using Block Change Tracking on a physical standby. Therefore, the ADG option must be licensed on both the primary and standby to remain compliant while offloading backups.

Some might wonder: “What if we don’t open the standby and just use it for backups?” – If backups are done with the standby in read-only mode or using the ADG BCT feature, that counts as Active Data Guard usage. One could attempt to do backups by temporarily stopping redo apply and opening the standby without ADG, which means the standby lags during the backup. You lose the real-time sync – an operationally complex approach, not the intended usage pattern.

The supported and streamlined approach is to use ADG and have the standby open for backups without interruption to redo apply, which requires licensing. Thus, the licensing model is the same as Scenario 2: both servers must be licensed for ADG. The cost will similarly depend on the processors or users involved.

The organization might justify this cost by the benefit of offloading backup overhead from the primary (e.g., if backups can be done 20x faster and without impacting primary performance, that can be very valuable). Nonetheless, from a licensing perspective, there is no discount or alternate rule for “just using it for backups” – it’s an ADG use case, hence a licensed feature.

(Side note: In this scenario, even though end-users aren’t querying the standby, if Processor licenses the primary, it may make sense to license ADG by Processor as well. If NUP licensed the primary (say, there are 100 users of the DB), one might still have to license ADG by NUP, covering those same 100 users, because the backup processes themselves don’t count as users, but the option license must match the metric of the DB. Always align with the database’s licensing model when in doubt.)

Additional Scenario Considerations

The above scenarios cover the common cases requested (failover-only vs. reporting vs. backups). In practice, some deployments use Active Data Guard simultaneously for multiple purposes (e.g., a standby that handles reporting and backups and even acts as a read-mostly database for certain applications).

The same principles cover any such use: as long as ADG is enabled, license both sides fully.

For multiple standby databases: If you have one primary and two standbys and open both for read-only workloads, you would need to license Active Data Guard on the primary and each of the two standby servers.

Oracle does not give a “bulk discount” for multiple standbys – each is an independent installation that needs licensing. Some organizations with many standbys consider whether all need ADG or only some (perhaps one is for reporting, others are purely for failover).

In such cases, you could license ADG only on the standby you are open to reporting, and not on a purely passive standby. That is allowed as long as the passive standby never uses ADG features. Just be extremely careful to segregate those; if a standby without an ADG license is accidentally opened read-only or uses an ADG feature, you’d be in violation.

Active-Active replication setups (e.g., Oracle GoldenGate or bidirectional replication alongside ADG) typically involve separate licensing considerations beyond ADG (GoldenGate has its licensing, etc.). However, suppose ADG is part of an active-active strategy (perhaps two databases, each acting as a standby for the other somehow). In that case, both are primaries and standbys, and both must be fully licensed for ADG.

For Oracle Cloud scenarios: If using Oracle’s Database Cloud services, customers can enable Active Data Guard by subscribing to the appropriate service level (for example, Oracle offers a High Availability cloud service that includes ADG).

If using BYOL in the cloud, ensure you have sufficient on-prem licenses to cover the cloud deployment cores and that support is active.

The main point is that cloud does not eliminate the need to license ADG properly; it just changes how you account for the cores (often by OCPU or vCPU counts).

Best Practices and Recommendations

Licensing professionals should carefully approach Oracle Active Data Guard 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 how many processor or NUP licenses you will need for each environment (primary and standby). Verify that your primary database is properly licensed (no shortfalls), then calculate 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 use it, and what for. 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 form the basis of 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 to match accordingly. Keep an eye on core factor changes if you upgrade hardware – adding CPUs could double your needed 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 treated as an ongoing process, not 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 need versus 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 like Redress Compliance, SoftwareOne, or others who 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, prepare in advance. Keep all proof of purchase and entitlement for your ADG licenses organized. 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 many users or where it is impractical to count them all. NUP licensing can be more cost-effective if you have limited 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 Enterprise Edition and provides basic disaster recovery. 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 both environments (primary and standby), and 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 License Management Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit