GoldenGate Licensing for High Availability and Disaster Recovery

The Core Principle: Installed and Running Means Licensed

Oracle's standard licensing terms state that software which is installed and available for use must be licensed, with very limited exceptions. For GoldenGate specifically, this means that every server — primary, secondary, standby, DR site, or cloud failover instance — where GoldenGate binaries are installed and where GoldenGate processes run requires a processor licence. Oracle does not provide a general-purpose passive standby exemption for GoldenGate.

This principle is frequently misunderstood in HA and DR architecture planning. Infrastructure architects and DBAs familiar with the 10-day failover rule for Oracle Database clustered deployments sometimes assume a similar concession applies to GoldenGate at DR sites. It does not, for reasons explained in the section below.

Active-Passive Replication: The Continuous Replicat Problem

In a standard active-passive GoldenGate deployment for disaster recovery, the primary database runs Extract processes to capture changes from the redo log. Those changes are transmitted to the DR site, where Replicat processes continuously apply the transactions to the standby database. This is the architecture that provides near-zero RPO (Recovery Point Objective) and rapid failover capability.

The licensing implication follows directly from the architecture: the DR site is not idle. It is actively running GoldenGate Replicat processes around the clock, applying every committed transaction from the primary. The standby database server therefore requires full GoldenGate processor licensing based on the processor count of that server, calculated using the same core factor table and methodology as the primary site.

Why the 10-Day Rule Does Not Apply

Oracle's 10-day failover rule — formally described in Oracle's partitioning policy document — permits a passive node in a hardware cluster to run Oracle software for up to ten separate days per year without a separate processor licence. The rule was designed for cold standby scenarios in Oracle Clusterware or hardware failover configurations, where the passive node sits entirely idle until a failover event occurs.

GoldenGate in an active-passive DR architecture does not meet this condition for two reasons. First, the Replicat processes at the DR site run continuously, not only during failover events. Second, the 10-day rule applies to nodes within a single cluster topology, not to geographically separated primary and DR environments. Oracle's LMS team consistently applies this interpretation during audits, and attempts to claim the 10-day exception for GoldenGate DR deployments almost universally fail.

Active-Active Bidirectional Replication

Bidirectional, active-active GoldenGate replication is deployed for geographic load distribution, global read/write access, and near-zero-downtime failover across sites. In this architecture, both sites simultaneously run Extract processes (as sources) and Replicat processes (as targets), with conflict detection and resolution logic managing concurrent writes.

The licensing obligation is the highest of all GoldenGate architectures: both sites must be fully licensed for the complete processor footprint. Since both sites operate as source and target simultaneously, the bilateral licensing requirement applies at full capacity at both locations. An organisation with a 20-processor primary site and a 20-processor secondary site in active-active configuration requires 40 GoldenGate processor licences. At list price of $17,500 per processor, that represents $700,000 in base licence cost before annual support.

Organisations that originally deployed GoldenGate in active-passive mode and later converted to active-active replication for improved availability frequently fail to revisit their licence entitlement. The conversion from passive to active architecture changes the secondary site from a receiving-only target to a full bilateral participant, potentially doubling the licence requirement at that site.

GoldenGate with Oracle RAC for High Availability

Oracle Real Application Clusters (RAC) is the preferred high availability mechanism for Oracle Database in many enterprises. When GoldenGate is deployed alongside RAC, the interaction between the two products creates specific licensing considerations that differ from single-instance deployments.

Extract Process Placement in RAC

In a RAC environment, GoldenGate's Extract process must connect to the Oracle redo log stream. For classic Extract, this typically means GoldenGate runs on one node of the RAC cluster and reads the redo log files. For Integrated Extract (which uses Oracle Logminer and the database connection API), GoldenGate can be associated with any node in the cluster. The licensing question centres on which processors Oracle will consider as "running" GoldenGate.

Oracle's standard position is that if GoldenGate can run on any node within a cluster — and GoldenGate with Integrated Extract can failover between nodes automatically — then all nodes in the cluster must be licensed. An organisation with a four-node RAC cluster where GoldenGate Integrated Extract runs on one node but can failover to any node must licence all four nodes' processors. This position mirrors Oracle's general approach to clustered environments and is consistent with how Oracle applies processor counting to other products in HA cluster topologies.

Practical Mitigation: Dedicated GoldenGate Nodes

Organisations seeking to limit the processor licensing exposure in RAC deployments can achieve this through careful cluster configuration. Designating specific RAC nodes for GoldenGate operations — through Oracle Clusterware resource policies, database service placement rules, or static service configurations — and ensuring that GoldenGate processes cannot migrate to non-designated nodes allows a more targeted licence count. The designated nodes' processors must be fully licensed; non-designated nodes where GoldenGate cannot run can be excluded.

This approach requires architectural discipline and must be documented for audit purposes. If GoldenGate processes can failover to unlicensed nodes even as an unintended consequence of a cluster event, Oracle will assert that those nodes required licensing at the time of the failover.

Cloud Hybrid HA/DR Architectures

