Skip to main content
OCIDatabasesadvanced

OCI GoldenGate Guide

Configure real-time data replication with OCI GoldenGate: deployments, connections, extract/replicat processes, pipelines, and CDC patterns.

CloudToolStack Team24 min readPublished Mar 14, 2026

Prerequisites

  • Understanding of database replication concepts
  • OCI account with GoldenGate and database permissions

Introduction to OCI GoldenGate

OCI GoldenGate is a fully managed, real-time data replication and integration service that enables you to replicate data across heterogeneous databases and platforms with sub-second latency. Built on Oracle GoldenGate technology, the managed service eliminates the complexity of installing, configuring, patching, and managing GoldenGate infrastructure while providing the same powerful capabilities for change data capture (CDC), data replication, and data integration.

GoldenGate excels at continuous, real-time data movement between Oracle databases, as well as cross-platform replication between Oracle and non-Oracle databases including MySQL, PostgreSQL, SQL Server, MongoDB, and Apache Kafka. It supports bidirectional replication, data transformation during transit, conflict detection and resolution, and zero-downtime database migrations.

This guide covers deploying OCI GoldenGate, creating connections and deployments, configuring extract and replicat processes, building replication pipelines, handling schema changes, and production best practices for data replication.

OCI GoldenGate Editions

OCI GoldenGate is available in two editions: Standard for Oracle-to-Oracle replication, and Enterprise for heterogeneous replication supporting Oracle, MySQL, PostgreSQL, SQL Server, MongoDB, Kafka, and Big Data targets. Both editions are billed per OCPU-hour. The service also includes a free trial with 2 OCPUs for 30 days.

GoldenGate Architecture

OCI GoldenGate uses a deployment-based architecture where each deployment is an isolated GoldenGate instance with its own compute resources, management console, and process configurations. A deployment can host multiple extract and replicat processes, enabling complex multi-source, multi-target replication topologies.

The key components are:

Deployments: Managed GoldenGate instances that run extract and replicat processes. Each deployment is provisioned with a specific OCPU count and is associated with a VCN subnet for network connectivity.

Connections: Database connection definitions that specify the endpoint, credentials, and connection properties for source and target databases. Connections are reusable across multiple deployments.

Extracts: Processes that capture changes from the source database transaction logs (redo logs for Oracle, binlog for MySQL) and write them to trail files.

Replicats: Processes that read trail files and apply the changes to the target database. Replicats support filtering, mapping, and transformations during the apply phase.

bash
# Create a GoldenGate deployment
oci goldengate deployment create \
  --compartment-id $C \
  --display-name "production-gg" \
  --license-model "LICENSE_INCLUDED" \
  --deployment-type "DATABASE_ORACLE" \
  --subnet-id <private-subnet-ocid> \
  --cpu-core-count 2 \
  --is-auto-scaling-enabled true \
  --ogg-data '{"deploymentName": "prod_gg", "adminUsername": "oggadmin", "adminPassword": "<password>"}' \
  --is-public false \
  --wait-for-state ACTIVE

# List GoldenGate deployments
oci goldengate deployment list \
  --compartment-id $C \
  --query 'data.items[].{"display-name":"display-name", "deployment-type":"deployment-type", "cpu-core-count":"cpu-core-count", "lifecycle-state":"lifecycle-state"}' \
  --output table

# Get deployment details (including the console URL)
oci goldengate deployment get \
  --deployment-id <deployment-ocid> \
  --query 'data.{"display-name":"display-name", "deployment-url":"deployment-url", "lifecycle-state":"lifecycle-state"}'

Creating Database Connections

Connections define the source and target endpoints for your replication pipelines. Each connection specifies the database type, hostname, port, credentials, and connection properties. OCI GoldenGate stores credentials securely and supports integration with OCI Vault for enhanced secret management.

Before creating connections, ensure network connectivity between the GoldenGate deployment and the database endpoints. The deployment must be able to reach both source and target databases through the VCN, VPN, or FastConnect. Use private endpoints whenever possible for security.

bash
# Create an Oracle Database connection
oci goldengate connection create \
  --compartment-id $C \
  --display-name "source-oracle-db" \
  --connection-type "ORACLE_DATABASE" \
  --technology-type "ORACLE_DATABASE" \
  --database-id <database-ocid> \
  --username "ggadmin" \
  --password "<password>" \
  --session-mode "DIRECT" \
  --subnet-id <private-subnet-ocid>

