Oracle Active Dataguard Licensing

How Does Oracle Active Data Guard Licensing Work?

• Separate License: A separate license from the Oracle Database is required.
• Cost: USD 11,500 per processor or named user plus.
• Nodes: Must be licensed on both primary and standby nodes.
• License Matching: The number of licenses must match Oracle Database Enterprise Edition.
• Core Factor Table: Used to determine license requirements based on cores.
• Inclusions: This can be included in an Oracle Unlimited License Agreement (ULA).

Oracle Active Data Guard Licensing

Oracle Active Data Guard is a powerful add-on to Oracle Database Enterprise Edition that enables organizations to use a standby database for real-time queries, reporting, and backups while the primary database is running.

However, Active Data Guard is not included for free – it requires separate licensing on both the primary and standby environments, and failing to license it correctly can lead to significant compliance risks and costs.

This advisory explains how Active Data Guard licensing works, including its list price of $11,500 per processor, licensing rules (e.g., both sites must be licensed under the same terms), common pitfalls to avoid, and best practices to maximize value while staying compliant.

Understanding Active Data Guard vs Data Guard

Oracle Data Guard (standard feature) is included with Oracle Database Enterprise Edition at no extra cost.

It allows you to maintain one or more standby databases for disaster recovery.

Still, these standbys typically remain passive (in recovery mode only) and cannot be open for read/write while synced to the primary. In contrast, Oracle Active Data Guard (ADG) is an optional licensed feature that extends the capabilities of Data Guard.

With Active Data Guard, a physical standby database can be opened read-only for reporting, queries, or backups while it continuously applies redo logs from the primary.

This “active” use of the standby offloads work from the primary (improving performance and ROI on the DR system) and provides advanced features like real-time query, fast incremental backups via block change tracking, automatic block corruption repair, and support for rolling upgrades.

The key difference is that Basic Data Guard is included with the Enterprise Edition and addresses disaster recovery needs, whereas using any Active Data Guard features requires the purchase of an Active Data Guard license.

• Included Data Guard features (free with EE): Synchronized standby databases for failover, redo log shipping, automated failover (with Data Guard Broker), etc. The standby is usually in a mount state and is only opened during failover or testing.
• Active Data Guard features (licensed option): The standby database is open read-only for real-time reporting and analytics, with backup offloading (backups run on the standby). Additionally, Fast Sync ensures zero data loss across distances. Automatic Block Repair is available between the primary and standby, as well as other configurations. These features enhance availability and performance but trigger the licensing requirement for ADG.

In summary, Data Guard vs Active Data Guard comes down to usage: if your standby remains purely a passive failover, no extra license is needed; if your standby is actively used for queries or other workloads, Active Data Guard licenses are required for compliance.

Licensing Models and Pricing

Oracle Active Data Guard is licensed as a separate option to Oracle Database Enterprise Edition.

It can be licensed under the same metrics as the database itself, either per Processor or per Named User Plus (NUP):

• Processor License: Priced at $11,500 per processor (perpetual license, list price). This metric is typically used for server-based licensing when an unlimited or unpredictable number of users will access the database. Oracle defines “processor” for licensing based on the number of CPU cores and a core factor (e.g., most Intel cores have a 0.5 factor, so two cores = 1 licensed processor). Annual support for Active Data Guard is an additional ~22% of the license price (about $2,530 per processor per year at list).
• Named User Plus License: Priced at $230 per named user (list). This model is only viable if you have a known, limited user population. Oracle requires a minimum of 25 Named User Plus licenses per processor (per core factor unit) for Enterprise Edition databases and their options. In practice, NUP licensing for ADG is less common in large enterprises, but it can save cost in small environments (e.g., a dev/test or a production system with <100 total users).

Cost example: If you have a primary database with four processors licensed and a standby with four processors, enabling Active Data Guard will require licensing a total of eight processors for ADG (four on the primary and four on the standby). At $11,500 each, the list price for licenses is $92,000, plus approximately $20,240/year in support fees.

