The two questions DR raises under a ULA
Disaster recovery under a ULA is best understood as two separate questions that are routinely confused. The first is whether a DR environment is allowed during the term. The second is whether that environment counts toward the perpetual entitlement at certification. The answers are usually different, and conflating them is the most common reason organisations either over deploy unnecessarily or under count valuable standby capacity. The contract mechanics that frame both questions are set out in the Oracle ULA pillar guide.
During the term the unlimited right is broad, so deploying DR is rarely a compliance problem. At certification the picture narrows, because the count is governed by the specific scope language of the agreement and by Oracle standard licensing policy, which treats certain failover and backup configurations differently from primary production. A standby database that the organisation assumed was free entitlement may or may not be counted, and the difference can be material for processor heavy estates.
DR coverage during the term
While the ULA is live, in scope products deployed in disaster recovery roles enjoy the same unlimited right as production. An organisation can build standby databases, configure failover clusters, and stand up test DR environments using ULA products without paying incremental licence fees, provided the products are on the schedule and the hosts belong to licensed legal entities. This is one of the operational advantages of a ULA: resilience engineering during the term carries no licensing penalty, so teams can build the DR posture the business actually needs.
During the term, deploy the disaster recovery you need without counting pennies. At certification, count every standby instance you are entitled to, because each one that qualifies is permanent.
This freedom should be used deliberately. Because DR environments deployed and running before the certification cut off may convert to perpetual entitlement, the term is the right window to build out resilience that the organisation intends to keep. Treating DR as part of the broader deployment campaign described in the ULA certification guide ensures standby capacity is both built and counted rather than added later at full cost.
How does Oracle DR policy interact with the ULA?
Oracle maintains standard licensing positions for disaster recovery that exist independently of any ULA. The widely cited distinctions are between a cold failover environment that is normally idle and only activated for a limited number of days when production fails, a warm or hot standby that runs continuously such as a Data Guard physical standby, and backup or archive copies. Oracle policy generally requires full licensing for any environment where the software is installed and running, including continuously synchronised standby, while offering narrow allowances for genuinely idle failover nodes in a clustered configuration.
Under a ULA these policy distinctions do not change what you may deploy during the term, but they shape what counts at the end and what your compliance position looks like afterward. A continuously running standby that mirrors production is installed and running software, so it generally counts. An idle cold failover node may be treated differently. Because virtualization changes how these boundaries are drawn on shared infrastructure, the interaction with partitioning is covered in the ULA virtualization guide, and the underlying database rules are detailed in the Oracle database disaster recovery licensing guide.
Whether DR environments count at certification
The value question is counting. At certification the customer declares the quantity of each in scope product deployed, and that quantity becomes the perpetual entitlement. Whether a given DR environment adds to that figure depends on the scope and certification language of the specific agreement and on how the environment is configured at the cut off date.
| DR configuration | Installed and running? | Typical count treatment |
|---|---|---|
| Continuous physical standby | Yes | Generally counts as deployed |
| Active standby for read or reporting | Yes | Counts, options may also apply |
| Warm standby kept synchronised | Yes | Generally counts |
| Idle cold failover node | No, until activated | May not count, check contract |
| Offline backup or archive copy | No | Does not count |
The practical lesson is that continuously running standby capacity is usually countable and therefore valuable to declare, while idle failover nodes and offline backups are not deployed software and add nothing. Organisations seeking to maximise the certified count should ensure that the standby capacity they intend to keep is running and evidenced at the cut off date, applying the correct core factor to each host as they would for production.
Standby, failover, and backup compared
The three DR patterns differ in both risk posture and licensing treatment. A continuously synchronised standby provides the fastest recovery and is unambiguously installed and running, so it both consumes a compliance position and counts at certification. A clustered cold failover relies on a node that stays idle until a primary failure, and Oracle policy has historically allowed limited idle days before licensing is required, though the detail is specific and worth confirming against current policy rather than assumption.
Backup environments, where software is not installed and running but data is held for restore, do not count and do not consume a licence while dormant, but the moment a restore brings an instance online the normal rules apply. The interaction of these patterns with audit risk is significant, because auditors examine DR estates closely for environments that are running but were assumed to be free, a pattern explored in Oracle audit defence engagements.
Managing DR to protect the count
Managing DR under a ULA means deciding, well before certification, which standby capacity the organisation intends to keep permanently and ensuring it is running and documented at the cut off. The inventory should record each DR instance, its role, its host processor configuration, and whether it is continuously running or idle, so the certification declaration can defend every counted environment. Standby that the business will retain should be live and counted; speculative DR built only to inflate a count invites challenge and should be avoided.
After certification the compliance position inverts. The perpetual entitlement is now a fixed quantity, and any DR environment that grows beyond it, or any failover node that is activated and left running, can create a new licensing requirement. Building the post ULA DR posture deliberately, with the certified quantities as the ceiling, is part of the wider commercial planning handled in the ULA negotiation service.
The buyer side view
The buyer side view separates the two questions cleanly. During the term, build the disaster recovery the business genuinely needs, because the unlimited right makes it free. At certification, count every standby environment that is installed and running and that you intend to keep, because each one converts to permanent entitlement, while recognising that idle failover nodes and offline backups add nothing to the figure. The value lies in continuously running standby capacity that is live and evidenced at the cut off date.
Map your entire DR estate against Oracle standard policy and your specific certification language before the term ends, read the database disaster recovery licensing guide for the underlying rules, and treat resilience as part of the deployment you certify rather than an afterthought you license later.
Oracle ULA disaster recovery: frequently asked questions
Are disaster recovery environments covered by an Oracle ULA?
During the term, in scope products in DR roles are covered by the unlimited right, so standby and failover environments can be deployed without incremental fees. The decisive question is whether they count at certification. See the ULA pillar guide.
Does a standby database count toward the ULA certification?
A continuously running standby, such as a synchronised physical standby, is installed and running software and generally counts toward the certified perpetual entitlement. An idle cold failover node and offline backups typically do not.
How does Oracle DR policy affect a ULA?
Oracle standard policy distinguishes continuously running standby, idle cold failover, and backup copies. It does not limit what you deploy during the term, but it shapes what counts at certification and your compliance position afterward. See the ULA virtualization guide.
Should we build DR during the ULA term?
Yes, if the business needs it. Resilience built during the term is free under the unlimited right, and continuously running standby that is live at the cut off date can convert to permanent entitlement, so deliberate DR build out is rational.