Oracle Cloud GoldenGate Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Integration

1. Introduction

GoldenGate on Oracle Cloud is Oracle’s managed, cloud-native way to run Oracle GoldenGate for real-time data replication and change data capture (CDC) across databases and data platforms.

In simple terms: GoldenGate continuously reads changes from a source database (inserts/updates/deletes) and applies them to a target system with very low latency, so your systems stay in sync without heavy batch jobs.

Technically, GoldenGate is a log-based replication engine (CDC) that captures changes from database transaction logs, stages them as trails, and delivers them to one or more targets. On Oracle Cloud, OCI GoldenGate provisions and manages the GoldenGate software stack for you, while you configure replication pipelines (Extract/Replicat, paths, checkpoints) via the GoldenGate Microservices UI and OCI resources (Deployments, Connections).

The main problem GoldenGate solves is keeping data synchronized across heterogeneous systems for migrations, analytics, active-active architectures, operational reporting, and event-driven integration—without locking tables or relying on fragile “poll and compare” patterns.

Naming note (important): Oracle has a long GoldenGate product history. In Oracle Cloud, the current managed service is commonly referred to as Oracle Cloud Infrastructure (OCI) GoldenGate. Older “classic” cloud offerings such as Oracle GoldenGate Cloud Service (from Oracle Cloud “Classic”) may appear in legacy content; treat those as legacy and verify current guidance in OCI documentation before following older tutorials.

2. What is GoldenGate?

Official purpose

GoldenGate is Oracle’s platform for real-time data replication and change data capture (CDC). In OCI, GoldenGate is delivered as a managed service where you create a GoldenGate Deployment and configure replication pipelines to move changes from sources to targets.

Core capabilities

Log-based CDC: reads database transaction logs rather than querying tables.
Real-time replication: continuously delivers changes with low latency.
Heterogeneous replication (varies by supported connectors/version): commonly used across Oracle databases and other platforms; always confirm supported technologies in the OCI GoldenGate docs for your region/version.
Migration and synchronization: keep old and new systems in sync during cutovers.
High availability / resilience patterns: support for multiple targets, restartability, checkpoints, and replay after transient failures.

Major components (conceptual)

GoldenGate’s traditional concepts still apply even when managed: – Extract: capture process reading source logs. – Data Pump (optional): routes data from local to remote trails. – Trail files: staged change records (local and/or remote). – Replicat: apply process writing changes to the target. – Checkpointing: ensures restartability without reprocessing committed data. – GoldenGate Microservices: web-based administration services (Administration Server, Distribution Server, Receiver Server, Performance Metrics Server) used by OCI GoldenGate deployments. Exact microservice names and exposure depend on the deployment model—verify in official docs.

Service type

Managed service on Oracle Cloud Infrastructure for running GoldenGate (you manage replication configuration; Oracle manages much of the underlying service infrastructure depending on the service model and responsibilities described in the docs).

Scope (regional/compartment)

Regional: OCI resources are created in a specific OCI region.
Compartment-scoped: Deployments and Connections live in an OCI compartment and are governed by IAM policies.
Networking is VCN-based: the Deployment is attached to subnets you choose.

How it fits into the Oracle Cloud ecosystem

GoldenGate is an Integration service when your integration problem is data movement and CDC (not application-to-application workflow orchestration). It typically pairs with: – Oracle Autonomous Database (ATP/ADW) or Oracle Database on OCI – Networking (VCN, subnets, NSGs, DRG) for connectivity – OCI IAM for access control – OCI Logging / Monitoring / Audit for operations and governance

Official documentation entry point (start here):
https://docs.oracle.com/en/cloud/paas/goldengate-service/

3. Why use GoldenGate?

Business reasons

Reduce downtime during migrations by keeping source and target synchronized until cutover.
Enable real-time analytics without impacting OLTP performance with heavy reporting queries.
Support modern architectures (data mesh, streaming-enabled integration) by feeding downstream systems continuously.

Technical reasons

Log-based capture is typically more efficient and accurate than timestamp-based polling or triggers.
Low-latency replication enables near-real-time data products.
Checkpointed, restartable pipelines handle transient failures better than custom scripts.

Operational reasons

Managed deployment in Oracle Cloud reduces operational overhead compared to self-managing GoldenGate hosts.
Centralized configuration and visibility via GoldenGate Microservices UI plus OCI monitoring/logging integrations (capabilities depend on the service integration—verify exact metric/log coverage in docs).

Security/compliance reasons

Supports patterns that keep sensitive source systems isolated while feeding sanitized targets.
Works with OCI-native IAM and network controls (compartments, NSGs, private endpoints).
Helps with auditability by enabling controlled, repeatable replication processes (plus OCI Audit for API operations).

Scalability/performance reasons

Designed for high-volume and continuous change streams when correctly sized and configured.
Supports parallelism patterns (where applicable) and efficient log mining.

When teams should choose it

Choose GoldenGate when you need: – Continuous, reliable CDC replication – Migration with minimal downtime – Multi-system synchronization – Real-time feed into operational reporting or analytics targets

When teams should not choose it

Avoid GoldenGate when: – You only need occasional batch ETL (simpler tools may be cheaper and easier). – Your integration is mainly API/workflow orchestration (consider Oracle Integration instead). – Your source/target technology is not supported in OCI GoldenGate for your region/version (verify support matrix in docs). – You cannot meet network/security prerequisites (private connectivity, ports, credentials, wallets).

4. Where is GoldenGate used?

Industries

Financial services (payments, fraud analytics, operational risk)
Retail/e-commerce (inventory, orders, personalization)
Telecom (billing, customer 360)
Healthcare/life sciences (operational reporting, data consolidation)
Manufacturing/logistics (real-time supply chain views)
SaaS providers (multi-tenant reporting pipelines)

Team types

Database engineering / DBA teams
Data engineering teams
Cloud platform teams
Integration engineers
SRE/operations teams supporting data platforms

Workloads

Zero/low-downtime database migrations
Real-time operational reporting
Cross-region replication (with careful network design)
Feeding analytics stores (data warehouse / lakehouse patterns)
Keeping microservices read models synchronized (where CDC is appropriate)

Architectures

Hub-and-spoke replication topology
Active-passive modernization (legacy → new)
Dual-write avoidance (single-write + CDC)
Multi-target fan-out for analytics and search systems (if supported targets/connectors are available)

Production vs dev/test usage

