Oracle's default stance: Any server where GoldenGate is installed or actively running must have a licence. The only exception — an unused cold backup rarely activated — is narrow and should be approached carefully with documentation if you rely on it. Plan to fully licence your HA and DR environments.
HA/DR Licensing Scenarios
In an active-active setup — two data centres or cloud regions where each has an active database and GoldenGate replicates changes both ways — both sites are production and actively using GoldenGate. All nodes must be fully licensed. It is effectively the same as licensing two separate GoldenGate deployments, one at each site. Each site's source and target roles are interchangeable, so there is no "free" side. This doubles the licensing requirements, but it is expected for active-active architectures.
A financial system runs in two data centres for HA, with GoldenGate keeping them in sync. If each data centre's DB server has 16 cores, you must license GoldenGate for 16 cores at DC1 and 16 cores at DC2 (with the appropriate GoldenGate edition for Oracle/Non-Oracle as applicable).
In this scenario, a primary database continuously replicates to a secondary database (which may be used for read-only reporting or purely for failover readiness). Even though the secondary might not accept user changes, GoldenGate is actively applying transactions to it — running apply (Replicat) processes continuously. From a licensing perspective, that secondary environment is actively running GoldenGate.
The general rule: if GoldenGate is installed and/or running on a server, that server needs to be licensed. The standby database server will continuously run the apply processes, which is definitively "running" GoldenGate.
Oracle has a concept of a failover exception (the "10-day rule") for certain products in clustered environments. This rule allows a passive node in a cluster to run the software for up to 10 separate days per year without a licence, only if the primary node fails.
However, this is tricky to apply to GoldenGate because GoldenGate doesn't usually sit idle until failover — it would either be running (for replication) or not running at all. If you had a setup where GoldenGate is installed on a secondary server but not actively replicating (essentially a cold standby for GoldenGate itself), you might argue the 10-day rule if you only launch GoldenGate on that server during a failover event.
But in practical GoldenGate DR designs, you cannot keep data in sync if GoldenGate isn't running until failover. Most GoldenGate DR setups don't qualify as "idle standby" — they are active replication. Therefore, the 10-day rule is usually not applicable, and you should licence the DR server.
Only consider the failover exception if you truly have GoldenGate completely inactive on a backup node that only kicks in if the primary GoldenGate server dies — and even then, track usage carefully. Oracle's official stance: standby and failover systems must be licensed the same as production unless they meet the narrow unlicensed failover criteria.
Be cautious if GoldenGate is installed in a cluster (e.g. Oracle RAC or a Linux cluster). Oracle's partitioning policies for databases apply similarly. If a GoldenGate installation can run on multiple nodes of a cluster, Oracle might insist all those nodes are licensed — even if at any one time it runs on only one node.
Common scenario: GoldenGate is installed on a multi-node application cluster for HA. Unless you've configured hard partitioning or processor affinity to restrict it, Oracle could view the entire cluster's CPU footprint as needing licensing (similar to the VMware scenario extended to physical clusters).
If you need GoldenGate high availability, consider using Oracle's native clustering (e.g. Oracle Clusterware) with static node assignment, or use container orchestration with node labels to ensure GoldenGate processes only run on licensed nodes. If using VMware for HA, see the virtualisation considerations in the GoldenGate Licensing Overview.
High availability testing often involves duplicating environments. Non-production environments also require licences if GoldenGate is installed. Oracle's licences do not automatically cover dev/test separate from production.
Unless you have a special deal, each dev/test GoldenGate deployment should either be licensed or you use the free licence (Oracle GoldenGate Free) under its limitations strictly for development use. GoldenGate Free edition is limited — Oracle-to-Oracle only, small data sizes — and cannot be used for production workloads.
If your HA/DR testing involves full-scale replicas, ensure those environments are accounted for in licensing — perhaps via a multi-use licence or as part of a ULA.
Many organisations use GoldenGate to maintain a live copy of an on-prem database in the cloud for DR. This is a great use case for GoldenGate, but it means you now have GoldenGate running in the cloud as well — which must be licensed (via BYOL).
You need enough licences for both environments: if your primary is on-prem (licensed via Processor metric) and your DR is on AWS (licensed via vCPUs with 2:1 ratio). Some may choose to deploy the DR GoldenGate in OCI using BYOL or even licence-included for ease — especially if it's only spun up during a disaster. But if it's continuously syncing, you're continuously using it, so the licence applies continuously.
Read Cloud-Based GoldenGate Licensing: OCI, AWS, and Azure for detailed cloud deployment guidance.
Need help assessing GoldenGate licensing across HA/DR environments?
Oracle Licence Management →HA/DR Licensing Summary
| Scenario | GoldenGate Running? | Licence Required? | Notes |
|---|---|---|---|
| Active-Active (Bi-Directional) | Yes — both sites | Yes — both sites | Double the licensing. Each site fully licensed. |
| Active-Passive (One-Way Standby) | Yes — Replicat on standby | Yes — both sites | Standby runs apply processes = active use. |
| 10-Day Failover (Cold Standby) | No — only on failover | Maybe — very narrow | Only if GoldenGate is truly idle. Track usage carefully. Rarely practical. |
| Clustered (RAC / Linux Cluster) | Can run on any node | Yes — all reachable nodes | Unless hard partitioning restricts to specific nodes. |
| Dev / Test / QA | Yes — if installed | Yes | No automatic dev/test coverage. Use GoldenGate Free for limited dev use. |
| DR to Cloud (OCI/AWS/Azure) | Yes — continuous sync | Yes — cloud too | BYOL to cloud, vCPU counting rules apply. |
Cost-Saving Architecture Strategies
📚 Related Reading
For example, an organisation might use GoldenGate for multi-master or heterogeneous replication (where it's truly needed), but use ADG for a single-instance Oracle standby because the GoldenGate licence they have for that server grants ADG rights. This can avoid needing GoldenGate in some cases for DR.
However, this only works Oracle-to-Oracle and requires the environment to tolerate physical standby (no divergence). It's a possible optimisation: if you have GoldenGate licensed on an Oracle DB, you already own ADG for that DB, so consider using ADG for one-directional DR and GoldenGate for other integration tasks — thereby not having to deploy GoldenGate in the DR site for that DB.
Architecture optimisation: Use GoldenGate where you need it (multi-master, heterogeneous, transformation) and leverage the included ADG rights for simpler Oracle-to-Oracle standby scenarios. This is nuanced but can deliver meaningful cost savings on the DR side.
Plan to fully licence your HA and DR environments. Oracle's default stance is that any server where GoldenGate is installed or actively running must have a licence. From a budgeting perspective, factor in the cost of those additional licences if you require redundancy.
📂 Oracle Licensing Case Studies
🔧 Oracle Advisory Services
📄 White Papers & Resources
Need Help With Oracle GoldenGate Licensing?
Whether you're planning a new HA/DR architecture, preparing for an Oracle audit, or looking to optimise existing GoldenGate deployments — our Oracle licensing specialists deliver clarity, compliance, and cost savings as a fully independent advisor.
💡 Download our Oracle licensing white papers for actionable strategies
View White Papers →