If you had only two processors on standby, the standby ADG cost would be halved accordingly. For a smaller user-base scenario, suppose only 40 named users ever access the databases; you could license Active Data Guard by NUP instead (minimum 25 per processor).

If the environment has four processors (which implies at least 100 NUP licenses are required), 100 NUP licenses at $230 total $23,000, potentially offering a lower cost than processor licensing – but this only works if you truly have a limited user count.

All licensing metrics for ADG must match the database’s licensing model (you cannot mix processor licensing on the DB with NUP on the ADG option or vice versa).

Below is a summary of Oracle’s list pricing for Active Data Guard compared to the base database for context:

Real-world contract note: Oracle sometimes offers discounts off these list prices depending on the volume of licenses or as part of larger enterprise agreements.

Active Data Guard can also be included in an Unlimited License Agreement (ULA).

In a ULA, you pay an up-front fee to deploy unlimited instances of certain Oracle products (which can include ADG) during the ULA term.

This can be a cost-effective strategy if you plan to use Active Data Guard extensively across many servers, but it requires careful negotiation and forecasting.

Always engage your Oracle account manager or a licensing advisor to explore discount programs, including pre-purchasing as part of an enterprise agreement, especially if Active Data Guard is critical to your architecture.

Key Licensing Rules and Compliance

To use Oracle Active Data Guard legally, organizations must adhere to Oracle’s licensing policies.

The following are critical rules and requirements to keep in mind:

• License Both Primary and Standby: If you enable Active Data Guard, every environment that is actively running the database with ADG features must be licensed. This means the primary database server and each standby server in an Active Data Guard configuration require the ADG option license. It’s not enough to license just one side – Oracle’s policy is that the standby is an active part of the system, so it requires the same licensing as the production system.
• Matching License Quantities and Metric: The number of ADG licenses must match the Oracle Database licenses on each server. For example, if your primary database is licensed for eight processors of Enterprise Edition, you should have eight processors of Active Data Guard licensed on that primary. If the standby server has eight processors, it also requires eight processor licenses of ADG. The licensing metric (Processor vs. NUP) should match the database’s metric. You cannot mix metrics (e.g., you cannot license the database by processors but try to license ADG by named users on the standby). All Oracle database options must follow the base database’s licensing model for consistency.
• “10-Day Rule” (Failover Policy) – Not Applicable to Active Usage: Oracle’s license rules include a failover policy that provides some relief for passive disaster recovery servers. Under this policy, a standby that is only used during actual failover or brief DR tests can be operated unlicensed for up to a total of 10 days per year (in emergencies or scheduled tests) without requiring a full license, as long as it’s truly idle otherwise. However, this exception does not apply if you are using Active Data Guard features. The moment you open a standby database for read-only access, or use any ADG-only capability while the primary is running, that standby is no longer considered “idle passive DR.” The 10-day rule is intended for cold or warm standby systems that are typically shut down or in maintenance mode. If you are using Active Data Guard, you must fully license the standby from the start. In other words, there is no free ride for a standby that’s actively querying or syncing in real-time beyond pure failover readiness.
• Counting Cores and Users Properly: When licensing by processors, ensure you count all physical cores (with the appropriate core factor). If the standby hardware has a different core count than the primary, you still need to license the actual core count deployed on each. For Named User Plus licensing, count all distinct individuals (or devices) that will access the Oracle Database environments (primary or standby). Remember the minimums: Oracle requires at least 25 named user licenses per processor (for both the database and its options). If you have, say, eight cores (with factor 0.5 = 4 processors for licensing) on a server, the minimum NUP would be 100 for that server. Ensure you meet the minimum license counts; undercounting users or processors is a compliance violation that Oracle’s audits will flag.
• Applies to On-Premises and Cloud: Oracle does not waive ADG licensing requirements just because you run in the cloud. Suppose you Bring Your License (BYOL) to a cloud IaaS or Oracle Cloud Infrastructure. In that case, you must allocate enough of your existing licenses to cover both primary and standby instances (following Oracle’s cloud core counting formulas – for example, in AWS, Oracle counts 2 vCPUs as one processor license). Oracle’s Cloud database services also offer Active Data Guard as an add-on subscription. For instance, in Oracle Cloud, enabling ADG on a Database Cloud Service incurs an additional cost (on an hourly or monthly basis). The key point is that cloud deployments must also be properly licensed for Active Data Guard, either via BYOL or via the cloud service subscription. There’s no loophole – the rules on licensing the standby and primary remain fully in effect.