Production: strict sizing, HA strategy, change management, auditing, and network isolation.
Dev/test: small deployments for pipeline development, schema mapping tests, and cutover rehearsals. Cost control matters because managed deployments typically bill while running.

5. Top Use Cases and Scenarios

Below are realistic GoldenGate scenarios. Exact supported source/target combinations depend on the OCI GoldenGate supported technologies for your service version—verify in official docs.

1) Zero-downtime migration: Oracle Database to Autonomous Database

Problem: Migrate an OLTP database to Autonomous Transaction Processing (ATP) with minimal downtime.
Why GoldenGate fits: Continuous CDC keeps the target synchronized while apps still write to the source.
Example: Replicate from an on-VM Oracle Database to ATP, validate, then switch application connection strings.

2) Real-time reporting offload

Problem: Reporting queries slow down the OLTP database.
Why GoldenGate fits: Replicate OLTP changes into a reporting database/warehouse.
Example: Replicate order tables into an ADW reporting schema for dashboards.

3) Cross-environment synchronization (dev/test from prod-like data)

Problem: Refresh dev/test environments frequently without full backups/restores.
Why GoldenGate fits: Continuous sync plus filtering/masking patterns (where applicable).
Example: Keep a test environment updated nightly with a controlled replication window.

4) Blue/green database cutover

Problem: Upgrade database version or platform with a reversible cutover.
Why GoldenGate fits: Run old and new in parallel and cut over when stable.
Example: Keep “blue” and “green” databases synchronized; switch traffic using app config.

5) Event-driven integration seed (CDC to streaming)

Problem: Microservices need near-real-time change events without adding load to the DB.
Why GoldenGate fits: CDC is a natural event source; GoldenGate can publish change records to downstream consumers if supported adapters are available in your deployment.
Example: Publish customer change events to a messaging system (verify supported targets/adapters).

6) Multi-target fan-out

Problem: Multiple systems need the same authoritative data updates.
Why GoldenGate fits: Capture once, distribute to multiple targets (architecture and licensing/service constraints apply).
Example: Replicate product catalog updates to both analytics and search targets.

7) Active-active (bi-directional) patterns (advanced)

Problem: Two regions/sites must accept writes (conflict detection required).
Why GoldenGate fits: GoldenGate can support bidirectional replication patterns with careful conflict handling.
Example: Two Oracle databases replicate in both directions for regional resilience (complex; plan thoroughly).

8) Data consolidation from multiple sources

Problem: Combine data from multiple OLTP systems into a consolidated store.
Why GoldenGate fits: Multiple Extracts feed a centralized target.
Example: Consolidate regional order systems into a central ADW schema.

9) Modernize a monolith incrementally

Problem: Decompose a monolith without rewriting everything at once.
Why GoldenGate fits: CDC can keep new service databases populated from the monolith.
Example: Build a new “Customer Profile” service and keep it synced from the monolith schema.

10) Operational resilience and fast recovery

Problem: Need fast recovery to a warm standby target.
Why GoldenGate fits: Continuous replication can reduce RPO for certain patterns (not a replacement for backups).
Example: Maintain a warm standby schema for fast failover of reporting services.

11) Controlled data sharing across compartments/tenancies (governed)

Problem: Share datasets across organizational boundaries with guardrails.
Why GoldenGate fits: Replication pipelines can implement scoped sharing (schema/table-level).
Example: Replicate only approved tables into a shared analytics tenancy (requires network and IAM planning).

12) Database platform change with long coexistence

Problem: Two platforms must coexist for months during vendor/app transition.
Why GoldenGate fits: Continuous sync avoids dual-write in application code.
Example: Keep the new platform in sync while teams migrate downstream dependencies.

6. Core Features

Note: Feature availability depends on OCI GoldenGate version, region, and supported technologies. Always confirm in the official docs.

Managed GoldenGate Deployments (OCI)

What it does: Provisions a GoldenGate runtime (“Deployment”) in your VCN/subnet.
Why it matters: Avoids manual host provisioning, patching workflows, and much of the infrastructure management.
Practical benefit: Faster time to first replication, consistent environments across teams.
Caveats: You still must design networking, IAM, database permissions, and replication topology.

GoldenGate Microservices-based Administration

What it does: Web UI and REST endpoints to manage Extracts, Replicats, paths, and credentials.
Why it matters: Operational control plane for pipelines.
Practical benefit: Easier day-2 ops than legacy command-line-only management.
Caveats: Access to the admin endpoints must be secured (private endpoints, restricted ingress, strong auth).

Connections (OCI resource)

What it does: Stores connection definitions used by Deployments to reach sources/targets (databases, endpoints).
Why it matters: Standardizes connectivity setup and reduces config sprawl.
Practical benefit: Reuse connections across pipelines; consistent compartment governance.
Caveats: Treat connection secrets carefully; use least privilege DB users.

Log-based CDC replication

What it does: Captures committed changes from transaction logs.
Why it matters: Efficient, low overhead, accurate ordering semantics.
Practical benefit: Minimal impact on OLTP workload compared to triggers/polling.
Caveats: Requires correct database logging settings and permissions; initial load is separate from CDC.

Checkpointing and restartability

What it does: Tracks processed log positions and applied transactions.
Why it matters: Enables safe restart after outages.
Practical benefit: Operational resilience; avoids duplicates when configured correctly.
Caveats: Misconfigured checkpoints or credential issues can cause lag and retries.

Filtering, mapping, and basic transformations (GoldenGate parameterization)

What it does: Allows table selection, column mapping, and some transformations in replication config.
Why it matters: Supports selective replication and schema evolution patterns.
Practical benefit: Avoid replicating unnecessary tables/columns; controlled sharing.
Caveats: Heavy transformations might belong in ETL/ELT tools; keep CDC pipelines simple for reliability.

Monitoring and metrics (OCI + GoldenGate)

What it does: Provides operational visibility into deployment status and pipeline health.
Why it matters: CDC is a continuous system; you must detect lag and failures quickly.
Practical benefit: Alerts on replication lag, process down, resource exhaustion (availability depends on integrations).
Caveats: Define SLOs (max lag, RPO) and alerting thresholds; metrics differ by deployment model.

VCN-based networking

What it does: Runs the deployment attached to your subnets and security controls.
Why it matters: Private connectivity to private databases; enforce network segmentation.
Practical benefit: Keeps replication traffic off the public internet.
Caveats: Requires planning for DNS, routing, gateways, and database access controls.

