Oracle GoldenGate Licensing

Oracle GoldenGate is one of the more expensive line items a database estate can acquire without fully understanding the bill, because it is licensed per Processor on every database it touches and a replication design naturally touches at least two. This article explains what GoldenGate is, why it is a standalone product rather than a database extra, exactly how the Processor metric applies across a replication topology, and how a buyer side estate keeps the cost contained. It sits beneath the database licensing pillar and pairs with the options and packs overview.

What is Oracle GoldenGate?

Oracle GoldenGate is a real time data integration and replication product. It captures committed transactions from a source database, ships them as trail files, and applies them to one or more target databases, keeping the two in near synchronisation with very low latency. It is used for high availability, zero downtime migration, active active configurations, and feeding data warehouses and reporting systems without loading the production source.

Because it operates on the redo stream rather than on the application, it is largely transparent to the database it replicates. That transparency is exactly what makes it a licensing trap: GoldenGate can be installed, configured, and run by a database or integration team solving an availability problem, with no procurement event marking the moment a six figure entitlement obligation was created.

Why GoldenGate is a product, not a database option

It is essential to understand that GoldenGate is not a database option in the sense that Partitioning or Advanced Compression are. Those options are features of the database kernel, switched on inside the engine and recorded in the feature usage views. GoldenGate is a separately installed product with its own binaries, its own price list entry, and its own licence metric. It does not appear in DBA_FEATURE_USAGE_STATISTICS the way a kernel option does.

This distinction matters for two reasons. First, it means the detection mechanism is different: Oracle finds GoldenGate by inspecting installed software and running processes, not by reading a database view. Second, it means the licence does not ride on the database licence; GoldenGate must be licensed in its own right, in addition to whatever the database and its other options and packs already cost. Teams that assume a replication tool is bundled with Enterprise Edition are mistaken.

How is Oracle GoldenGate licensed?

GoldenGate is licensed on the Processor metric. The licensable processor count is the physical cores of the server multiplied by the core factor for that chip, exactly as it is for the database. Named User Plus is generally not the practical metric for GoldenGate because the processes are not tied to a countable human user population; replication is a machine to machine activity.

The licence attaches to the database server where the GoldenGate Extract or Replicat processes execute. If the capture process runs on the source server and the apply process runs on the target server, both servers require GoldenGate Processor licences for their respective core counts. There is no concept of a single GoldenGate licence that covers an entire flow regardless of where it runs.

Licensing source and target databases

The single most expensive misunderstanding about GoldenGate is the assumption that you license it once. In a normal one way replication from a production source to a reporting target, the Extract runs on the source and the Replicat runs on the target, so both servers need GoldenGate. In an active active configuration, where both sides capture and apply, both sides plainly need it. The footprint is therefore at least the sum of the two databases, and frequently more once a hub server is added.

This doubling is why GoldenGate exposure scales so quickly. A 16 processor production database replicated to a 16 processor standby that also runs GoldenGate is a 32 processor GoldenGate obligation, layered on top of the database and option licences already in place. The asymmetry between the modest operational task of replication and the full Processor cost on every server is the same trap that makes the database options audit so punishing.

GoldenGate editions and bundles

GoldenGate is sold in several forms, and the entitlement you hold determines what you may legally run. There is the base GoldenGate product, editions tuned for specific platforms and for big data and streaming targets, and bundles that combine GoldenGate with other data integration tooling. Each has its own price and its own scope, and an entitlement for one does not authorise another.

A frequent finding is that an estate holds GoldenGate for one platform or use case but has deployed it more broadly, for example extending replication to a database or an operating system that the held entitlement does not cover. Treating the specific edition and its restrictions as part of the entitlement baseline, alongside the Enterprise Edition position, is the only way to know whether deployment matches the contract.

What triggers a GoldenGate audit?

Because GoldenGate is found through installed software inventory rather than a database view, the triggers are slightly different from a pure database option audit. The common ones include a deployment scan that finds GoldenGate binaries on servers with no corresponding entitlement, a migration project where GoldenGate was used as the zero downtime mechanism and never decommissioned, and an active active or multi target architecture where the second and third targets were never licensed.

• Undecommissioned migration use. GoldenGate is installed to move a database to new infrastructure, the migration succeeds, and the binaries are left running, creating a standing obligation for a task that has finished.
• Topology growth. A flow that started as one source to one target grows additional targets, each adding a Processor obligation that the original purchase never anticipated.
• Platform drift. Replication is extended to a database or platform outside the held edition's scope.

Each of these is visible in advance to an estate that inventories its own GoldenGate installations, and invisible to one that does not, until an audit defence engagement is already under way.

How to contain GoldenGate exposure

Containment begins with a complete inventory of where GoldenGate binaries are installed and where Extract and Replicat processes actually run, mapped against the held entitlement and its edition restrictions. Anywhere the software runs without a matching Processor licence is exposure that must be licensed, removed, or relocated to a licensed server.

The preventive control is to treat any new GoldenGate deployment, and any new target in an existing flow, as a procurement event requiring sign off, the same discipline applied to creating a partitioned object or enabling any other chargeable feature. Migration use deserves special attention: GoldenGate installed for a one off move should be decommissioned the moment the cutover is complete, with the removal documented and dated. Modelling the Processor cost of a replication topology before it is built, the way the database licensing service does, is far cheaper than discovering the doubled footprint in a settlement. For metric mechanics that feed the calculation, see Processor versus Named User Plus.

The buyer side view

The buyer side position on GoldenGate is that it is a Processor licensed product whose true cost is determined by the shape of the replication topology, not by the size of any single server. Inventory every installation, license every server where capture or apply runs, decommission migration use promptly, and never let a flow grow new targets without a deliberate licensing decision. Done as a standing control, this keeps a genuinely useful replication capability available where it is paid for and prevents the silent doubling that becomes an audit finding. To model your own replication exposure, start with the database pillar, review the database licensing white paper, or request a consultation.