Cloud hybrid GoldenGate architectures — where on-premises databases replicate to cloud environments, or where cloud instances are used as cost-effective DR sites — introduce additional licensing complexity beyond standard on-premises deployment rules.

AWS and Azure as DR Targets

When GoldenGate is deployed on Amazon Web Services or Microsoft Azure as a DR target, the organisation must bring its own GoldenGate licence. Neither AWS nor Azure offers GoldenGate as a managed licensed service. The cloud instance running GoldenGate Replicat at the DR site must be licensed using the cloud vCPU rule: two vCPUs equal one processor licence, regardless of cloud provider or instance family.

Consider a typical DR architecture: an on-premises source database with 16 processors runs GoldenGate Extract, replicating to an AWS r5.8xlarge instance (32 vCPUs) running GoldenGate Replicat. The on-premises side requires 16 processor licences (standard on-premises calculation). The AWS DR instance requires 32 ÷ 2 = 16 processor licences at the cloud rate. Total: 32 GoldenGate processor licences for one active-passive DR pair. At list price, this represents $560,000 in base licence cost before support.

Oracle Cloud Infrastructure as a Cost-Effective DR Option

Oracle Cloud Infrastructure offers GoldenGate as a fully managed service called OCI GoldenGate. Unlike AWS and Azure, OCI GoldenGate bundles the software licence into the OCPU-hour pricing. For organisations that need to licence GoldenGate at a DR site for the first time, OCI GoldenGate can represent a substantially lower initial investment than purchasing on-premises or BYOL cloud licences, because there is no upfront licence cost — only consumption-based compute charges.

BYOL mode on OCI allows organisations with existing on-premises GoldenGate licences to deploy on OCI at a reduced hourly rate that credits the licence value against the service charge. For enterprises already carrying GoldenGate licences, this can make OCI GoldenGate the most cost-efficient DR target from a total cost of ownership perspective, while also simplifying the licence compliance position relative to self-managed BYOL deployments on non-Oracle clouds.

Multi-Site and Hub-and-Spoke HA Topologies

Enterprise GoldenGate deployments often extend beyond two sites into multi-site hub-and-spoke or mesh replication topologies where one primary site replicates to multiple secondaries, or where each site replicates to multiple others. In these topologies, the licensing obligation scales with the number of sites and the processor counts at each location.

The most common under-licensing scenario in multi-site deployments is treating the hub site as the only site requiring full bilateral licensing. Where spoke sites receive data from the hub (and thus run active Replicat processes), each spoke site requires full GoldenGate licensing on the processors where Replicat runs. This is true whether the spoke receives replicated data for read-only reporting, analytics offload, geographic distribution, or DR readiness.

Organisations deploying GoldenGate for global data distribution — where a central hub database feeds regional databases for local performance optimisation — can accumulate significant licensing obligations across all regional sites, even if each regional site is relatively small. The cumulative processor count across all spoke sites frequently exceeds the primary hub count in global deployments.

Licensing Checklist for HA and DR Architectures

The following checklist summarises the actions required to establish an accurate GoldenGate licence position for high availability and disaster recovery deployments:

• Map every GoldenGate process: Identify all Extract and Replicat processes running in your environment, including those at DR sites, standby clusters, cloud targets, and spoke databases.
• Count processors at every active site: For each location where GoldenGate processes run continuously, calculate the licensed processor count using the appropriate method (on-premises core factor, or cloud 2 vCPU = 1 processor rule).
• Verify RAC node coverage: Confirm that all nodes to which GoldenGate can failover within a RAC cluster are licensed, or document the architectural restrictions that prevent GoldenGate from running on specific nodes.
• Do not assume the 10-day rule applies: Unless your DR architecture involves a fully idle passive node with no active GoldenGate processes, the 10-day failover exception does not protect the DR site.
• Review cloud DR instances: For AWS or Azure DR targets, apply the 2 vCPU = 1 processor calculation and confirm that existing licence entitlements cover the cloud instance sizes deployed.
• Consider OCI GoldenGate for new DR deployments: If establishing new DR capacity where no GoldenGate licence currently exists, OCI GoldenGate's consumption-based model avoids the upfront licence investment required for on-premises or BYOL cloud deployments.

What Happens If the DR Site Is Unlicensed?

An unlicensed GoldenGate deployment at a DR site discovered during an Oracle audit generates the same type of finding as any other licence shortfall: Oracle presents the processor shortfall at list price and seeks immediate remediation. The financial exposure depends on the processor count at the DR site and how long GoldenGate has been running there without proper licence coverage.

Oracle may seek backdated support charges in addition to the licence shortfall if the audit finds that the unlicensed deployment predates the current audit period. The combination of licence shortfall at list price, backdated support, and the cost of negotiating a settlement with Oracle's LMS and commercial teams means that a single unlicensed DR site can cost more to resolve than it would have cost to licence it correctly at the time of deployment.

Independent advisory at the point of architecture design — not after an audit notification — is the most cost-effective way to ensure HA and DR deployments are correctly licenced. Redress Compliance works with infrastructure architects and procurement teams to calculate accurate licence requirements before deployment decisions are finalised, preventing the compliance gaps that create audit exposure.