7. Architecture and How It Works

High-level service architecture

OCI GoldenGate typically consists of: – OCI control plane: where you create and manage Deployments and Connections (IAM-governed). – GoldenGate runtime (data plane): the actual GoldenGate processes running inside the deployment in your VCN. – Source and target endpoints: databases or platforms the deployment connects to over the network. – Admin access path: how administrators reach the GoldenGate Microservices UI (private endpoint preferred).

Request/data/control flow

You create a Deployment (and required networking).
You define Connections to source/target endpoints.
In the deployment console, you create Extract to capture changes.
Changes are written to trail files and moved (if needed) to the target side.
A Replicat reads the trail and applies changes to the target.
Checkpoints track progress; if a process restarts, it resumes from last checkpoint.

Integrations with related services

Common integrations around GoldenGate include: – Oracle Autonomous Database (ATP/ADW) or Oracle Database on OCI – OCI Networking (VCN, subnets, NSGs, route tables, gateways) – OCI IAM (groups, policies, compartments) – OCI Logging / Monitoring / Alarms (verify exact integrations and metric namespaces in official docs) – OCI Vault (recommended for secret lifecycle patterns, though the exact “native integration” behavior should be verified)

Dependency services

A VCN and subnet(s) to host the deployment
Source and target databases reachable over the network
IAM policies to create/manage GoldenGate resources

Security/authentication model

OCI IAM: governs who can create deployments/connections and view metadata.
GoldenGate admin users: authentication to the GoldenGate Microservices console (mechanism depends on service configuration).
Database authentication: least-privilege database users for capture/apply.

Networking model

Deployment attached to your chosen subnet(s)
Ingress to admin endpoints should be tightly restricted (NSGs, private endpoints, bastion)
Egress from deployment must reach source/target on required ports (e.g., Oracle Net listener ports for Oracle DB; exact ports depend on your databases)

Monitoring/logging/governance considerations

Track replication lag, process health, trail backlog, database errors.
Enable OCI Audit for governance of GoldenGate resource changes.
Use compartment structure and tagging to separate environments and cost centers.

Simple architecture diagram (conceptual)

flowchart LR
  A[Source Database] -->|Redo/Transaction logs| B[GoldenGate Extract]
  B --> C[(Trail Files)]
  C --> D[GoldenGate Replicat]
  D --> E[Target Database]
  F[OCI Console/IAM] -->|Manage| G[OCI GoldenGate Deployment]
  G --> B
  G --> D

Production-style architecture diagram (OCI-focused)

flowchart TB
  subgraph OCI[Oracle Cloud Infrastructure - Region]
    subgraph Net[VCN]
      subgraph Pub[Public Subnet (optional)]
        Admin[Admin Access Path\n(Bastion/VPN/Allowlisted IPs)]
      end

      subgraph Priv[Private Subnet (recommended)]
        GG[OCI GoldenGate Deployment\n(Microservices + Extract/Replicat)]
      end

      NSG[Network Security Groups]
      NAT[NAT Gateway (if needed for egress)]
      DRG[DRG (optional)\nfor on-prem / other VCNs]
    end

    Mon[OCI Monitoring/Alarms]
    Log[OCI Logging (as supported)]
    Aud[OCI Audit]
  end

  Src[Source DB\n(ATP/Oracle DB on OCI/on-prem)] <-->|DB Port + Auth| GG
  GG <-->|DB Port + Auth| Tgt[Target DB\n(ADW/ATP/Oracle DB)]

  Admin -->|HTTPS to Admin Endpoint| GG
  GG --> Mon
  GG --> Log
  Aud --> OCI
  GG --> NAT
  DRG --- Src
  NSG --- GG

8. Prerequisites

Tenancy/account requirements

An Oracle Cloud tenancy with permissions to create networking, databases (for this lab), and GoldenGate resources.
A compartment strategy (at minimum: a compartment for the lab).

Permissions / IAM roles

You typically need permissions to: – Manage GoldenGate resources in the compartment – Manage VCN/subnets/NSGs (or have them pre-created) – Manage Autonomous Database (for the lab)

OCI IAM is policy-based. Exact policy verbs and resource-types can change—verify the latest policy reference in official docs. As a starting point, you will usually create policies that allow a group to manage GoldenGate resources in a compartment.

Billing requirements

OCI GoldenGate is generally a paid managed service (no universal “Always Free” guarantee). You need:
A paid tenancy, or
Promotional credits / trial credits
Autonomous Databases may have “Always Free” options in some tenancies/regions, but GoldenGate usage may still incur cost.

Tools needed

Web browser for OCI Console and GoldenGate Microservices UI
Optional:
OCI CLI (helpful for automation)
SQL client for Autonomous Database (Database Actions web SQL, SQL Developer, or similar)

Region availability

OCI GoldenGate is not available in every region. Check service availability for your region in OCI docs or the Console region selector.

Quotas/limits

Service limits apply (number of deployments, shapes/sizing, connections). Check:
OCI Console → Governance → Limits, Quotas and Usage
Database limits also apply (connections, CPU, storage).

Prerequisite services

VCN, subnets, security rules
Source and target databases reachable from the GoldenGate deployment network

9. Pricing / Cost

Current pricing model (how it’s typically structured)

OCI GoldenGate pricing is usage-based. The most common cost dimensions you should expect are: – GoldenGate Deployment runtime: billed while the deployment is running (often tied to size/shape or compute units). – Storage used by the deployment (trail files, logs), depending on service design. – Network egress: outbound data transfer to the public internet or across regions (OCI billing rules apply). – Source/target database costs: Autonomous Database, compute instances, storage, backups. – Optional network infrastructure: NAT Gateway, Load Balancer, VPN/FastConnect (if used).

Because SKUs, shapes, and regional price points can change, do not rely on blog-post numbers. Use the official sources below.

Official pricing entry points: – Oracle Cloud price list (search for “GoldenGate”): https://www.oracle.com/cloud/price-list/ – OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html

Free tier

OCI has an Always Free tier for some services, but GoldenGate is not commonly categorized as Always Free. Treat it as paid unless your tenancy explicitly shows a free allowance.
Trials/credits: Oracle frequently offers free trials; eligibility and credits vary.

Primary cost drivers

Keeping a deployment running 24/7
Larger deployment sizing to handle higher redo/log volume
High change rate tables generating large trail volumes
Cross-region or internet-based data transfer
Non-production environments left running

Hidden/indirect costs to plan for

