Disaster recovery and standby instances deployed inside the ULA term count toward your certification like any other deployment, yet they are among the most overlooked. Captured and evidenced properly, they add real perpetual licenses at no extra support cost. Missed, they are entitlement you lose for good.
Most organisations measure their production estate carefully and then stop. Disaster recovery sites, standby databases, and warm replicas sit slightly out of view, owned by infrastructure rather than the application teams who track licensing, and they quietly drop out of the count. Inside a ULA that omission is expensive. While the term runs, your right to deploy is unlimited, so every standby you have installed is fully licensed. At certification, each one you can evidence converts into a perpetual license. Counting them is not aggressive. It is simply counting what you actually built.
Yes. A disaster recovery or standby instance that is genuinely deployed and installed within the term counts toward the certification like any other deployment. The unlimited right covers it while the ULA runs, and at exit it becomes part of the deployed quantity you declare, provided you can prove it was live before the cutoff and falls inside scope. This is one of the most reliable sources of legitimate maximization, because nearly every serious Oracle estate has standby capacity, and that capacity is frequently left out of the first measurement. The licenses were always yours to certify. The work is to find them and document them.
Your standby estate is licensed entitlement you already built. Certification is the moment to convert it to permanent ownership. Count it, evidence it, keep it.
Outside a ULA, Oracle offers a limited failover allowance that lets a passive node take over for a short period during an actual failure without a separate license, under defined conditions in the ordinary licensing rules. Many teams carry that mental model into the certification and assume their standby is therefore not a licensed deployment. Inside a ULA the logic is different. You do not rely on the failover allowance during the term, because deployment is unlimited and the standby is fully covered while installed. At certification, the question is not whether the node was actively serving traffic, but whether the Oracle software was installed and deployed within the term. A standby you stood up and can evidence is a deployed instance, and it counts. The same is true for active data guard configurations, where the standby is open and doing real work.
The detail depends on your architecture and, as always in ULA work, on your specific contract language, but the common patterns are clear. A physical standby maintained through replication and installed within the term is a deployment. A warm standby that is built and ready, even if rarely activated, is a deployment if the software is installed. A second site running its own installed Oracle estate for resilience is a deployment. Backup targets that hold only data files with no installed Oracle software are not deployments and should not be claimed, because they are not running the product. The line is installation and deployment of the software within the term, not how often the environment is exercised. Hold that line and your DR contribution is both substantial and defensible.
Consider an anonymized organisation certifying a database ULA with a primary data centre and a disaster recovery site. The first measurement captured only production. A full review added the standby estate that had been built during the term and was fully installed. The figures below are indicative and the real result turned on the contract and the evidence, but the shape is typical: the DR site materially raised the defensible count, and because support is flat at the ULA level, every added license was free permanent value.
| Environment | Installed in term | Counts at certification |
|---|---|---|
| Primary production | Yes | Yes, captured first |
| Physical standby at DR site | Yes | Yes, often missed |
| Warm standby, rarely activated | Yes | Yes, if software installed |
| Backup storage, no Oracle installed | No software | No, not a deployment |
Evidence is what turns a real standby into a defensible certified license rather than an audit question two years later. For each standby, document the host and its processor configuration and core factor, the installation date showing it was live within the term, and the role it plays. Configuration records, Data Guard or replication setup, server inventories, monitoring history, and tooling output all contribute. The aim is a file that lets you answer, quickly and from records, how each counted instance qualified. Standby environments deserve the same evidentiary discipline as production, because they will draw scrutiny precisely because they are sometimes claimed loosely. Done properly, they are among the strongest additions to a count.
Capturing DR is part of counting the whole estate and timing deployment well. Read counting production, test, and DR instances for the complete measurement discipline, and coordinating engineering for the final push for standing environments up before the cutoff. Remember too that support fees do not rise with the count, so every defensible standby is free value. For the full method, see the ULA deployment maximization guide.
Yes, when they are genuinely deployed and installed within the term, disaster recovery and standby instances count toward the certification like any other deployment. The unlimited right covers them during the term, and at exit they convert into perpetual licenses if you can evidence them, which is why they are a routine source of maximization.
Oracle's limited failover allowance lets a passive node run for a short period during an actual failure without a separate license under ordinary contracts. Inside a ULA you do not need that allowance during the term, because deployment is unlimited, and at certification a standby you have installed and can evidence is counted as a deployed instance.
Document the host, processor configuration and core factor, the installation date inside the term, and its role through configuration records, Data Guard or replication setup, server inventories, and tooling output. The evidence file is what converts a real standby into a defensible certified license rather than an audit question later.
Book a confidential assessment and we will find every defensible DR and standby deployment, evidence each one, and convert it into permanent entitlement at certification.