By following these rules – licensing all active environments, using the same metric and counts as the base database, and respecting any user or processor minimums – you can ensure compliance with Active Data Guard licensing.

It is wise to document your license allocations for both primary and standby and review them whenever you change hardware, core counts, or user counts, to maintain alignment with Oracle’s policies.

Common Pitfalls and How to Avoid Them

Licensing Oracle products can be complex, and Active Data Guard has some common pitfalls that organizations should be wary of.

Here are frequent mistakes and how to avoid them:

• Assuming Data Guard = Active Data Guard: A common mistake is enabling Active Data Guard features (such as opening the standby database in read-only mode) without realizing it’s a paid option. Many assume that since Data Guard is included with Enterprise Edition, using the standby for queries or backups is also free; however, this is not the case. Pitfall to avoid: Don’t use the standby for any active workload unless you have purchased the ADG licenses. Educate DBAs and architects that “active” use of the standby triggers a licensing requirement. In Oracle’s terminology, “Active Data Guard” is a separate product – ensure your team is aware of the difference.
• Not Licensing the Standby Environment: Some companies license the ADG option on the primary database but forget to license the standby server, thinking of it as “just a copy” or a non-production system. This is non-compliant. If an Oracle audit finds an active standby being used without an ADG license, your organization will be at risk for back licensing fees and penalties. Avoid this: Always license each standby that is open and syncing. In a multi-standby setup, each one using ADG must be licensed. Also, double-check that the processor counts match – if the standby has more cores than the primary, you may need more licenses on that side.
• Mixing Licensing Metrics: Oracle’s rules forbid mixing metrics for the same product deployment. A scenario to avoid is licensing your primary database with Named User Plus licenses and then trying to license Active Data Guard on the standby by processors (or vice versa) to save money. This will not pass an audit. Avoid this pitfall: Stick to one metric for both the database and all options, such as ADG. If you originally licensed your database per processor, license ADG per processor as well (even if user counts are low). If NUP licenses you, then acquire NUP licenses for ADG in the same quantities as needed.
• Ignoring Minimums and User Counting Rules: When using Named User Plus licensing, a common mistake is undercounting or failing to meet minimum requirements. For example, you might think that if only 10 analysts run reports on the standby, you only need 10 NUP licenses for ADG. In reality, if your environment has two processors, Oracle’s minimum is 50 NUP (25 per proc) for that option. Conversely, ensure you’re not over-counting the same user on both primary and standby – the same named user accessing both counts as one user license, not two. Avoid this: Adhere to the 25-per-processor minimum rule and count all human and non-human users that access the database. When in doubt, obtain clarity on NUP counts from Oracle or a licensing expert before proceeding with true-up or purchase.
• Virtualization and Partitioning Mistakes: In virtualized environments (such as VMware), some users assume they only need to license the vCPUs assigned to the Oracle instance. Oracle’s policy regarding “soft partitioning” is that you must license the full physical server cores, unless you are using an approved hard-partitioning technology. This means if your standby runs on a VM in a cluster, you might inadvertently need to license more cores than you planned. Avoid this: Review Oracle’s partitioning licensing policies. If using VMware or a similar platform, consider constraining Oracle to a dedicated host or utilize Oracle-approved partitioning (such as Oracle VM with hard partitioning or Oracle Linux KVM with CPU pinning) to limit the number of licensable cores. For Active Data Guard, the licensing must account for the actual underlying hardware where the standby could run or fail over. This is a complex area – involve your infrastructure team and possibly Oracle to ensure you’re correctly licensing in virtual or cloud deployments.
• Backup-Only Standby Assumptions: Some organizations think if the standby is only used for backups (no interactive reporting), they might not need ADG licenses. However, the ability to do fast incremental backups on a physical standby using Oracle’s Block Change Tracking is an Active Data Guard feature. Even just opening read-only for backups or using that feature requires an ADG license. Avoid this misunderstanding: If you offload backups to the standby without shutting down redo apply, you are using Active Data Guard. Plan to license it accordingly. The alternative (stopping recovery to perform a backup and then resynchronizing manually) is possible without ADG, but it is cumbersome and not usually worth the risk or downtime.