NAT Gateway data processing charges (if your GoldenGate deployment needs outbound internet access from a private subnet)
Operational tooling (logging retention, monitoring alarms)
Database backups and storage growth (targets often grow fast in analytics scenarios)
Connectivity (FastConnect/VPN) if replicating with on-prem sources

Network/data transfer implications

Replication within the same VCN/region is usually cheapest from a data transfer perspective.
Cross-region replication can introduce:
Higher latency (affects lag)
Inter-region data transfer costs
Public internet replication adds security and reliability risks plus potential egress costs.

How to optimize cost

Stop or delete non-prod deployments when not in use.
Right-size deployments based on redo generation and throughput testing.
Filter out unneeded tables/columns early.
Prefer private connectivity within OCI where feasible.
Set retention policies for trail files and logs according to requirements.

Example low-cost starter estimate (how to think about it)

A “starter” lab cost typically includes: – 1 small GoldenGate deployment running for a few hours – 2 small databases (source and target), ideally Always Free where possible – Minimal data transfer within a region

Because actual unit prices depend on region and SKU, calculate using: – OCI Cost Estimator: select GoldenGate (deployment size), storage, and expected runtime.

Example production cost considerations

In production, the bigger costs are usually: – Deployment runtime 24/7 (and HA strategy if you run multiple deployments) – Higher sizing for peak redo rates – Larger storage for trails and logging – Cross-region data transfer and connectivity (FastConnect, DRG, etc.) – Operational overhead (monitoring, on-call, compliance retention)

10. Step-by-Step Hands-On Tutorial

This lab builds a small, real replication pipeline using OCI GoldenGate to replicate a table from a source Autonomous Transaction Processing (ATP) database to a target Autonomous Data Warehouse (ADW) (or a second ATP). The exact screens can change; the core workflow remains consistent.

Objective

Set up a GoldenGate deployment and configure CDC replication for one schema/table from a source Oracle Autonomous Database to a target Autonomous Database, then verify changes replicate in near-real-time.

Lab Overview

You will: 1. Create (or reuse) networking for GoldenGate. 2. Create source and target Autonomous Databases. 3. Create database users and privileges for GoldenGate capture/apply. 4. Create an OCI GoldenGate Deployment. 5. Create OCI GoldenGate Connections to source and target. 6. Configure Extract + Replicat in the GoldenGate deployment console. 7. Insert/update/delete rows in source and verify they appear in target. 8. Clean up all resources to stop billing.

Cost safety: The GoldenGate deployment is typically the main cost driver. Do not leave it running.

Step 1: Create a compartment and basic tags (recommended)

In OCI Console, create a compartment like: – gg-lab
(Optional) Create a tag namespace and tags: – env=lab – owner=<yourname> – costcenter=training

Expected outcome: You have an isolated compartment for all lab resources.

Step 2: Create networking (VCN + subnet) for the GoldenGate deployment

You need a VCN and a subnet where the GoldenGate deployment will live.

Option A (simpler for labs): Public subnet with restricted ingress
Option B (recommended for production): Private subnet + Bastion/VPN + NAT

For a beginner lab, Option A is easier, but lock down access.

Go to Networking → Virtual Cloud Networks → Create VCN
Choose VCN with Internet Connectivity (wizard) or create manually.
Create: – VCN CIDR: e.g., 10.0.0.0/16 – Public subnet CIDR: e.g., 10.0.1.0/24
Create a Network Security Group (NSG) for GoldenGate deployment and restrict ingress: – Allow TCP 443 from your public IP to the GoldenGate admin endpoint (if you enable public access). – Allow egress to the databases (Oracle listener port). For Autonomous Database, connectivity depends on whether you use private endpoint or public endpoint. If public, you’ll use internet routing.

Expected outcome: A VCN and subnet exist; you have an NSG ready to attach to the GoldenGate deployment.

Security note: For production, prefer private endpoints and access via Bastion, VPN, or FastConnect.

Step 3: Create source and target Autonomous Databases (ATP + ADW)

Go to Oracle Database → Autonomous Database → Create Autonomous Database
Create Source ATP: – Workload type: Transaction Processing – Database name: GGSRCLAB – Choose Always Free if available (optional)
Create Target ADW (or second ATP): – Workload type: Data Warehouse (or Transaction Processing) – Database name: GGTGTLAB

Wait until both show Available.

Expected outcome: Two Autonomous Databases are running.

Step 4: Create GoldenGate database users and required privileges

GoldenGate needs database users with privileges to capture (source) and apply (target). For Autonomous Database, Oracle provides supported privilege-granting procedures. Exact privilege scripts can vary by database version—verify with the OCI GoldenGate + Autonomous Database documentation.

4.1 Connect to source ATP and create a capture user

Using Database Actions → SQL (recommended for beginners), run:

-- On SOURCE (ATP)
CREATE USER ggadmin IDENTIFIED BY "Use-A-Strong-Password-Here";

-- Basic connectivity
GRANT CREATE SESSION TO ggadmin;

-- GoldenGate capture privileges (recommended approach uses DBMS_GOLDENGATE_AUTH)
BEGIN
  DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE(
    grantee                 => 'GGADMIN',
    privilege_type          => 'CAPTURE',
    grant_select_privileges => TRUE,
    do_grants               => TRUE
  );
END;
/

Create a demo schema/table (you can use ggadmin or a separate schema):

-- Create demo objects (on SOURCE)
CREATE TABLE ggadmin.customer_demo (
  customer_id NUMBER PRIMARY KEY,
  full_name   VARCHAR2(200),
  updated_at  TIMESTAMP DEFAULT SYSTIMESTAMP
);

-- Insert a seed row
INSERT INTO ggadmin.customer_demo (customer_id, full_name) VALUES (1, 'Ada Lovelace');
COMMIT;

Enable supplemental logging as required for CDC. The exact commands depend on your environment. A commonly used table-level approach is:

-- Supplemental logging (verify exact requirements for your DB/version)
ALTER TABLE ggadmin.customer_demo ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

4.2 Connect to target ADW and create an apply user

-- On TARGET (ADW or ATP)
CREATE USER ggadmin IDENTIFIED BY "Use-A-Strong-Password-Here";
GRANT CREATE SESSION TO ggadmin;

BEGIN
  DBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE(
    grantee                 => 'GGADMIN',
    privilege_type          => 'APPLY',
    grant_select_privileges => TRUE,
    do_grants               => TRUE
  );