# Create a MySQL connection
oci goldengate connection create \
  --compartment-id $C \
  --display-name "target-mysql" \
  --connection-type "MYSQL" \
  --technology-type "OCI_MYSQL" \
  --database-id <mysql-db-ocid> \
  --username "ggadmin" \
  --password "<password>" \
  --subnet-id <private-subnet-ocid>

# Create a Kafka connection
oci goldengate connection create \
  --compartment-id $C \
  --display-name "kafka-target" \
  --connection-type "KAFKA" \
  --technology-type "OCI_STREAMING" \
  --stream-pool-id <stream-pool-ocid> \
  --bootstrap-servers "<bootstrap-url>" \
  --security-protocol "SASL_SSL" \
  --username "<tenancy>/<username>/<stream-pool-ocid>" \
  --password "<auth-token>"

# List connections
oci goldengate connection list \
  --compartment-id $C \
  --query 'data.items[].{"display-name":"display-name", "connection-type":"connection-type", "technology-type":"technology-type", "lifecycle-state":"lifecycle-state"}' \
  --output table

# Assign a connection to a deployment
oci goldengate deployment-backup create \
  --compartment-id $C \
  --deployment-id <deployment-ocid> \
  --display-name "pre-config-backup" \
  --bucket-name "gg-backups" \
  --namespace $NAMESPACE \
  --object-name "backup-001"

Configuring Extract and Replicat Processes

Extract and Replicat processes are the core data movement components. Extract captures changes from the source database, and Replicat applies them to the target. Configuration is performed through the GoldenGate Administration Console or via the REST API.

Initial Load Extract: Performs a one-time bulk copy of existing data from the source to the target. This is used to establish the baseline data before starting continuous replication.

Change Data Capture (CDC) Extract: Continuously captures changes (inserts, updates, deletes) from the source database transaction logs. This process runs continuously and captures changes in near real-time.

Replicat: Reads changes from trail files and applies them to the target database. Supports parallel apply for high throughput, conflict detection for bidirectional replication, and data transformations for schema differences.

bash
# GoldenGate configuration is typically done via the Admin Console
# Access the console at the deployment URL:
# https://<deployment-url>/

# Example: Configure Extract via GoldenGate REST API
# curl -X POST https://<deployment-url>/services/v2/extracts/EXT_SRC \
#   -H "Authorization: Basic <base64-credentials>" \
#   -H "Content-Type: application/json" \
#   -d '{
#     "config": [
#       "EXTRACT EXT_SRC",
#       "USERIDALIAS source_db",
#       "EXTTRAIL ./dirdat/aa",
#       "TABLE HR.EMPLOYEES;",
#       "TABLE HR.DEPARTMENTS;",
#       "TABLE SALES.*;"
#     ]
#   }'

# Example: Configure Replicat via REST API
# curl -X POST https://<deployment-url>/services/v2/replicats/REP_TGT \
#   -H "Authorization: Basic <base64-credentials>" \
#   -H "Content-Type: application/json" \
#   -d '{
#     "config": [
#       "REPLICAT REP_TGT",
#       "USERIDALIAS target_db",
#       "MAP HR.EMPLOYEES, TARGET HR.EMPLOYEES;",
#       "MAP HR.DEPARTMENTS, TARGET HR.DEPARTMENTS;",
#       "MAP SALES.*, TARGET SALES.*;"
#     ]
#   }'

# Monitor process status via REST API
# curl https://<deployment-url>/services/v2/extracts/EXT_SRC/info/status \
#   -H "Authorization: Basic <base64-credentials>"

# Check replication lag
# curl https://<deployment-url>/services/v2/replicats/REP_TGT/info/lag \
#   -H "Authorization: Basic <base64-credentials>"

Source Database Preparation

Before configuring GoldenGate extracts, the source database must be prepared. For Oracle databases, enable supplemental logging at the database and table level. For MySQL, enable binary logging with binlog_format=ROW. For PostgreSQL, configure logical replication with wal_level=logical. Without proper source configuration, extracts will fail to capture all changes accurately.

Replication Pipelines

OCI GoldenGate Pipelines provide a simplified, visual approach to configuring data replication. Instead of manually configuring extract and replicat processes, pipelines let you define source-to-target mappings with a few parameters. The service automatically creates and manages the underlying GoldenGate processes.

Pipelines support one-to-one and one-to-many replication patterns. You can replicate entire schemas, specific tables, or filtered subsets of data. Pipelines also support schema mapping to replicate data between databases with different schema names or table structures.

