Is Active Data Guard a paid option?
Active Data Guard is a paid option, licensed separately per processor on the standby database, and it is one of the easier options to enable without meaning to. It sits on top of Enterprise Edition and the standby it runs on must carry its own processor licenses for the option, counted through the core factor table just like the primary. The capability it unlocks is real and useful, which is precisely why a standby gets opened for it without the licensing decision being made deliberately.
The contrast that matters is with basic Data Guard, which is free. Enterprise Edition includes the ability to maintain a standby database that stays in sync with the primary and is ready to take over if the primary fails. That standby sits closed, in recovery mode, applying changes but not serving users. Nothing about keeping that closed standby requires the paid option. The line is crossed only when the standby is opened for active use, and knowing exactly where that line falls is the whole compliance question.
What is the difference between Data Guard and Active Data Guard?
The difference is whether the standby is open: basic Data Guard keeps the standby closed in recovery mode, while Active Data Guard opens it for read only queries and other active features as it stays in sync. With basic Data Guard the standby is a quiet insurance policy, receiving and applying the primary's changes but invisible to applications until a failover. It costs nothing beyond the Enterprise Edition licenses the database already needs, because it is part of the core product.
Active Data Guard changes the standby from passive to working. Opened for read only access, it can serve reporting queries, offload work from the primary, and support additional features while remaining a valid failover target. That dual role, simultaneously a live read replica and a standby, is the value Oracle charges for. The trap is that opening the standby can happen as a configuration choice that looks operational rather than commercial, so a team gains the benefit of Active Data Guard without registering that it has begun using a licensed option.
| Configuration | License needed | Buyer move |
|---|---|---|
| Closed standby in recovery | Enterprise Edition only | Keep standby closed unless licensed |
| Standby open read only | Active Data Guard option | License or close the standby |
| Failover up to 10 days a year | 10 day rule, no license | Record failover dates |
| Standby run as production | Full license | License the standby fully |
How does the 10 day rule apply to a standby?
The 10 day rule lets an unlicensed failover node take over for a failed primary for up to ten separate days in a year without needing its own license, and it covers genuine failover, not active use. When the primary fails and the standby steps up to run production, that is the scenario the rule protects: a limited, exceptional takeover while the primary is restored. As long as the cumulative time stays within ten separate days across the year, the failover node does not require a full license for that use.
The rule is easy to misread as broader than it is. It does not license an Active Data Guard standby that is open for read only queries during normal operations, because that is active use rather than failover. It does not cover a standby that is effectively run as a second production system. And it counts days carefully, so a series of failovers can exhaust the allowance. The buyer move is to record failover events with their dates, so the 10 day allowance can be applied accurately, and to keep that allowance separate in the analysis from any Active Data Guard usage, which is a different licensing question entirely.
How does Active Data Guard surface in an audit?
Active Data Guard surfaces in an audit when the feature usage data shows the standby was opened for active use, and Oracle reads that as option usage requiring a per processor license on the standby. The same feature usage views that record any option also record Active Data Guard, so opening the standby leaves a trace. In an audit, that trace becomes a finding, and because the standby carries its own processor count, the finding is sized like a second licensed database rather than a small add on.
Audits are a sales channel, and a standby is fertile ground because the configuration is technical and the licensing consequence is invisible in daily operations. Oracle's preliminary findings arrive inflated at list price, so an Active Data Guard claim across multiple standbys can be large. The buyer move is to review the usage data before it leaves, establish whether the standby was genuinely opened for active use or merely capable of it, and apply the 10 day rule correctly to any failover. An independent line by line review of findings typically cuts claims by 60 to 80 percent, and standby claims that confuse failover with active use are a frequent place to recover value.
How do you keep Data Guard configurations compliant?
You keep Data Guard configurations compliant by deciding deliberately whether each standby is closed, failover only, or licensed for active use, and then configuring it to match that decision. A standby that is meant to be a free insurance policy should stay closed in recovery mode, so it cannot accidentally register Active Data Guard usage. A standby that genuinely needs to serve read only queries should carry the Active Data Guard license for its processors. The expensive position is the accidental middle, where a standby is opened for convenience without the license that opening requires.
Governance ties this together. The estate map should record, for every standby, its configuration, whether it is open or closed, what it is licensed for, and the dates of any failover events. A periodic internal review checks the feature usage data against that record, catching a standby that drifted open before it becomes a finding. This is the same options discipline that contains accidental pack usage across the estate: detect the usage on your own schedule, configure the systems to match the licenses held, and document the failover events so the 10 day rule can be claimed with confidence rather than reconstructed under audit pressure.
The next step
This article is part of our Options and Management Packs cluster. Read the pillar, the Oracle database licensing guide, for the full picture, and these related reads: the Enterprise Manager click that costs millions, and technical locks that prevent accidental use.