END;
/

Create the target table (for a simple mapping-first lab, match schema/table name):

-- On TARGET
CREATE TABLE ggadmin.customer_demo (
  customer_id NUMBER PRIMARY KEY,
  full_name   VARCHAR2(200),
  updated_at  TIMESTAMP
);

Expected outcome: ggadmin exists on both DBs, with capture privileges on source and apply privileges on target. Tables exist on both sides.

If DBMS_GOLDENGATE_AUTH is not accessible or behaves differently in your Autonomous Database, do not “hack around” with random grants. Stop and follow the official Autonomous Database + GoldenGate privilege setup guide.

Step 5: Create an OCI GoldenGate Deployment

Go to GoldenGate in OCI Console (service location may vary by console layout; you can also search “GoldenGate”).
Click Create deployment
Choose: – Compartment: gg-lab – Name: gg-deployment-lab – VCN + Subnet: select the subnet you created – NSG: attach the NSG you created – Access type: choose private if you have Bastion/VPN, otherwise public for lab and restrict to your IP
Choose a deployment sizing/shape appropriate for a small lab (exact names vary). Keep it minimal.
Create and wait until status is Active.

Expected outcome: A GoldenGate deployment is provisioned and reachable (admin console URL available in deployment details).

Step 6: Create OCI GoldenGate Connections for source and target

OCI GoldenGate typically uses Connections as first-class resources.

In the GoldenGate service page, go to Connections → Create connection
Create Source connection: – Type: Oracle Autonomous Database (or Oracle Database) – Database OCID: select GGSRCLAB – Username: ggadmin – Password: the password you set – Wallet/cert handling: follow console prompts (Autonomous DB usually requires a wallet or service-managed connectivity; follow official steps)
Create Target connection similarly for GGTGTLAB.

Expected outcome: Two connections show as Active/Valid (or at least created successfully).

Common pitfall: network access. If your deployment is in a private subnet and your Autonomous DB is public-only, you may need NAT for outbound access and correct allowlists. If your Autonomous DB uses private endpoints, place the deployment in the same VCN or connected network.

Step 7: Open the GoldenGate Deployment Console (Microservices UI)

From the deployment details, click Launch console (wording may differ).
Sign in using the deployment’s configured admin credentials.

Expected outcome: You can see the GoldenGate microservices landing page and navigation for Administration/Configuration.

Step 8: Configure credentials/aliases inside GoldenGate (if required)

Many GoldenGate configurations use a credential store with aliases instead of embedding passwords in parameter files.

In the GoldenGate console: 1. Go to Configuration / Credentials (menu names vary) 2. Create credential aliases like: – SRC_GGADMIN – TGT_GGADMIN 3. Associate each with the correct username/password and (if required) domain.

Expected outcome: Credentials exist and can be referenced by Extract/Replicat.

Step 9: Create Extract (capture) for the source table

In the GoldenGate Administration UI: 1. Create an Extract 2. Choose capture type appropriate for Oracle DB (often “Integrated Extract” for Oracle; verify recommended mode for Autonomous). 3. Select the source connection you created. 4. Specify table selection: – Schema: GGADMIN – Table: CUSTOMER_DEMO 5. Configure trail: – Local trail name (example): aa

A minimal Extract parameter example (for reference; UI may generate it):

EXTRACT ext_demo
USERIDALIAS SRC_GGADMIN
EXTTRAIL ./dirdat/aa
TABLE GGADMIN.CUSTOMER_DEMO;

Start the Extract.

Expected outcome: Extract status shows Running and begins reading changes.

Step 10: Create Replicat (apply) to the target table

Create a Replicat
Choose apply mode appropriate for Oracle DB (verify best practice for your target).
Select the target connection.
Configure the mapping: – GGADMIN.CUSTOMER_DEMO → GGADMIN.CUSTOMER_DEMO
Choose a trail to read from (the one produced by Extract / distribution path as applicable).

Minimal Replicat parameters (reference):

REPLICAT rep_demo
USERIDALIAS TGT_GGADMIN
MAP GGADMIN.CUSTOMER_DEMO, TARGET GGADMIN.CUSTOMER_DEMO;

Start the Replicat.

Expected outcome: Replicat status shows Running.

Depending on deployment topology, you may need to configure Distribution/Receiver paths between services. OCI GoldenGate can abstract some of this, but not always. Follow the workflow in the docs for “paths” if required by your deployment model.

Step 11: Generate changes on the source and observe replication

On the source database, run:

INSERT INTO ggadmin.customer_demo (customer_id, full_name) VALUES (2, 'Grace Hopper');
UPDATE ggadmin.customer_demo SET full_name = 'Ada Lovelace (updated)', updated_at = SYSTIMESTAMP WHERE customer_id = 1;
DELETE FROM ggadmin.customer_demo WHERE customer_id = 2;
COMMIT;

On the target database, query:

SELECT customer_id, full_name, updated_at
FROM ggadmin.customer_demo
ORDER BY customer_id;

Expected outcome: The target reflects the insert/update/delete operations after a short delay. Only row customer_id=1 remains with the updated name.

Validation

Use multiple validation methods:

Data validation – Compare counts and sample rows on source and target.
Process health – Extract and Replicat show Running.
Lag monitoring – Check “lag” indicators in the GoldenGate UI (if available).
Error logs – Confirm no repeated connection or permission errors.

A simple row-count check:

-- Run on both source and target
SELECT COUNT(*) FROM ggadmin.customer_demo;

Expected outcome: Counts match (for this lab, should be 1).

Troubleshooting

Common issues and fixes:

Cannot connect to database – Check subnet routing (internet/NAT/DRG) and NSG rules. – Confirm Autonomous DB network access mode (public vs private endpoint). – Confirm wallet/cert requirements are satisfied (Autonomous often requires wallet-based connectivity).
Extract abends due to missing privileges – Re-check DBMS_GOLDENGATE_AUTH grants on the source. – Ensure supplemental logging is configured as required.
Replicat failing with “table not found” – Ensure target table exists with correct schema name and case. – Check mapping rules.
Replication lag grows – Deployment sizing too small – Network latency – Target apply constraints/locks – Index/constraint overhead on target
No changes appear – Ensure you committed transactions – Ensure Extract is started and capturing the correct table – Ensure Replicat is reading the correct trail/path

When stuck, rely on the official troubleshooting sections in the product docs: https://docs.oracle.com/en/cloud/paas/goldengate-service/