bash
# Create a replication pipeline
oci goldengate pipeline create \
  --compartment-id $C \
  --display-name "oracle-to-mysql-pipeline" \
  --license-model "LICENSE_INCLUDED" \
  --source-connection-detail '{"connectionId": "<source-connection-ocid>"}' \
  --target-connection-detail '{"connectionId": "<target-connection-ocid>"}' \
  --recipe-type "ZERO_ETL"

# List pipelines
oci goldengate pipeline list \
  --compartment-id $C \
  --query 'data.items[].{"display-name":"display-name", "lifecycle-state":"lifecycle-state", "recipe-type":"recipe-type"}' \
  --output table

# Start the pipeline
oci goldengate pipeline start \
  --pipeline-id <pipeline-ocid>

# Stop the pipeline
oci goldengate pipeline stop \
  --pipeline-id <pipeline-ocid>

# Monitor pipeline health
oci goldengate pipeline get \
  --pipeline-id <pipeline-ocid> \
  --query 'data.{"lifecycle-state":"lifecycle-state", "time-last-recorded":"time-last-recorded"}'

Data Transformation and Filtering

GoldenGate supports data transformation during replication, allowing you to modify data as it moves from source to target. Transformations include column mapping, data type conversion, value substitution, column concatenation and splitting, and custom SQL expressions.

Filtering allows you to replicate only a subset of data based on conditions. You can filter by table name patterns, column values, or custom WHERE clauses. This is useful for geographic data partitioning, compliance requirements, or replicating only active records.

bash
# Example GoldenGate configuration with transformations:

# Column mapping and renaming:
# MAP source.EMPLOYEES, TARGET target.EMP,
#   COLMAP (
#     emp_id = EMPLOYEE_ID,
#     full_name = @STRCAT(FIRST_NAME, ' ', LAST_NAME),
#     hire_date = HIRE_DATE,
#     salary_usd = @IF(CURRENCY = 'EUR', SALARY * 1.08, SALARY),
#     region = @CASE(COUNTRY_ID,
#       'US', 'North America',
#       'CA', 'North America',
#       'UK', 'Europe',
#       'DE', 'Europe',
#       DEFAULT, 'Other')
#   );

# Table-level filtering:
# MAP source.ORDERS, TARGET target.ORDERS,
#   FILTER (@STREQ(STATUS, 'ACTIVE'));

# Schema-level replication with exclusions:
# MAP source.HR.*, TARGET target.HR.*,
#   MAPEXCLUDE source.HR.AUDIT_LOG,
#   MAPEXCLUDE source.HR.TEMP_*;

# Partitioned replication (geographic):
# MAP source.CUSTOMERS, TARGET target_us.CUSTOMERS,
#   FILTER (@STREQ(REGION, 'US'));
# MAP source.CUSTOMERS, TARGET target_eu.CUSTOMERS,
#   FILTER (@STREQ(REGION, 'EU'));

Schema Changes and DDL Replication

Handling schema changes (DDL) during replication is one of the most challenging aspects of data replication. GoldenGate supports DDL replication for Oracle-to-Oracle scenarios, automatically applying CREATE, ALTER, and DROP statements to the target database.

For heterogeneous replication (e.g., Oracle to MySQL), DDL replication is limited. Schema changes on the source may require manual intervention on the target, such as adding columns, modifying data types, or recreating tables. Plan a DDL change management process that coordinates source schema changes with replication configuration updates.

bash
# DDL configuration for Oracle-to-Oracle replication:

# Enable DDL replication on the extract:
# EXTRACT EXT_SRC
# USERIDALIAS source_db
# DDL INCLUDE ALL
# EXTTRAIL ./dirdat/aa
# TABLE HR.*;

# Enable DDL apply on the replicat:
# REPLICAT REP_TGT
# USERIDALIAS target_db
# DDL INCLUDE ALL
# MAP HR.*, TARGET HR.*;

# DDL filtering - only replicate specific DDL types:
# DDL INCLUDE MAPPED OBJTYPE 'TABLE' OPTYPE ALTER
# DDL INCLUDE MAPPED OBJTYPE 'TABLE' OPTYPE CREATE
# DDL EXCLUDE ALL

# Monitor DDL replication status
# GoldenGate Admin Console > Extract/Replicat > Statistics > DDL

Monitoring and Troubleshooting