By being aware of these pitfalls, you can take proactive steps to avoid them.

Regularly educate your technical teams on what triggers license needs. It’s often helpful to implement internal checks or monitoring – for instance, have a policy that any use of ACTIVE Data Guard features in an Oracle environment require a licensing review.

Avoid “accidental” usage of ADG by clearly distinguishing test/dev environments (where you might toggle ADG on for a quick performance test – even that is technically not allowed without a license).

In short, treat the standby with the same level of license scrutiny as the primary when it’s actively used.

Best Practices and Optimization Tips

Managing Active Data Guard licensing requires a balance between maximizing the technology’s benefits and controlling costs.

Here are some best practices and strategies for Oracle licensing and contract negotiation related to ADG:

• Evaluate the Need vs Cost: Before enabling Active Data Guard, perform a cost-benefit analysis. Quantify the performance gains (e.g., improved report response times, reduced load on primary, faster backups, higher availability) against the licensing costs if the standby will significantly improve operations, which often justifies the expense. If not, you might delay or skip ADG to save costs. Use this analysis in budgeting and in justifying the license purchase internally.
• Include ADG in Early License Planning: It’s often easier (and cheaper per unit) to buy the Active Data Guard licenses up front during an initial purchase or renewal negotiation, rather than later as a one-off. If you know a project will require ADG, bundle it when you negotiate your Oracle agreement. Oracle may give better discounts when ADG is part of a larger deal or when extending an Enterprise Agreement.
• Consider an Unlimited License Agreement (ULA) if Appropriate: If your organization has many Oracle databases and plans to broadly deploy Active Data Guard across them, an Oracle ULA can be a strategic option. In a ULA, you pay a fixed fee for unlimited use of specified Oracle products (for a term like 2-3 years). For example, including Active Data Guard in a ULA means you could deploy it on as many processors as you want without counting, during the ULA period. This can remove the per-core cost barrier for widespread adoption. However, ULAs require careful management, and you must certify usage at the end of the period. Consider this only if you have the scale and license management maturity to handle it.
• Leverage Oracle’s Cloud or Alternative Solutions: If you are moving to the cloud, compare the cost of using Oracle’s own Database Cloud services, where Active Data Guard can be toggled on as a service. In Oracle Cloud (OCI), for instance, enabling ADG on a database service incurs an hourly charge rather than a full, perpetual license – this may be more cost-effective for short-term needs or if you prefer an OPEX model. Additionally, if full Active Data Guard licensing is too costly, consider whether Oracle Standard Edition High Availability (SEHA) or third-party replication tools (if you’re on Standard Edition or want a cheaper DR) could meet some requirements at a lower cost. In enterprise environments, however, the integrated ADG features often justify sticking with Oracle’s solution, provided the budget allows.
• Keep Documentation and Proof of Compliance: Always document the location and method of Active Data Guard deployment. Maintain a license inventory that shows you have X number of ADG licenses covering Y processors or Z users on both primary and standby systems. Keep proof of purchase and Oracle contracts on file for future reference. It’s also wise to log usage: for instance, if you ever open a standby database (even briefly), note the date and reason. In the event of an audit, this documentation helps demonstrate compliance or explain usage under policies such as the 10-day rule for emergency failovers.
• Disable ADG Features if Not Licensed: Oracle databases have initialization parameters and features that, if used, indicate Active Data Guard usage (for example, opening a standby read-only while recovery is running, or using ALTER DATABASE RECOVER MANAGED STANDBY with the DISCONNECT which allows read-only mode. If you have not licensed ADG, ensure these features are not accidentally enabled. Consider using Oracle’s feature usage tracking views or audit tools to alert if ADG features are used. Some organizations proactively set standby databases to prevent open read-only access unless a license is acquired. In short, treat ADG like any paid software: don’t use what you haven’t licensed.

Following these practices will help ensure you derive the high availability and performance benefits of Active Data Guard while keeping your organization audit-ready and cost-efficient.

Oracle’s licensing can be daunting, but with careful planning and regular oversight, you can avoid surprises and fully leverage your standby databases.

Recommendations

• License Active Data Guard from Day 1 if you plan to use it: Don’t wait for an audit – purchase the ADG option for all required processors or users on both primary and standby when designing an active standby solution.
• Align ADG licensing with your database licenses: Use the same metric (Processor or NUP) and license counts as your Enterprise Edition database to stay compliant and simplify management.
• Audit your standby usage regularly: Periodically verify that no standby databases are being opened for read-only or backup use without proper licensing. If they are, either stop that usage or procure the ADG licenses.
• Take advantage of Oracle’s policies wisely: If you have a truly passive standby (no reporting, no active syncing beyond apply), consider Oracle’s 10-day rule to potentially save on licensing, but strictly limit usage and document any activation.
• Negotiate in bulk: When possible, include ADG in larger licensing deals or ULAs to get volume discounts. A well-negotiated ULA or enterprise agreement can substantially reduce the per-processor cost of Active Data Guard.
• Educate and enforce internally: Ensure that your DBA team and IT architects are aware that Active Data Guard is a licensed product. Establish internal guidelines that require no one to enable ADG features without business approval and proper licensing in place.
• Plan for cloud and virtualization properly: If deploying ADG in cloud or virtual environments, consult Oracle’s cloud licensing guide or experts to ensure you license the correct number of cores. Don’t assume it’s automatically covered – BYOL rules still apply.
• Monitor Oracle’s updates: Oracle’s licensing policies and prices are subject to change. Keep an eye on updated price lists or Oracle licensing documentation each year, especially if you plan new deployments, to avoid any surprises (e.g., new features that require ADG or changes in pricing).
• Maintain records for compliance: Keep detailed records of your Oracle licenses, ADG deployments, and usage logs. This will prepare you for any audits and also help in internal reviews of whether the ADG investment is delivering value.

Checklist

• Confirm standby usage: Review all Oracle standby databases in your environment – are any open for read-only access or used for backups while the primary is running? Identify where Active Data Guard is in use (or planned).
• Verify license purchase: Ensure you have purchased Oracle Active Data Guard licenses for every processor (or named user) on each primary and standby that uses ADG. The license count and type should mirror your database license.
• Match metrics and counts: Double-check that the licensing metric (Processor vs NUP) is consistent between your Oracle Database and Active Data Guard. Verify that you’ve counted all physical cores correctly and met the minimum named user requirements if applicable.
• Apply the 10-day rule carefully: If you are relying on Oracle’s grace policy for an unlicensed failover standby, make sure that the standby is never used for production read/query purposes and maintain a log of any activations (ensuring they do not exceed 10 days per year).
• Document and educate: Keep documentation of your Active Data Guard licensing (contracts, purchase orders, and deployment diagrams). Educate your technical teams about these licensing requirements to prevent accidental non-compliance.

FAQ

Q: Do we need to license the standby database for Active Data Guard, or just the primary?
A: You must license both the primary and every standby that is part of an Active Data Guard configuration. Oracle requires that any server actively running the database (applying redo and open for queries/backups) be fully licensed for the ADG option. Only purely idle, emergency-only standby databases are exempt (and even then with strict limitations). If the standby is “active” in any way, include it in your license count.

Q: Is Active Data Guard included in Oracle Enterprise Edition by default?
A: No. Active Data Guard is not included with the Enterprise Edition; it is a separate licensed option. Oracle Database Enterprise Edition includes basic Data Guard (for maintaining a standby for failover purposes). Still, if you want to open the standby for read-only use or use other advanced Data Guard capabilities, you must purchase the Active Data Guard add-on. The cost is separate from your database license.

Q: Can we use the standby database for reporting without buying Active Data Guard licenses?
A: Only if you are willing to forego real-time sync and accept potential downtime. In other words, to stay license-compliant without ADG, the standby should not be open while the primary is running. You could temporarily open a standby read-only by pausing recovery (breaking real-time sync), but this is not the Active Data Guard mode – it’s a manual workaround, and the standby will lag. Oracle’s licensing is clear: the moment you use the standby concurrently for queries or backups while the primary is active, you need Active Data Guard licenses. If reporting needs are important, it’s safer to license ADG or consider Oracle’s other features (like Oracle GoldenGate for data replication to a reporting database, which has its license, or doing reports on a snapshot standby with careful control – but that can be complex). Generally, using a standby for live reporting requires an ADG license.

Q: Is it possible to license Active Data Guard by Named User Plus instead of by Processor to save money?
A: Yes, Oracle allows Active Data Guard to be licensed by Named User Plus (NUP), provided NUP licenses your database itself and you meet the minimum required quantities. If you have a small, definable user population, this can sometimes result in reduced costs. For example, a development environment or a departmental system with 30 users could use NUP licensing for the database and the ADG option. However, in an enterprise with hundreds or thousands of users (or unknown users), NUP licensing isn’t practical – you’d then license per processor. Remember that even with NUP, the count of licenses for ADG should equal at least the number of users licensed for the database, and you must cover both primary and standby users (though overlapping users aren’t double-counted). Always calculate if NUP truly saves cost after meeting Oracle’s minimum; in many cases, especially for production, you’ll still end up with a large number of NUP license,s so that processor licensing can be simpler.

Q: How can we reduce the cost of Active Data Guard licensing?
A: There are a few approaches to manage or lower the cost:

Review Support Renewals: Over time, support costs 22% annually. If a project using ADG is retired or consolidated, ensure that the licenses are terminated or support is negotiated. Additionally, suppose you have been paying support on licenses you’re not using. In that case, you may want to discuss with Oracle the possibility of repurposing that budget towards ADG or other necessary licenses. Essentially, regularly audit your Oracle license utilization so you’re only paying for what adds value. Base, Active Data Guard helps improve the primary database’s performance.

Negotiate Volume Discounts: Oracle sales can often offer discounts when purchasing multiple licenses or as part of a broader agreement. Engage in negotiations – highlight your loyalty or multi-year plans to utilize Oracle technology, and you may receive a better price than the list price.

Leverage an Enterprise Agreement or ULA: As mentioned, including ADG in an enterprise license agreement (like a ULA or ELA) can spread or cap the cost. It converts the cost into a fixed investment for unlimited use, which may be beneficial if you foresee future expansion.

Optimize Usage: Deploy Active Data Guard only where it provides clear value. You might not need it for every database. Some less critical systems might manage with basic Data Guard (no active use), which incurs no extra cost. Concentrate your ADG licenses on the systems that truly need continuous availability and offload capabilities.

Cloud Options: If you’re open to cloud services, consider Oracle’s Database Cloud Service, where you pay a subscription fee. The incremental cost to enable ADG in the cloud might be lower over the short term than buying perpetual licenses, especially for temporary projects or DR instances that you don’t run 24/7.

Read about our Oracle Licensing Assessment Service.

Would you like to discuss our Oracle Advisory Services with us?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Message *

Submit