Cleanup

To stop billing and leave no resources behind:

In GoldenGate console: – Stop Replicat – Stop Extract
In OCI Console: – Delete GoldenGate deployment – Delete GoldenGate connections
Delete databases (if created for the lab): – Terminate GGSRCLAB and GGTGTLAB
Delete networking (if dedicated): – NSG – Subnet – VCN
Remove any stored credentials you created.

Expected outcome: All billable resources are deleted, and the compartment is empty.

11. Best Practices

Architecture best practices

Prefer private networking (private endpoints + Bastion/VPN/FastConnect) for production.
Separate environments by compartment: dev, test, prod.
Design for cutover: include validation, fallback, and rollback steps.
Keep CDC pipelines focused: replicate “what you need,” not the entire database by default.

IAM/security best practices

Use least privilege OCI policies for GoldenGate administrators.
Separate roles:
Network admin
GoldenGate operator
DBA/security officer
Use least-privilege database users: separate capture and apply users where appropriate.

Cost best practices

Turn off/delete non-prod deployments when idle.
Right-size based on measured redo volume and throughput testing.
Avoid cross-region replication unless needed.

Performance best practices

Ensure source logging is correctly configured (supplemental logging as required).
Keep target constraints/indexing appropriate; too many indexes can slow apply.
Monitor lag continuously; define thresholds and alarms.

Reliability best practices

Use checkpoints properly (default behavior is usually correct; avoid manual tampering).
Plan maintenance windows for schema changes and deployments.
Document restart procedures and runbooks.

Operations best practices

Centralize logs/metrics where possible.
Create alarms for:
Extract/Replicat stopped
Lag above threshold
Storage/trail saturation (if exposed)
Use consistent naming:
Deployments: gg-<env>-<purpose>
Connections: conn-<env>-<dbrole>-<db>
Extract/Replicat: ext_<schema>_<purpose>, rep_<schema>_<purpose>

Governance/tagging/naming best practices

Tag resources with env, owner, app, costcenter.
Use compartments for strong boundaries and clean cost reporting.
Keep an inventory of pipelines and data flows for compliance.

12. Security Considerations

Identity and access model

OCI IAM controls who can create/manage:
Deployments
Connections
Related networking and database resources
GoldenGate console access must be protected:
Restrict ingress (NSG, allowlisted IPs)
Prefer private access paths

Encryption

Data in transit:
Use TLS where supported/required
Autonomous Database connectivity commonly uses wallets and secure connections
Data at rest:
Managed services and Autonomous Database encrypt at rest by default in OCI (confirm your service’s encryption guarantees in official docs).

Network exposure

Avoid public admin endpoints in production.
If you must use public access:
Restrict by source IP
Use MFA where available
Monitor access logs

Secrets handling

Do not store passwords in scripts or parameter files in plain text.
Use GoldenGate credential store/aliases.
Consider OCI Vault for secret lifecycle and rotation patterns (verify exact integration steps).

Audit/logging

Enable OCI Audit (enabled by default in OCI) and review logs for GoldenGate resource changes.
Ensure operational logs are retained per your compliance needs.

Compliance considerations

Data replication can create regulated-data copies. Plan for:
Data residency requirements (region choice)
Retention policies
Masking/tokenization requirements (GoldenGate is not a full data masking platform; use appropriate tooling)

Common security mistakes

Public admin endpoint open to the internet
Over-privileged database users (DBA-level grants without need)
Replicating sensitive tables to less-secure targets
No alerting on stopped processes or increasing lag

Secure deployment recommendations

Private subnets + Bastion/VPN/FastConnect
Strict NSGs with least-ports/least-sources
Separate capture/apply accounts
Continuous monitoring and incident response runbooks

13. Limitations and Gotchas

These are common issues seen in real deployments. Always confirm current service limits and supported matrices in official OCI GoldenGate docs.

Supported technologies vary: Not every GoldenGate connector/adapter may be available in OCI GoldenGate. Verify supported sources/targets for your region and service version.
Autonomous Database connectivity nuances: Wallet requirements, network access modes (public/private endpoint), and privilege procedures differ from self-managed Oracle DB.
Initial load is separate: CDC keeps changes flowing, but you still need an initial data load strategy (Data Pump, export/import, database copy, or GoldenGate initial load features—verify best practice).
Schema changes require planning: DDL replication support depends on configuration and database types. Plan migrations and DDL handling carefully.
Network is the #1 cause of failures: NSGs, route tables, DNS, and endpoint access are frequent root causes.
Lag isn’t just a GoldenGate problem: Target constraints, slow I/O, database contention, and long transactions can increase lag.
Costs can surprise: Leaving deployments running, using larger shapes than needed, and cross-region replication can raise monthly spend.
Cutover complexity: Application cutover requires coordinating writes, final sync, validation, and rollback options.
Operational ownership: Even as a managed service, your team owns pipeline correctness, data validation, and on-call response.

14. Comparison with Alternatives

GoldenGate is a CDC replication engine. Some alternatives are better for batch ETL, app integration, or managed migrations.

Option	Best For	Strengths	Weaknesses	When to Choose
OCI GoldenGate (GoldenGate)	Real-time CDC replication, migrations, continuous sync	Log-based capture, low latency, mature replication concepts	Cost while running; requires careful network/DB setup; supported tech matrix constraints	When you need reliable CDC and minimal downtime cutover
Oracle Data Guard	Oracle-to-Oracle HA/DR	Strong DR for Oracle DB, simpler for HA	Not a general CDC integration tool; primarily Oracle-to-Oracle	When your goal is DR/HA of an Oracle DB rather than multi-target integration
OCI Database Migration	Guided migrations	Workflow for migrations; can reduce manual steps	Not a general-purpose real-time integration service	When you need a migration project tool more than a CDC platform
OCI Data Integration	Batch ETL/ELT pipelines	Good for scheduled integration and transformations	Not designed for low-latency CDC	When batch is acceptable and transformations are key
Oracle Integration (OIC)	App-to-app integration, APIs, workflows	Connectors, orchestration, business processes	Not for high-volume log-based CDC replication	When integration is process/API driven rather than CDC
AWS DMS	CDC/migration in AWS	Managed migration and CDC	Different ecosystem; feature parity varies	When workloads are primarily on AWS
GCP Datastream	CDC into GCP	Managed CDC service	GCP-specific; connector constraints	When targeting GCP analytics/streaming
Azure Data Factory / Fabric Data Pipelines	ETL/ELT orchestration	Strong pipeline orchestration	CDC capabilities vary; may require extra services	When you need orchestration more than log-based replication
Debezium + Kafka Connect (self-managed)	Open-source CDC pipelines	Flexible, event-streaming-native	You operate everything; operational complexity	When you want OSS stack and can run/operate it reliably
Qlik Replicate / Striim	Commercial CDC platforms	Broad connector ecosystems	Licensing cost; vendor lock-in	When you need connectors not covered by OCI GoldenGate or multi-cloud standardization

