Oracle ULA contracts routinely omit any explicit definition of disaster recovery environments — and that silence is not neutral. Oracle's LMS team interprets ambiguous DR language in the way that maximises your certification count and, ultimately, Oracle's revenue at renewal. Understanding exactly how hot standby, cold standby, Active Data Guard, and failover environments count under your ULA is the difference between an accurate certification and a back-license exposure running into eight figures.
A ULA gives you unlimited deployment rights for contracted Oracle products during the ULA term. At the end of the term, you certify the number of processor licenses deployed — and those certified numbers become your perpetual license entitlement. The higher your certified processor count, the greater your perpetual entitlement. That is the fundamental structure Oracle designed.
What Oracle did not design is a clear, universally applicable rule for how DR environments count toward that certified total. Most ULA contracts define "deployment" in terms of production use. They say nothing about databases running in a disaster recovery site in a standby configuration, waiting for a production system to fail. Oracle's LMS team fills that silence by applying Oracle's standard licensing policies — which treat any running instance of Oracle Database software as a licensed deployment requiring counted processor licenses, unless a specific exemption applies.
For enterprises running enterprise-class business continuity programs, this has significant implications. A typical large-enterprise Oracle Database deployment might have a primary production site running 64 processor licenses and a fully mirrored DR site running another 64 processors. Without understanding the ULA DR rules precisely, that enterprise may certify 64 processors when Oracle's interpretation would count 128 — triggering a back-license claim at renewal that the enterprise was never prepared for.
The variables that determine your DR environment's licensing treatment under a ULA are: the type of standby (hot vs cold), whether Active Data Guard is in use, the specific contract language in your ULA, and whether Oracle's published DR policy applies or whether your ULA modifies it. All four variables require forensic review of your specific agreement before you certify.
Our ULA Advisory service forensically reviews your contract language and DR architecture before you certify — preventing seven-figure back-license claims at renewal.
A hot standby environment is one where Oracle Database software is running, the database is mounted and open (or in standby open mode), and the system can serve as a production failover target with minimal or zero switchover time. Hot standby systems include Active Data Guard standby databases, Oracle RAC clusters with synchronous replication, and any secondary database system that is online, active, and processing redo log data in real time.
Oracle's licensing policy is unambiguous on hot standby environments: they require full licensing. Every processor on which Oracle software is running and active — regardless of whether that processor is serving end users — is a licensed processor. There is no DR exemption for hot standby in Oracle's standard licensing policy, and ULA contracts do not modify this position unless you have specifically negotiated a DR clause.
Under your ULA, a hot standby system must be counted in your certification. If you have a 32-processor primary production database cluster with a fully synchronous hot standby running another 32 processors, your ULA certification count for that system is 64 processors (subject to Core Factor calculations), not 32. The standby processors run Oracle software; they are licensed; they count.
The practical consequence for ULA holders who have not planned for this: if you have been deploying hot standby DR throughout your ULA term without counting those processors, your certification will understate your actual deployment. Oracle's LMS team, if they review your certification, will identify the gap using infrastructure discovery tools and issue a back-license claim for the uncounted hot standby processors at full list price — plus 22% annual support retroactively to the date of first deployment.
Do not certify without counting hot standby: Oracle LMS auditors specifically look for DR environments that have been excluded from certification counts. Infrastructure discovery scripts capture all running Oracle instances across your network — including DR sites. Certifying without including hot standby, and then being audited, results in the worst possible outcome: a compliance gap identified post-certification that Oracle can pursue as a separate back-license claim outside your ULA protection.
A cold standby environment is one where Oracle software is installed on the hardware but the database is not running. The system is powered off, or powered on but with Oracle software stopped, ready to be brought online only in the event of a production disaster. In a true cold standby configuration, no Oracle processes are active between disaster recovery tests and actual failover events.
Oracle's published licensing policy provides an exemption for cold standby environments under specific conditions, set out in Oracle's "Technical Support Policies" document. The policy states that a single cold failover server may be used for disaster recovery purposes without requiring additional Oracle Database licenses, provided the standby system is used solely for DR purposes and is not used for testing, development, reporting, or any purpose other than DR failover.
For ULA holders, this cold standby exemption means that a genuine cold standby system — with Oracle software installed but not running — may be excluded from your ULA certification count. However, several important conditions must be met precisely:
The cold standby exemption is frequently misapplied. Enterprises assume that because a system is labelled "DR" in their CMDB it qualifies as cold standby. But if Oracle software is running on that server — even as a passive mount for monitoring — Oracle's LMS team will classify it as a hot standby and require full licensing. The label on your documentation does not determine the licensing classification. The state of the Oracle software on the hardware determines it.
Oracle Data Guard is included with Oracle Database Enterprise Edition at no additional cost. It provides standby database functionality — shipping redo log data from a primary database to one or more standby databases and applying that data to maintain synchronized copies. The standard Data Guard standby database is in a "mounted" state: it receives and applies redo data, but it cannot serve queries or application connections. From a licensing perspective, a standard Data Guard standby is a hot standby that requires full licensing at the standby site.
Active Data Guard (ADG) is a separately licensed Oracle Database option. ADG allows a standby database to be open in read-only mode while simultaneously receiving and applying redo data from the primary. This means the standby can serve read-only queries, offload reporting workloads, and provide real-time data access — while still maintaining DR readiness. ADG requires licensing the Active Data Guard option on every processor at the standby site.
For ULA holders, the Data Guard vs Active Data Guard distinction matters in two ways. First, if your ULA does not include the Active Data Guard option, deploying ADG at your DR site creates a compliance gap for the option license, even though your ULA covers the base Oracle Database EE. Second, if your ULA does include ADG, your certification count must include the ADG processors at your DR site — they are running a licensed Oracle option and must be counted.
A common trap: enterprises deploy Active Data Guard during the ULA term to enable read-only DR reporting without purchasing the option separately (reasoning that the ULA covers everything). If ADG was explicitly listed in the ULA's covered products, this is legitimate. If ADG was not listed, the enterprise has been running an unlicensed option throughout the ULA term — and certification will not cure that gap; it will expose it.
Included with Oracle Database EE. No separate option license required. DR site processors still count toward ULA certification as hot standby.
Separate licensed option. Must be explicitly covered in your ULA product list. DR processors count toward certification for both EE and ADG option.
May qualify for cold standby exemption if no Oracle processes are running and the system is used exclusively for failover. Review your specific ULA language.
RAC clusters at DR sites require full node licensing if they are running. Oracle RAC license applies to every active node — including standby cluster nodes.
Oracle Real Application Clusters (RAC) introduces additional complexity for ULA holders with DR environments. RAC is licensed per processor across all active nodes in the cluster. If you run a 4-node RAC cluster at your primary site and a 4-node RAC standby cluster at your DR site using Oracle Data Guard with RAC, the licensing question is: how many RAC processors must be certified?
Oracle's position: all running RAC processors require licensing. A hot standby RAC cluster — where Oracle software and clusterware are running, even if the database is in mounted standby mode — is a deployed RAC environment and must be counted. A 4-node standby RAC cluster running Data Guard means 4 additional processor licenses for Oracle Database EE plus 4 additional processor licenses for the RAC option — assuming Core Factor calculations apply to your hardware.
The cold standby exemption for RAC is even more restrictive. The single-server cold standby exemption in Oracle's policy was written for single-instance databases, not RAC. Oracle's interpretation for RAC cold standby is that the entire DR RAC cluster must be powered down (or Oracle software stopped across all nodes) to qualify for any DR exemption. A partially active RAC standby cluster does not qualify.
For ULA holders planning certification, it is essential to document the state of every RAC node at every DR site — active, standby, or cold — at the time of certification. Oracle LMS auditors will use network discovery tools and Oracle's own USMM (Usage Monitoring and Management) data to verify the state of RAC environments at DR sites independently of your self-reported certification.
Our Compliance Review service establishes your true processor count across production and DR — before Oracle does. See the Manufacturer ULA Certification case study for a $4.2M savings example.
Even if your DR environment qualifies as cold standby during normal operations, the licensing picture changes during DR tests and actual failover events. When you bring a cold standby online for a DR test — starting Oracle software, opening the database, and running production workloads on the standby — you are deploying Oracle software on those processors. For the duration of that test, the standby servers are running Oracle and require licensing.
Under Oracle's cold standby exemption, testing the DR environment is permitted — but Oracle's policy specifies that the exemption covers failover testing and actual disaster recovery, not extended parallel production running. If your "DR test" involves running the standby as a production system for weeks while the primary undergoes major maintenance, Oracle's LMS team may argue that the standby was being used as a production system, not a DR system — and charge accordingly.
For ULA certification purposes, if a DR test occurs during the ULA term, you must decide whether to count the DR processors in your certification. If the DR test ran for a meaningful period and you have documentation that Oracle software was fully active during that period, including those processors in your certification is prudent. Attempting to certify without them and subsequently being audited creates a compliance exposure that the ULA's unlimited deployment protection would no longer cover — because the ULA will have been certified and exited.
Best practice for ULA holders approaching certification: conduct a final DR inventory two to three months before certification. Document the state of every DR environment — which systems are hot, which are cold, which are currently being tested. Make a deliberate decision about whether each DR environment is included in your certification count. Then defend that position with contemporaneous documentation if Oracle ever challenges it.
The most effective approach to Oracle ULA DR licensing is to negotiate explicit DR protections into the ULA contract before it is signed. If your ULA does not address DR environments, you are subject to Oracle's standard licensing policy interpretations — which are almost always less favorable to the customer than a negotiated clause would be.
Specific terms to pursue during ULA negotiation include a defined DR processor cap — a contractual limit on the number of DR processors Oracle can count toward your certification, regardless of the DR environment's state. A common structure is to negotiate that DR processors count at 50% of production processor count, or that a single DR site is exempt from certification entirely provided it mirrors production exactly and is not used for active workloads.
A second option is a DR testing safe harbour. This clause would specify that DR tests of up to a defined duration (for example, 72 hours per quarter) do not trigger licensing obligations or increase the certification count — provided the tests are documented and the primary system remains the primary. This protects you against Oracle's LMS team characterising a DR test as parallel production running.
A third, increasingly common negotiated position is a "dark site" clause — a contractual acknowledgement that a specific named DR site, fully documented in the ULA, is excluded from processor counting for certification purposes, provided the site is used exclusively for disaster recovery and the software remains dormant except during declared DR events and scheduled tests.
Oracle's standard ULA template includes none of these protections. They must be actively negotiated. Oracle's deal team will resist, citing policy compliance obligations. An experienced independent Oracle contract negotiation advisor who has seen Oracle's internal position on DR clauses — and knows which terms Oracle will accept under the right commercial conditions — is essential for getting these protections into a signed agreement.
DR rules, certification traps, negotiation benchmarks and ULA case studies — delivered to enterprise stakeholders who are managing Oracle ULA positions.
Read by 2,000+ Oracle stakeholders at Fortune 500 enterprises. Unsubscribe at any time.
The complete guide to ULA certification — covering DR environments, deployment counting methodology, hot/cold standby rules, and how to prepare a defensible certification package. Used by ITAM teams at global enterprises preparing for ULA exit.
Download the ULA Certification Handbook →Before you certify, know exactly what Oracle can count — including your DR environments. Our former Oracle insiders protect your certification position.
Not affiliated with Oracle Corporation. Independent advisory for enterprise buyers only.