Monitoring GoldenGate replication health is critical for ensuring data consistency and detecting issues before they impact downstream systems. OCI GoldenGate emits metrics to OCI Monitoring and provides a built-in administration console with real-time process status, lag metrics, and error logs.

The most important metric to monitor is replication lag, which measures the time difference between when a change occurs on the source and when it is applied to the target. High lag indicates that the replicat process cannot keep up with the extract rate and may require tuning or scaling.

bash
# Monitor GoldenGate deployment metrics
oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_goldengate" \
  --query-text 'DeploymentCpuUtilization[5m]{resourceId = "<deployment-ocid>"}.mean()'

# Monitor replication lag
oci monitoring metric-data summarize-metrics-data \
  --compartment-id $C \
  --namespace "oci_goldengate" \
  --query-text 'ReplicatLag[1m]{resourceId = "<deployment-ocid>"}.max()'

# Create an alarm for high replication lag
oci monitoring alarm create \
  --compartment-id $C \
  --display-name "gg-high-lag" \
  --metric-compartment-id $C \
  --namespace "oci_goldengate" \
  --query-text 'ReplicatLag[5m]{resourceId = "<deployment-ocid>"}.max() > 300' \
  --severity "WARNING" \
  --destinations '["<ops-topic-ocid>"]' \
  --is-enabled true \
  --body "GoldenGate replication lag exceeds 5 minutes"

# Create an alarm for process failures
oci monitoring alarm create \
  --compartment-id $C \
  --display-name "gg-process-abended" \
  --metric-compartment-id $C \
  --namespace "oci_goldengate" \
  --query-text 'ProcessStatus[1m]{processStatus = "ABENDED"}.count() > 0' \
  --severity "CRITICAL" \
  --destinations '["<critical-topic-ocid>"]' \
  --is-enabled true \
  --body "GoldenGate process has abended"

# Backup a deployment
oci goldengate deployment-backup create \
  --compartment-id $C \
  --deployment-id <deployment-ocid> \
  --display-name "gg-backup-2026-03-14" \
  --bucket-name "gg-backups" \
  --namespace $NAMESPACE \
  --object-name "backup-2026-03-14"

Production Best Practices

Running GoldenGate in production requires careful planning for high availability, performance, and disaster recovery:

High Availability: Enable auto-scaling on your deployment to handle traffic spikes. Create deployment backups on a regular schedule and test restoration procedures. For critical replication streams, consider running a standby deployment in a secondary region.

Network Security: Place GoldenGate deployments in private subnets with no public IP. Use NSGs to restrict access to only the source and target database ports. Enable TLS encryption for all database connections and the admin console.

Performance: Size your deployment OCPUs based on the transaction volume of your source database. Each OCPU can typically handle 5,000 to 10,000 transactions per second, depending on row size and complexity. Enable parallel replicat for high-throughput targets.

Data Validation: Regularly validate data consistency between source and target using row counts, checksums, or sampling queries. GoldenGate provides the VERIDATA utility for automated comparison, but simple SQL comparisons can catch most issues.

Change Management: Coordinate GoldenGate configuration changes with application deployments. Test replication changes in a non-production environment before applying them to production. Use deployment backups before making configuration changes for easy rollback.

Autonomous Database on OCIOCI MySQL HeatWave GuideOCI Streaming & Events Guide

Key Takeaways

  1. 1GoldenGate provides sub-second replication latency for real-time data integration.
  2. 2Supports heterogeneous replication between Oracle, MySQL, PostgreSQL, SQL Server, and Kafka.
  3. 3Pipelines offer a simplified no-code approach to configuring replication workflows.
  4. 4Data transformations and filtering can be applied during replication without impacting the source.

Frequently Asked Questions

What is the difference between GoldenGate Standard and Enterprise editions?
Standard edition supports Oracle-to-Oracle replication only. Enterprise edition adds heterogeneous replication supporting Oracle, MySQL, PostgreSQL, SQL Server, MongoDB, Apache Kafka, and Big Data targets. Both editions support CDC, initial load, and bidirectional replication. Enterprise edition is required for cross-platform migrations and multi-database data integration.
Can GoldenGate be used for zero-downtime database migrations?
Yes, GoldenGate is commonly used for zero-downtime migrations. The process involves: (1) initial load to copy existing data, (2) start CDC to replicate ongoing changes, (3) wait for replication lag to reach near-zero, (4) briefly quiesce the source, (5) verify target consistency, (6) switch application connections to the target. Total downtime is typically measured in seconds to minutes.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.