Oracle Active Data Guard Licensing

Active Data Guard is where disaster recovery architecture and licensing collide. Teams build a standby for resilience, then open it for reporting to get more value from idle hardware, and in doing so cross a licensing line that is invisible at the console but decisive in an audit. This article separates the free capability from the paid option, explains why a standby is never licence free, and sets out the controls that keep the option contained. It sits under the database licensing pillar and complements the disaster recovery licensing deep dive.

What is Oracle Active Data Guard?

Active Data Guard is an Enterprise Edition option that allows a physical standby database to be open in read only mode while redo from the primary is still being applied. In practice this means the standby can serve reporting queries, offload backups, and support real time read workloads instead of sitting idle waiting for a failover. It also enables features such as automatic block repair, far sync instances, and the ability to run certain workloads against the standby.

The appeal is obvious. Disaster recovery hardware is expensive and usually idle, and Active Data Guard turns it into a productive reporting tier. That productivity is exactly what Oracle charges for, and the option carries its own price line on top of the Enterprise Edition database and any other options in use.

Active Data Guard versus basic Data Guard

Basic Data Guard is included with Enterprise Edition at no extra licence cost. It lets you maintain one or more physical or logical standby databases, ship and apply redo, and perform a switchover or failover. The critical limitation is that with basic Data Guard the physical standby is mounted but not open. It applies changes in the background and is available to take over, but you cannot query it.

Active Data Guard removes that limitation by allowing the standby to be open read only while applying redo. That single capability, real time query against an actively recovering standby, is the dividing line. Everything you can do with a mounted, closed standby is free; the moment you open it for queries while recovery continues, you are using the paid option. The distinction matters as much as the Enterprise versus Standard Edition boundary, because both turn on a capability that looks like a configuration toggle.

Why the standby must be fully licensed

A point that surprises many teams is that the standby database itself requires a full Enterprise Edition licence, with or without Active Data Guard. Oracle treats an installed and running standby as a licensable deployment. The only relief is the limited failover allowance described below. So the cost question is not whether to license the standby, but whether to add the Active Data Guard option on top of the database licence the standby already needs.

When Active Data Guard is in use, it must be licensed for the same number of processors or named users as the standby database, calculated with the same core factor rules that govern the primary. If the standby has the same core count as the primary, the option doubles in quantity across the pair. This mirrors the all or nothing logic that governs every database option, including the wider options and packs set.

What switches Active Data Guard on?

Active Data Guard usage is recorded the moment a standby is opened read only while a redo apply session is active. The database logs this in the feature usage statistics, and like all option usage it is conclusive evidence in a review. Far sync instances and the real time query capability also register. There is no grace period and no soft warning at the console.

The common accidental trigger is a database administrator opening the standby to run a quick report or to verify the standby is current, not realising that opening it read only with apply running is the precise action that uses the option. A second is monitoring or backup tooling configured to query the standby. Both leave a permanent usage record, which is why this option appears so often in the options audit.

The failover and ten day rule

Oracle's licensing documents allow a limited failover provision. An unlicensed spare node in a cluster may take over the production workload for up to ten separate days in a calendar year to cover a failure, without requiring a full licence for that node. This provision is narrow, applies to specific clustered configurations, and is frequently misunderstood as a general right to run a standby for free.

It is not. The ten day rule covers genuine failover events on a passive node, not a standby that is routinely open for reporting. Relying on it to justify an Active Data Guard reporting tier is a misreading that collapses immediately in an audit. The provision interacts with clustered designs in ways covered in the RAC licensing analysis, and any reliance on it should be documented against the exact contract wording rather than the general understanding.

What Active Data Guard costs

Because the option is licensed for the full standby footprint, the cost mirrors the standby's core count. On a symmetric primary and standby pair, adding Active Data Guard effectively adds the option price across both the primary, if it serves as a reader during role transitions, and the standby. The economic question is whether the reporting and resilience value of an open standby justifies the option cost compared with simply provisioning a separate reporting database.

Often it does, because a single managed standby serving both disaster recovery and reporting is cheaper than a standby plus an independent reporting copy. But that calculation must be made deliberately, with the option cost on the table, rather than discovered after the fact. Comparing the option against alternative architectures is the work the database licensing service brings to resilience planning.

How to contain Active Data Guard exposure

Containment is about controlling the open read only action. If the organisation has not licensed Active Data Guard, the standby must remain mounted and closed, and administrators must understand that opening it for even a brief report uses the option. Where reporting from the standby is wanted, the option should be licensed deliberately and the value justified.

The standing controls are scheduled queries of the feature usage views to catch any inadvertent open, clear runbooks that distinguish a permitted closed standby from a chargeable open one, and documented reliance on the failover provision only where it genuinely applies. Where usage has already occurred, an early assessment of the exposure is far cheaper than an audit defence after Oracle's scripts have read the usage history.

The buyer side view

The buyer side discipline on Active Data Guard is to treat the open read only standby as a deliberate purchase, never an operational convenience. License the standby database as the baseline, decide consciously whether the reporting value of an open standby justifies the option, and keep administrators from opening an unlicensed standby for any reason. Monitored continuously and governed by a clear runbook, the option delivers real value where it is paid for and never becomes a silent audit liability. To weigh it against your own disaster recovery design, see the database pillar, the database licensing white paper, or request a consultation.