GoldenGate Licensing for High Availability and Disaster Recovery
GoldenGate is often used to support high availability (HA) and disaster recovery (DR) architectures, such as bidirectional replication for active-active databases or one-way replication to a standby database or remote DR site.
Understanding that Oracle’s licensing requirements also extend to HA/DR environments is critical.
There is a common misconception that standby or passive systems don’t need licensing; in Oracle’s licensing world, if the software is installed or running, it typically must be licensed, with limited exceptions.
Let’s break down scenarios:
- Active-Active (Bi-Directional) Replication: In an active-active setup (say two data centers or two 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 – effectively, it’s the same as licensing two separate GoldenGate deployments, one at each site. Each site’s source and target roles are interchangeable, so there’s no “free” side. This doubles the licensing requirements, but it’s expected for active-active. Real-world example: A financial system runs in two data centers for HA, with GoldenGate keeping them in sync. If each data center’s DB server has 16 cores, you must license GoldenGate for 16 cores at DC1 and 16 at DC2 (with the appropriate GoldenGate edition for Oracle/Non-Oracle as applicable).
- Active-Passive (One-Way) Replication to Standby: In this case, a primary database is continuously replicating to a secondary database (which might 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, so from a licensing perspective, that secondary environment is actively running GoldenGate apply processes. Oracle requires licensing the GoldenGate software on the standby environment, like the primary. 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 (Replicat) processes, which is definitely “running” GoldenGate.
- Failover Nodes and the 10-Day Rule: Oracle does have 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 license, only if the primary node fails. However, this scenario typically applies to unplanned failovers of identical workloads (like an Oracle DB instance failing over to a standby node). It’s 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), 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 wouldn’t be able to keep data in sync if GoldenGate isn’t running until failover. So, 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 license 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.
- Clustered Environments: 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). A 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). Best practice: 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 virtualization notes below.
- Development, Test, QA Environments: High availability testing often involves duplicating environments. Remember that non-production environments also require licenses if GoldenGate is installed. Oracle’s licenses 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 license (Oracle GoldenGate Free) under its limitations strictly for development use. GoldenGate Free edition is limited (Oracle-to-Oracle only, small data sizes, etc.) 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 license or as part of a ULA).
- Disaster Recovery to Cloud: Many organizations 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 from licensing perspective, it means you now have GoldenGate running in the cloud as well – which must be licensed (via BYOL, as discussed). You need enough licenses for both if your primary is on-prem (licensed via processors). DR is on AWS (licensed via vCPUs 2:1). Some may choose to deploy the DR GoldenGate in OCI using BYOL or even license-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 that license-included pricing would apply continuously too).
Read Cloud-Based GoldenGate Licensing: OCI, AWS, and Azure..
In summary, plan to fully license your HA and DR environments. Oracle’s default stance is that any server where GoldenGate is installed or actively running must have a license. The only exception – an unused cold backup rarely activated – is narrow and should be approached carefully with documentation if you rely on it. From a budgeting perspective, factor in the cost of those additional licenses if you require redundancy.
One strategy some organizations use to reduce DR costs with GoldenGate is to leverage Oracle’s Active Data Guard for pure Oracle-to-Oracle physical standby (if that meets the need), since ADG is included with the GoldenGate license.
For example, they might use GoldenGate for multi-master or heterogeneous replication, but use ADG for a single-instance Oracle standby because the GoldenGate license they have for that server grants ADG rights. This can avoid needing GoldenGate in some cases for DR. However, that only works Oracle-to-Oracle and requires the environment to tolerate physical standby (no divergence).
It’s a possible optimization: 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. This is a bit nuanced but worth mentioning as a cost-saving architecture choice.
Read GoldenGate Common Audit Risks and Non-Compliance Scenarios.
