Disaster recovery is one of the most overlooked sources of legitimate certification value, and one of the most misunderstood. Whether your DR counts, and how much, turns on configuration and contract. Both are worth getting right.
By Daniel Voss · Ex Oracle LMS · 4 June 2026
Disaster recovery often counts toward your Oracle ULA certification, but it depends on how the DR environment is configured and what your contract allows. A DR instance with Oracle installed and running during the term is generally a deployment you can count. Cold standby that meets particular conditions may be treated differently. Because the answer turns on configuration and contract wording, DR should be measured and reconciled deliberately, not assumed in or out, since it is frequently a meaningful and defensible addition to the certified number.
Disaster recovery sits at the edge of most people's mental model of their estate. It is the environment that exists to be unused, the insurance you hope never to claim. That mindset is exactly why DR is so often left out of a certification count. Teams measure production carefully, sometimes measure test, and quietly forget the standby site running the same Oracle software in another data centre. At certification, that omission is not neutral. Every DR instance with Oracle deployed is a potential perpetual licence, and leaving it out is leaving entitlement uncaptured for no reason but habit.
The irony is that Oracle's own licensing logic generally treats DR as licensable. In ordinary licensing terms, a standby or active DR environment with Oracle installed normally requires licences because the software is present and the processors can run it. Inside a ULA, that same logic works in your favour. If those instances would require licences outside the agreement, they are deployments you are entitled to count within it. The environment you think of as dormant is, for certification purposes, very much alive.
The honest answer is that it usually can, but the precise treatment depends on the DR pattern and your contract. Different DR architectures are treated differently, and the distinctions matter. The table below sketches the common patterns and their typical direction, with the firm caveat that your agreement and your configuration govern the real answer.
| DR pattern | Typical character | Usual direction at certification |
|---|---|---|
| Active or synchronised standby | Oracle installed and running | Generally counts |
| Warm standby | Installed, periodically active | Generally counts, evidence the activity |
| Cold standby | Installed but not running | Contract specific, assess carefully |
Indicative only. The treatment of any DR pattern depends on how it is configured and on the precise wording of your agreement. Cold standby in particular carries specific conditions worth professional assessment.
Treat disaster recovery as a deployment until your contract tells you otherwise, not the reverse. The default of forgetting DR costs entitlement. The discipline of measuring it, and evidencing how it runs, turns dormant infrastructure into permanent licences.
Because DR is unusual by design, counting it requires more than asserting it exists. The strength of a DR figure comes from the evidence that the instances were deployed and operating during the term. That means configuration data showing Oracle installed on the DR hosts, replication or standby logs showing the environment was live, and monitoring or backup records confirming it ran. With that evidence, the DR count is defensible at certification and resilient in a later audit. Without it, even a legitimate DR deployment is a weak claim that may not survive scrutiny.
Consider an anonymized financial services firm running a synchronised standby of its core database estate in a second site. The standby carried the same processor footprint as production. Measured and evidenced properly, it roughly doubled the certified count for that estate, all of it defensible because the replication logs and configuration data proved the environment had been live throughout the term. Had the firm followed the common habit of certifying only production, half of that legitimate, no extra support cost entitlement would simply have vanished at exit.
Disaster recovery is a clear example of why counting and evidence go together, and why nothing should be excluded from the certified number by assumption. See how to test the whole count before Oracle does in verifying the count before Oracle does, learn to align your records in reconciling entitlement to deployment, and ground the full picture in our Oracle ULA certification guide.
Book a ULA assessment and we will measure your disaster recovery estate, test it against your contract, and evidence what counts so none of it is left behind at exit.