GoldenGate Common Audit Risks and Non-Compliance Scenarios
Oracle’s license audits can be rigorous, and GoldenGate deployments are increasingly scrutinized as more organizations adopt this technology.
Several common pitfalls can lead to compliance issues (and potentially hefty back-license fees or penalties).
Read GoldenGate License Optimization Strategies.
Being aware of these risks can help you avoid them:
- Miscounting Processors and Cores: Perhaps the most frequent issue is an incorrect calculation of required licenses. This can happen by not using the core factor when you should (leading to over-counting or under-counting depending on the method), or by using it when you shouldn’t (like in cloud). For example, an organization might deploy GoldenGate on a server and forget to multiply cores by the core factor. If they assumed one core = 1 license on an Intel system, they might over-license (buying double the needed licenses). Conversely, some might misunderstand rounding rules and under-license (e.g., six cores ×0.5 = 3 licenses, but if someone mistakenly thought 2.5 and rounded down). It’s important to apply Oracle’s formula exactly and always round up. Document your calculations for each server.
- Ignoring Minimums or NUP Requirements: In the rare cases where Named User Plus is used, organizations might not realize that Oracle requires a minimum of 25 Named Users per processor (in general). If GoldenGate NUP were in play and you had, say, 30 users on a 4-core server, the minimum would be 25×(cores×factor). Not meeting those minimums is non-compliant, even if the actual users are fewer. Again, since NUP for GoldenGate is unusual, this is not often seen, but it is worth noting.
- Unlicensed Targets/Sources: Another common scenario is when GoldenGate is set up to capture from or deliver to a database that the team didn’t realize needed its license. For instance, you might license the primary database’s GoldenGate but forget to license the secondary database’s server. In an audit, Oracle will typically ask for installation details of GoldenGate – if it’s installed on that target server and you have no license, that’s a compliance gap. Any environment where GoldenGate binaries are installed and used should correspond to a license entitlement.
- Virtualization Mistakes (VMware and Others): Virtualization can be a compliance trap with Oracle software. Many organizations run GoldenGate in virtual environments (e.g., VMware vSphere). Oracle’s policy with VMware (which it treats as soft partitioning) is to require licensing of all physical cores in any cluster where Oracle software is running, not just the portion the VM uses. A classic audit finding: GoldenGate was installed on a small VM with four vCPUs, but that VM is part of a large VMware cluster of 10 hosts. Oracle will assert that you needed to license the entire cluster for GoldenGate – potentially dozens of processors – even if GoldenGate wasn’t actively running on those other hosts. This can be a devastating compliance exposure if not anticipated. To avoid it, some strategies are:
- Physically segment Oracle workloads to dedicated clusters (e.g., have a separate VMware cluster for Oracle DB/GoldenGate with limited hosts, separate from your general virtualization farm).
- If possible, use Oracle-approved hard partitioning technologies (Oracle VM Server, Oracle Linux KVM with hard partitioning, or VMware ESXi with each host in its own sub-cluster and bound licensing—but Oracle does not officially recognize VMware as hard partitioning, so it’s the first option).
- Document that GoldenGate is pinned to certain hosts (Affinity rules) – while Oracle may not formally accept that in policy, it can be a negotiation point.
- Example Pitfall: Company A ran a GoldenGate instance on a VMware VM in a cluster of 20 ESXi hosts. They only licensed the four vCPUs assigned (2 licenses by cloud rule or four by mistake using the core factor). In an audit, Oracle discovered vMotion was enabled. Thus,, any cluster host could run the VM, so Oracle demanded licenses for all 20 hosts (say 20 hosts × 16 cores each ×0.5 factor = 160 licenses!). This example is taken to extremes but illustrates why virtualization must be managed carefully for Oracle products.
- Cloud Calculation Errors: A common mistake is applying on-prem rules to cloud or vice versa. One compliance risk is under-licensing in the cloud by using the core factor. E.g., an engineer might think an eight vCPU Azure VM is 8×0.5 = four licenses, whereas Oracle expects eight vCPUs ÷ 2 = 4 licenses – the same result in that case, but if they mistakenly did 8×0.5 and then ÷2, they’d get 2, which is wrong. Or if they didn’t know about the 2:1 rule and assumed eight vCPUs = 8 licenses, they’d be over-paying. Both misinterpretations happen. Oracle auditors will use the official policy (2 vCPU = 1) and could flag any deviation. Ensure your team is aware of the difference so that you neither under-license (compliance risk) nor over-license (unnecessary spend).
- Using the Wrong Edition License: Oracle expects you to have the correct GoldenGate licenses for the use case. If an audit finds you’re using GoldenGate for a non-Oracle database but only owning “GoldenGate for Oracle” licenses, that’s technically non-compliant. For example, you bought four processors of GoldenGate (assuming Oracle DB usage), but used them to replicate from an Oracle DB into Kafka. Oracle could argue you needed GoldenGate for Big Data licenses for that scenario. In practice, Oracle might require you to purchase the Big Data edition licenses for those processors if this happens. Similarly, if you use GoldenGate for Mainframe but only have licenses for GoldenGate for Non-Oracle, you’d likely be out of compliance. Always match your license type to your usage. This can be confusing if your GoldenGate configuration evolves (say you originally only did Oracle-to-Oracle, then later added a SQL Server target – you’d need to add the non-Oracle license at that point).
- Non-Production Environments Unlicensed: Sometimes teams spin up GoldenGate in a dev or test environment without including it in licensing counts (under the false assumption that only production needs licensing). Oracle licenses don’t differentiate environment; a deployment is a deployment. An audit will typically request details of all environments. Many firms have been caught off guard when Oracle asks, “List all servers (including dev/test) where Oracle GoldenGate is installed or used.” If you haven’t licensed dev/test, Oracle may require you to license or shut them down. To avoid this, you can:
- Use Oracle GoldenGate Free in dev/test if your use case fits its limitations (it’s free but has limits like 20GB of data, Oracle-to-Oracle only, etc.).
- Or include at least some licensing for non-prod in your budget (perhaps NUP licenses, if allowed, could be used for test environments with limited users, but again, GoldenGate NUP is rare).
- Or if non-prod usage is intermittent, you might shuffle a set of licenses between prod and test as needed (not officially straightforward, but as long as you’re not running beyond your total license count concurrently, you are technically okay).
- GoldenGate Version and Features Misuse: Oracle sometimes differentiates features by licensing. The core GoldenGate replication doesn’t have edition options like Database (no Standard vs Enterprise for GoldenGate – it’s one edition per DB type). But watch out for:
- Management Pack for GoldenGate: Oracle has a management pack (for monitoring GoldenGate via Oracle Enterprise Manager). It’s a separate license if you use it. Many avoid it, but just to be aware, enabling it without a license is a violation.
- Monitoring tools or custom solutions that embed GoldenGate technology might also require licensing.
- Upgrades: If you upgrade GoldenGate to a newer major version, ensure your support is active; otherwise, a version released after your support lapse might be considered unlicensed (since your license gives you rights only up to the version available during the support period). Stay current with support or stay on versions you have the right to.
- Audit Data Gathering Mistakes: During an audit, Oracle will often provide scripts or requests for data (for databases, they do this; for GoldenGate, they might ask for inventory or logs). Mistakes in how this data is gathered or reported can inadvertently expose you to compliance issues. For example, if you provide Oracle with a list of server specs and one server’s core count is reported incorrectly high, Oracle might calculate a larger license requirement. Always double-check any audit response data for accuracy.
Read GoldenGate Licensing for High Availability and Disaster Recovery.
Preparation and compliance management are key. To mitigate these risks, adopt some best practices:
- Conduct internal license audits regularly. Check that every GoldenGate installation is accounted for in your license counts.
- Keep accurate documentation of where GoldenGate is installed, how many cores/vCPUs it uses, what type of license covers it, and how you calculated it. This documentation is invaluable in an audit defense.
- Understand Oracle’s policies (or have licensing experts on call) so that you can immediately assess the licensing impact if you plan any architectural change (like expanding a VMware cluster or adding a new replication target).
- Be conservative in assuming what is “free” – unless explicitly documented (like the 10-day failover rule, or GoldenGate Free usage in dev with its constraints), assume you need a license.
Remember that Oracle’s LMS (License Management Services) auditors are thorough, and GoldenGate licensing is less familiar to some IT teams than database licensing. So the element of surprise can be higher. By knowing the common pitfalls above, you can hopefully avoid the “gotchas” that others have learned the hard way.
