Oracle Disaster Recovery Licensing

Disaster recovery is where good resilience engineering meets unforgiving licensing rules. The instinct to keep a warm standby ready, or to test recovery regularly, is exactly the behaviour that creates a licence requirement, because Oracle generally licenses any installed and running database the same as production. This article sets out how standby, failover, and backup servers are treated, and where the few exceptions apply. It builds on the database pillar and connects to the RAC licensing rules.

How is Oracle disaster recovery licensed?

The default rule is that a disaster recovery server must be licensed exactly like a production server, with the same edition, the same metric, and the same options. Oracle does not offer a general discount for non production or standby use, a rule set out in full in the non production licensing article. The licence requirement attaches to the installation and operation of the software, not to whether the server is currently serving users, so a standby that is installed and running is licensable even if no one connects to it.

There are only two narrow ways out of this: a true cold backup that is not installed and running, and the limited failover allowance for a single cluster node. Everything else is licensed as production. This is the single most important fact about disaster recovery licensing, and the source of most surprises.

Active and passive standby

A standby database that continuously receives and applies redo from production is installed and running, and is therefore licensed like production. This is true whether the standby is open for read only access or simply applying changes in the background. The act of applying data is operation of the software, which triggers the licence, so a passive standby is not a licence saving over an active one.

The consequence is that a typical primary and standby pair doubles the licence requirement: both servers are fully licensed, including every option in use on production. If production runs Partitioning and the management packs, the standby needs them too. This doubling is why disaster recovery is a major cost line and must be modelled deliberately, not assumed to be free or discounted.

The ten day failover rule

The one genuine relief is the limited failover allowance. Under strict conditions, one node in a properly configured cluster may take over the workload of a failed node for up to a total of ten separate days in a calendar year without requiring its own licence. The conditions matter: the nodes must share storage, only one unlicensed node may act as the failover target, and the allowance is capped at ten days across the year, with any part of a day counting as a full day.

The failover allowance is narrow and easy to invalidate. Exceeding ten days, using more than one unlicensed failover node, or failing the shared storage condition removes the relief and makes the node fully licensable. It is a genuine but fragile saving, and it interacts with the clustered model in the RAC licensing article.

Cold backup and the unlicensed exception

The other relief is the cold backup. A server that holds only backup files, with no Oracle software installed and running, does not require a licence. This is the basis for keeping disaster recovery copies cheaply: store the backups, but do not install or run the database on the recovery hardware until it is actually needed.

The exception is lost the moment the software is installed and the database is mounted or opened, even to apply archive logs or to test that recovery works. This is the trap: routine recovery testing, which good practice encourages, converts a cold backup into a running deployment for the duration of the test, and Oracle's position is that the server is then licensable. The tension between sound operational practice and the licence rule is real and must be managed explicitly.

Data Guard and Active Data Guard

Data Guard is Oracle's standby technology, and its licensing splits in two. Basic Data Guard, which maintains a standby by shipping and applying redo, is included with Enterprise Edition at no extra option cost, though the standby server itself still needs its Enterprise Edition licence. Active Data Guard, which allows the standby to be opened read only for reporting or used for offloading work, is a separately licensed option.

The trap is that Active Data Guard features can be used without the option being licensed, producing an option finding in exactly the way described in the options audit article. Opening a standby read only for a report, or enabling an offload feature, activates the option. The discipline is to confirm whether the standby uses only basic Data Guard or genuinely requires Active Data Guard, and to license accordingly rather than discover the gap in an audit.

Modelling the disaster recovery bill

Modelling the disaster recovery bill starts from the principle that every installed and running server is licensed like production. The model then applies the two reliefs where they genuinely fit: cold backup for hardware that holds only backups, and the failover allowance for a single node within ten days. The realistic outcome for a warm standby estate is close to a doubling of the production licence cost, including options, plus support on the additional licences.

Reducing that bill means choosing the recovery architecture deliberately. A cold backup with a documented, tested recovery procedure that stays within the unlicensed boundary is far cheaper than a warm standby, at the cost of a longer recovery time. The right balance depends on the recovery time objective, and modelling it is part of the database licensing service, which sizes resilience against both the operational requirement and the licence cost.

The buyer side view

The buyer side view of disaster recovery is that the licence follows operation, so the architecture is the cost lever. Decide the recovery time objective first, then choose between a fully licensed warm standby and a cheaper cold backup that stays inside the unlicensed boundary, and use the failover allowance only where its strict conditions genuinely hold. An estate that designs resilience with the licence rule in view avoids paying twice for capacity it rarely uses. For the full modelling, see the Enterprise Edition article, the database licensing white paper, or request a consultation.

Disaster recovery audit traps

Disaster recovery audit findings arise from three patterns. The first is an unlicensed standby that is in fact installed and applying data, which Oracle counts as a running production equivalent. The second is recovery testing on a cold backup that installed and ran the software, converting it to a licensable deployment for the test period. The third is Active Data Guard features used on a standby licensed only for basic Data Guard.

Each is defended on the facts of installation and operation: whether the server was genuinely cold, whether the failover allowance conditions held, and whether the Active Data Guard features were truly used. Reconstructing this evidence is part of the audit defence practice, and the defence is strongest when the recovery procedures were designed and documented with the licence boundary in mind from the start.

Common disaster recovery mistakes

The first mistake is treating a passive standby as unlicensed because no one connects to it, when applying data is itself licensable operation. The second is testing recovery on a cold backup by installing and running the database, which forfeits the unlicensed exception for the test. The third is opening a standby read only for reporting and inadvertently activating Active Data Guard without the option.

The fourth is relying on the failover allowance without meeting its strict conditions on shared storage, single node, and the ten day cap. Avoiding these is a matter of designing the recovery architecture around the licence boundary, documenting which servers are genuinely cold, and confirming the standby uses only the included Data Guard features. The option dimension overlaps directly with the broader options and packs discipline.

Remote mirroring and storage replication

Storage level replication raises a subtle disaster recovery question. Where a disaster recovery copy is maintained by replicating the underlying storage rather than by an Oracle standby applying redo, the recovery server may hold a complete database image without Oracle software installed and running. In that state it can fall under the cold backup exception, because the database is not operational on the recovery hardware.

The exception is fragile in the same way as any cold backup. The moment the replicated copy is brought up, with Oracle installed and the database mounted or opened, even to verify the replica or to test recovery, the server becomes a running deployment and is licensable. Storage replication can therefore be a cost effective disaster recovery method provided the recovery server stays genuinely cold until a real failover, but the discipline around testing is exactly the same as for any cold backup, as set out earlier in this article.

Licensing recovery testing correctly

Recovery testing is the activity most likely to convert a cheap cold backup into a licensable deployment, and it is also indispensable: an untested recovery plan is not a plan. The tension is resolved not by avoiding testing but by licensing it deliberately. One option is to test on hardware that is itself licensed for the period, treating the test environment as a temporary licensed deployment. Another is to use the limited failover allowance where its conditions genuinely apply.

The mistake to avoid is testing on a cold backup and assuming the exception survives the test, because Oracle's position is that installing and running the software during a test makes the server licensable for that time. Building a recovery testing regime that is both rigorous and licence aware is part of designing the resilience architecture, and it should be planned alongside the standby and backup decisions rather than bolted on afterward. The option dimension of any Active Data Guard used in testing follows the options and packs rules.