15. Real-World Example

Enterprise example: Core banking reporting offload and migration

Problem: A bank runs a mission-critical Oracle OLTP system with heavy reporting demand and a planned migration to a new platform.
Proposed architecture:
OCI GoldenGate captures changes from the OLTP source database
Replicates into an ADW reporting store for dashboards
Maintains synchronization to a new target database during the migration program
Uses private connectivity (FastConnect/VPN + DRG), private endpoints, strict NSGs
Why GoldenGate was chosen:
Log-based capture reduces OLTP overhead
Continuous sync supports both reporting and migration coexistence
Operational restartability and checkpointing reduce risk
Expected outcomes:
Reporting queries move off OLTP
Migration cutover window shrinks significantly
Better operational visibility into replication lag and pipeline health

Startup/small-team example: SaaS operational analytics near real-time

Problem: A startup needs near-real-time analytics from its transactional database into a warehouse for customer-facing dashboards.
Proposed architecture:
Small OCI GoldenGate deployment in a single region
Source ATP → Target ADW replication for key tables only
Basic monitoring/alarms on lag
Strong cost controls (stop non-prod deployments; minimal sizing)
Why GoldenGate was chosen:
Faster than building custom CDC tooling
Lower risk than polling-based approaches
Works well with Oracle database services already in use
Expected outcomes:
Near-real-time dashboards
Reduced engineering time on data plumbing
Clear operational model (lag thresholds, restart runbooks)

16. FAQ

Is GoldenGate the same as OCI GoldenGate?
GoldenGate is the product family. OCI GoldenGate is the managed Oracle Cloud service that runs GoldenGate for you. Always follow OCI GoldenGate documentation for cloud steps.
Is OCI GoldenGate “ETL”?
It’s primarily CDC replication, not a full ETL platform. You can do limited mapping/filtering, but heavy transformations typically belong in ETL/ELT tools.
Do I need an initial load?
Yes. CDC captures changes from a point in time; you still need a strategy to load existing data before or alongside CDC.
Can GoldenGate replicate DDL (schema changes)?
Sometimes, depending on configuration and platforms. DDL replication is a common source of surprises—verify and test.
Does GoldenGate support non-Oracle databases?
GoldenGate as a product can support heterogeneous endpoints, but OCI GoldenGate supported technologies may vary. Verify the supported matrix in official docs.
How do I secure the GoldenGate admin console?
Prefer private endpoints, restrict ingress via NSGs, and use controlled admin access paths (Bastion/VPN). Avoid open internet exposure.
What are the typical ports I must allow?
At minimum, HTTPS (443) for admin access (if used), and database listener ports between deployment and databases. Exact ports depend on your database services and configuration.
How do I measure replication lag?
Use the GoldenGate UI metrics (lag, checkpoint position) and—where available—OCI Monitoring metrics. Set alarms on thresholds meaningful to your RPO/RTO.
Is GoldenGate a replacement for backups?
No. Replication is not backup. Keep standard backup and recovery strategies.
Can I replicate across regions?
Architecturally yes, but it adds latency, complexity, and cost (inter-region transfer). Prefer same-region unless business requires otherwise.
What causes replication to fall behind most often?
Network issues, insufficient sizing, target database contention, long-running transactions, and misconfigured logging/privileges.
How do I reduce cost quickly?
Stop/delete non-prod deployments, right-size, and limit replicated objects to what’s necessary.
Can I use GoldenGate for active-active multi-master?
GoldenGate can support bidirectional patterns, but conflict handling and design are complex. Treat it as an advanced architecture requiring careful testing.
Does OCI GoldenGate manage patches automatically?
OCI manages parts of the service, but patching responsibilities and windows depend on the service model. Verify in the official service documentation.
What’s the difference between GoldenGate and Data Guard?
Data Guard is primarily Oracle-to-Oracle HA/DR. GoldenGate is CDC replication for integration, migration, and multi-target sync patterns.

17. Top Online Resources to Learn GoldenGate

Resource Type	Name	Why It Is Useful
Official documentation	OCI GoldenGate Documentation	Primary, up-to-date configuration guidance for OCI GoldenGate. https://docs.oracle.com/en/cloud/paas/goldengate-service/
Official product page	Oracle GoldenGate (product family)	Good overview of capabilities and platform scope. https://www.oracle.com/database/technologies/goldengate/
Official pricing	Oracle Cloud Price List	Search “GoldenGate” for current SKUs and regional pricing context. https://www.oracle.com/cloud/price-list/
Pricing calculator	OCI Cost Estimator	Model deployment runtime and related OCI costs. https://www.oracle.com/cloud/costestimator.html
Architecture guidance	Oracle Architecture Center	Reference architectures and best practices (search for GoldenGate/CDC). https://docs.oracle.com/en/solutions/
Tutorials/labs	Oracle Cloud Tutorials	Step-by-step labs; search for GoldenGate. https://docs.oracle.com/en/learn/
Release notes	OCI GoldenGate docs (release notes section)	Track changes, new connectors, and behavioral updates (location varies; use docs navigation). https://docs.oracle.com/en/cloud/paas/goldengate-service/
Community learning	Oracle user communities/forums	Practical troubleshooting patterns; validate against docs. https://forums.oracle.com/
Videos	Oracle YouTube channel	Product walkthroughs and webinars (search “OCI GoldenGate”). https://www.youtube.com/@Oracle

18. Training and Certification Providers

Exactly the following institutes are listed as training providers; verify course outlines and delivery modes on their websites.

