GoldenGate has evolved significantly over the last few years. With GoldenGate Microservices Architecture (MA), the old classic architecture with its manager, extract, replicat processes managed via GGSCI commands is giving way to a REST API-driven, web-console-managed platform. And on OCI, GoldenGate is available as a fully managed service. This post covers what’s changed, what stays the same, and the integration patterns I’m seeing most in 2025 enterprise environments.

Why GoldenGate Over Data Guard for Data Distribution

This question comes up constantly. The answer is: they solve different problems.

Data Guard is a high availability and disaster recovery solution. It maintains a synchronized copy of your database for failover. The standby is a full replica of the primary — same schema, same data, same objects. You can’t selectively replicate only certain tables. You can’t replicate to a different database type. You can’t use the standby for real-time analytics with transformed data.

GoldenGate is a data integration and replication platform. It captures change data (inserts, updates, deletes) from the source database transaction log and applies them to one or more targets. Those targets can be:

• Oracle to Oracle (same or different version)
• Oracle to PostgreSQL, MySQL, SQL Server, Kafka, BigQuery
• Heterogeneous replication in any direction

Use Data Guard for HA/DR of your primary Oracle database. Use GoldenGate when you need to move data somewhere else — a data warehouse, a different database platform, a streaming platform, or a reporting replica with different schema design.

GoldenGate Microservices Architecture — Key Concepts

In GoldenGate MA, the components are:

Extract — Reads the source database redo/archive logs and captures changes. Two modes:

• Integrated Extract: uses Oracle LogMiner internally, runs as a database server process
• Classic Extract: reads redo logs directly from OS level

Trail Files — Intermediate files that store captured changes in GoldenGate’s proprietary format. Acts as a buffer between capture and delivery.

Replicat — Reads trail files and applies changes to the target. Multiple modes:

• Integrated Replicat: uses Oracle’s inbound server for parallelism
• Parallel Replicat: GoldenGate manages its own parallelism, highest throughput
• Coordinated Replicat: user-defined threading

Distribution Service — Moves trail files from source deployment to target deployment over TCP.

REST API Administration — All of this is managed through REST APIs, a web console, or OCI console (for managed GoldenGate).

The Supplemental Logging Requirement You Can’t Skip

Before GoldenGate can capture any changes from an Oracle source, supplemental logging must be enabled. Without it, Oracle’s redo logs don’t contain enough information for GoldenGate to identify which rows changed.

sql

-- Enable minimal supplemental logging at database level (required)
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
-- Verify
SELECT supplemental_log_data_min FROM v$database;
-- For UPDATE tracking, you need ALL columns or key columns logged
-- Enable for specific tables (recommended for targeted replication)
ALTER TABLE hr.employees ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
-- Or enable ALL columns at database level (more overhead, simpler management)
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

The performance overhead of supplemental logging is real — it increases redo generation. For heavily updated tables, ALL COLUMNS supplemental logging can increase redo volume by 20-30%. For insert-heavy tables, the overhead is minimal. Size your redo logs and archive log storage accordingly.

Conflict Detection and Resolution — The Hard Part of Bidirectional Replication

Active-active (bidirectional) replication with GoldenGate is technically possible and is used in some architectures where geographic write distribution is needed. It’s also the most complex GoldenGate configuration and the one most prone to subtle data integrity issues.

The fundamental challenge: if the same row is updated in Site A and Site B within the replication lag window, you have a conflict. Both changes will replicate to the other site. Without conflict detection, one update silently overwrites the other. Without conflict resolution, you don’t know which update was “right.”

GoldenGate provides CDR (Conflict Detection and Resolution) with several resolution strategies:

-- In Replicat parameter file
MAP hr.employees, TARGET hr.employees,
    RESOLVECONFLICT (UPDATEROWEXISTS,
                     (DEFAULT, USEMAX (last_update_timestamp)));

USEMAX resolves conflicts by keeping the version with the higher value in the specified column — in this case, the most recently updated record wins. This works if every row has a reliable last-update timestamp. If your application doesn’t maintain this column, you have a problem before you even start thinking about GoldenGate.

For most production active-active deployments I’ve seen that work well, the architecture partitions write traffic — tables or rows are owned by one site, and the other site gets a read replica of that data. True multi-master concurrent writes to the same rows are usually a sign that the architecture needs rethinking, not that more sophisticated conflict resolution is needed.

GoldenGate on OCI — Managed Service vs Self-Managed

OCI GoldenGate is a fully managed service. You provision a deployment, connect your source and target credentials, and manage processes through a web console or REST API. Oracle handles patching, availability, and infrastructure.

What you give up with managed GoldenGate:

• No OS-level access to trail files (you manage through APIs)
• Less flexibility in advanced parameter configuration
• Slightly higher cost than self-managed on a compute instance

What you gain:

• No GoldenGate software installation and patching
• High availability built in
• Native OCI connectivity (private endpoints, VCN peering)
• Direct integration with OCI services (Autonomous Database, Kafka in OCI Streaming)

For most Oracle-to-Oracle OCI replication use cases, managed GoldenGate is the right choice. For complex heterogeneous pipelines with unusual source systems or heavy customization, self-managed on a compute instance gives you more control.

Monitoring Replication Lag — The Metric That Matters

The most important operational metric for any GoldenGate deployment is replication lag — the delay between when a change is committed in the source and when it’s applied at the target.

In GoldenGate MA, monitor lag through the REST API or admin console. More practically, query it directly:

sql

-- On target: compare source commit timestamp to current time
SELECT source_commit_timestamp,
       SYSDATE - source_commit_timestamp lag_in_days,
       ROUND((SYSDATE - source_commit_timestamp) * 24 * 60, 2) lag_in_minutes
FROM (
    SELECT MAX(timestamp) source_commit_timestamp
    FROM gg_heartbeat  -- GoldenGate heartbeat table
);

GoldenGate’s heartbeat mechanism sends periodic records from source to target. The lag on the heartbeat record tells you the end-to-end replication delay. Set up alerting when lag exceeds your threshold — usually 60 seconds for near-real-time use cases, but depends on your SLA.