Oracle Data Guard Licensing for Active and Passive Standbys
Basic Data Guard is included with Enterprise Edition, but the standby database must be fully licensed for its own cores at the same metric as the primary, because the software is installed and the server is running. The standby becomes chargeable for Active Data Guard only when it is opened read only while applying redo, or when block change tracking, far sync, or automatic block repair is used.
Data Guard is the feature most often misunderstood at licensing time, because the replication itself is free with Enterprise Edition while the standby database it creates is not, and a single configuration choice quietly converts a free standby into a chargeable Active Data Guard deployment. This article separates the three distinct costs in a Data Guard topology, the base database licence on the standby, the optional Active Data Guard charge, and the failover allowances, so an estate can run high availability without an unbudgeted finding. It sits under the database licensing pillar and complements the broader disaster recovery licensing guide.
What is Oracle Data Guard?
Data Guard maintains one or more standby databases as transactionally consistent copies of a primary database by shipping and applying redo. It provides protection against data loss and downtime, supports planned switchovers and unplanned failovers, and underpins most Oracle disaster recovery architectures. A physical standby is a block for block copy kept in sync by redo apply; a logical standby applies SQL derived from the redo stream and can differ structurally.
The replication mechanism is part of Enterprise Edition. Where licensing enters is the simple fact that a standby is a full database installation with a running instance, and that installation has the same licence footprint as any other Enterprise Edition database on the same hardware.
What Data Guard is free with Enterprise Edition
The base Data Guard capability is included with Enterprise Edition at no additional option cost. That includes physical and logical standbys, redo transport and apply, switchover and failover role transitions, and the protection modes that govern data loss tolerance. An estate can build a complete primary and standby pair, perform regular role swaps, and recover from a primary failure using only Enterprise Edition licences, provided the standby itself is licensed.
This is the boundary that confuses estates: the software that does the replicating is free, but the second copy of the database that the replication keeps alive is a chargeable installation. Treating Data Guard as a free feature without licensing the standby is the single most common error in this area.
Must a standby database be licensed?
Yes. Oracle licenses installed and running software, not query activity, so a standby database with the binaries installed and an instance applying redo must be licensed for its own core count at the same metric as the primary, using the same core factor. A standby that is mounted but not open still has a running instance applying redo and is therefore fully licensable. The fact that no user is querying it is irrelevant to the base licence.
This means a primary and standby pair on identical hardware carries roughly double the database licence cost, before any option. Estates that size their disaster recovery footprint without accounting for this routinely discover the second licence only when the standby surfaces in an options and feature audit.
When Active Data Guard is required
Active Data Guard is a separately priced option, distinct from the base standby licence. It is required the moment the standby is opened read only while it continues to apply redo, the configuration that allows reporting, ad hoc queries, and backups to run on the standby instead of the primary. It is also required for far sync instances, real time query, automatic block repair, and block change tracking on the standby. The option, its features, and its pricing are covered in detail in the Active Data Guard licensing article.
The trap is that opening a standby read only is a single command, often run to validate that the standby is usable or to offload a report, and it registers permanently in the feature usage views. A standby kept strictly mounted and never opened for queries avoids the option entirely and needs only the base database licence.
The failover and ten day rule
Oracle's ten day failover allowance lets an unlicensed spare node assume production duty for up to a total of ten days per calendar year when the primary node fails. It is widely misread as covering Data Guard standbys. It does not. The allowance applies to a genuine cold failover node in a cluster where the spare is not running Oracle in normal operation. A Data Guard standby is running continuously, applying redo every day, so it falls outside the ten day rule and must be licensed in full.
Understanding which high availability topology qualifies for the allowance and which does not is central to sizing a compliant disaster recovery estate, and it is the same analysis that drives the wider disaster recovery position.
Passive versus active standby licensing
| Standby configuration | Base database licence | Active Data Guard option |
|---|---|---|
| Mounted, applying redo, not open | Required on standby cores | Not required |
| Open read only, applying redo | Required on standby cores | Required |
| Far sync instance | Required | Required |
| Cold failover spare, Oracle not running | Ten day rule may apply | Not required |
How to contain Data Guard exposure
Containment rests on two controls. The first is licensing every running standby for its cores from the outset and building that cost into the disaster recovery design, so the second database is never a surprise. The second is a configuration standard that keeps standbys mounted rather than open unless Active Data Guard has been deliberately licensed, preventing an operator from triggering the option with a single read only open.
The estate should monitor the feature usage views on the standby specifically for real time query and block change tracking, because those entries are the signature of inadvertent Active Data Guard usage. Where reporting genuinely needs to run on the standby, the option should be licensed openly and the benefit weighed against offloading to a separate licensed reporting copy, the kind of modelling the database licensing service performs.
The buyer side view
The buyer side position on Data Guard is to treat the standby as a full database licence and Active Data Guard as a deliberate purchase, never an accident. License every running standby on its own cores, keep standbys mounted unless the option is bought, and monitor the feature usage views so a stray read only open is caught before it becomes a finding. Reserve the ten day rule for genuine cold failover nodes and never apply it to a continuously running standby. Governed this way, high availability stays affordable and audit safe. Begin with the database pillar, study the Active Data Guard detail, and where a standby estate is already in question bring in audit defence or request a consultation. For a related scenario, see Oracle Spatial and Graph licensing.
Common questions.
Is Oracle Data Guard free?
The basic Data Guard capability is included with Enterprise Edition at no extra option cost, including physical and logical standbys with redo apply, role transitions, and switchover. What is not free is the standby database itself, which must be fully licensed for its cores, and the Active Data Guard option, which is a separately priced add on required for read only access while applying redo and several related features.
Do I have to license a passive Data Guard standby?
Yes. A standby database has the Oracle software installed and a running instance applying redo, so it must be licensed for its own processor or Named User Plus count at the same metric as the primary, calculated with the same core factor. The standby being closed or mounted rather than open does not remove the licence requirement, because installation and the running instance are what Oracle licenses, not query activity.
When do I need Active Data Guard?
Active Data Guard is required when the standby is opened read only while it continues to apply redo, which lets reporting and backups run on the standby. It is also required for far sync instances, automatic block repair, real time query, and block change tracking on the standby. A standby kept mounted and not opened for queries needs only the base database licence, not the Active Data Guard option.
Does the ten day failover rule remove the standby licence?
No. The ten day rule allows an unlicensed spare server to take over production for up to ten days per calendar year when the primary fails, but it applies to a true cold failover node, not to a Data Guard standby that is installed and continuously applying redo. A Data Guard standby is a running database and must be licensed regardless of the ten day allowance.
How does Oracle detect Active Data Guard usage?
Oracle reads the feature usage statistics views, which record real time query, far sync, automatic block repair, and block change tracking on the standby with first and last usage dates. Opening a standby read only while applying redo registers as Active Data Guard usage, and the record is permanent, so a single reporting test on the standby can create a finding for the option across the standby's full core count.