DevOpsSchool.com
– Suitable audience: DevOps engineers, cloud engineers, platform teams
– Likely learning focus: Cloud operations, DevOps practices, tooling that can complement data integration operations
– Mode: Check website
– Website: https://www.devopsschool.com/
ScmGalaxy.com
– Suitable audience: Software configuration management learners, DevOps practitioners
– Likely learning focus: SCM, DevOps, delivery practices (may complement GoldenGate operationalization)
– Mode: Check website
– Website: https://www.scmgalaxy.com/
CLoudOpsNow.in
– Suitable audience: Cloud operations engineers, SRE/operations teams
– Likely learning focus: Cloud ops practices, monitoring, reliability, operational playbooks
– Mode: Check website
– Website: https://www.cloudopsnow.in/
SreSchool.com
– Suitable audience: SREs, operations teams, reliability engineers
– Likely learning focus: SRE principles, incident response, monitoring/alerting
– Mode: Check website
– Website: https://www.sreschool.com/
AiOpsSchool.com
– Suitable audience: Operations and platform teams exploring AIOps
– Likely learning focus: AIOps concepts, automation, observability practices
– Mode: Check website
– Website: https://www.aiopsschool.com/

19. Top Trainers

Exactly the following trainer-related sites are listed; verify current offerings directly.

RajeshKumar.xyz
– Likely specialization: DevOps/cloud training and mentoring (verify specifics)
– Suitable audience: Engineers looking for guided coaching
– Website: https://www.rajeshkumar.xyz/
devopstrainer.in
– Likely specialization: DevOps training programs (verify specifics)
– Suitable audience: Beginners to intermediate DevOps practitioners
– Website: https://www.devopstrainer.in/
devopsfreelancer.com
– Likely specialization: DevOps consulting/training marketplace-style offerings (verify specifics)
– Suitable audience: Teams seeking short-term expert help
– Website: https://www.devopsfreelancer.com/
devopssupport.in
– Likely specialization: DevOps support and guidance (verify specifics)
– Suitable audience: Ops teams needing practical support coverage
– Website: https://www.devopssupport.in/

20. Top Consulting Companies

Exactly the following consulting companies are listed; descriptions are general and should be validated via their websites and proposals.

cotocus.com
– Likely service area: Cloud/DevOps consulting and engineering services (verify exact offerings)
– Where they may help: Architecture, implementation support, operationalization
– Consulting use case examples:
- Designing secure VCN connectivity for OCI GoldenGate
- Building deployment automation and runbooks
- Operational monitoring and alerting setup
- Website: https://cotocus.com/
DevOpsSchool.com
– Likely service area: DevOps/cloud consulting and training services
– Where they may help: Enablement, platform practices, delivery pipelines that support data platforms
– Consulting use case examples:
- Cloud governance and tagging strategy for GoldenGate environments
- SRE-style monitoring and incident response for replication pipelines
- Cost optimization reviews for always-on deployments
- Website: https://www.devopsschool.com/
DEVOPSCONSULTING.IN
– Likely service area: DevOps and cloud consulting (verify exact offerings)
– Where they may help: Implementation services, operations support, best practices adoption
– Consulting use case examples:
- Secure admin access patterns (Bastion/VPN) for GoldenGate console
- Infrastructure-as-code for networking and environments
- Production readiness reviews (IAM, NSGs, monitoring)
- Website: https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before GoldenGate

Oracle Cloud basics: compartments, IAM policies, VCN/subnets/NSGs
Database fundamentals: transactions, redo/transaction logs, constraints, indexing
Oracle Database basics: schemas, users/roles, SQL, connectivity
Observability fundamentals: metrics, logs, alerting, incident response

What to learn after GoldenGate

Advanced replication design: initial load strategies, DDL handling, conflict detection (for bidirectional)
Network architecture: DRG, FastConnect, private endpoints
Data platform patterns: warehouse/lakehouse design, data governance, lineage
Automation: OCI CLI, Terraform, CI/CD for infrastructure and configuration

Job roles that use it

Cloud Solution Architect (data platform focus)
Data Engineer (CDC pipelines)
DBA / Database Engineer (migration and replication)
SRE / Operations Engineer (data platform reliability)
Integration Engineer (data movement patterns)

Certification path (if available)

Oracle certification availability changes over time. Start with: – Oracle Cloud Infrastructure foundations and architect tracks (verify current names) – Oracle database administration tracks Then specialize via: – OCI GoldenGate workshops and official labs
Always verify current certification offerings on Oracle University: https://education.oracle.com/

Project ideas for practice

Build a repeatable “migration factory” template: VCN + GoldenGate + source/target DB + validation scripts
Implement replication monitoring: alarms on lag and process down, with runbooks
Schema evolution drill: add a column and validate downstream impacts
Cost-control automation: scheduled stop/start for non-prod deployments
Cross-VCN replication with private networking (DRG + routing + NSGs)

22. Glossary

CDC (Change Data Capture): Capturing row-level changes (insert/update/delete) from a source system and delivering them elsewhere.
Extract: GoldenGate capture process that reads changes (often from transaction logs).
Replicat: GoldenGate apply process that writes changes to the target.
Trail file: GoldenGate’s staged change log format used between components.
Checkpoint: Stored position markers that allow processes to resume safely after interruptions.
Lag: Delay between source commit time and target apply time (or between extract position and current time).
VCN (Virtual Cloud Network): OCI’s software-defined network container.
NSG (Network Security Group): OCI virtual firewall rules applied to VNICs/resources.
Compartment: OCI logical container for organizing and isolating resources with IAM policies.
Autonomous Database (ATP/ADW): Managed Oracle databases in OCI optimized for transaction processing (ATP) or analytics (ADW).
Initial load: The first copy of existing data to the target before CDC keeps it current.
DDL: Data Definition Language—schema changes such as CREATE/ALTER/DROP.
Cutover: The moment you switch production traffic from old system to new.

23. Summary

GoldenGate in Oracle Cloud (OCI GoldenGate) is a managed service for real-time CDC replication that helps you integrate and synchronize data across databases with low latency and strong restartability.

It matters when you need minimal-downtime migrations, real-time reporting offload, and continuous data synchronization without building brittle custom pipelines. Architecturally, it fits as an Integration building block focused on data movement, working alongside OCI networking, IAM, and observability services.

Cost is primarily driven by deployment runtime and sizing, plus database and network costs—so right-sizing and shutting down non-prod deployments are essential. Security depends on tight IAM, least-privilege database accounts, and private network access patterns for the admin console and data paths.

Use GoldenGate when CDC is the requirement; choose simpler ETL or app-integration services when real-time log-based replication isn’t needed. Next, deepen your skills by following the official OCI GoldenGate documentation and running Oracle’s labs: https://docs.oracle.com/en/cloud/paas/goldengate-service/

rajeshkumar

Category