OCI GoldenGate, in depth: deployments, connections, the Extract to Replicat pipeline, an SCN-consistent initial load, sizing and the failures that stop replication

What the service actually gives you

The unit you create is a deployment: a managed GoldenGate installation with its own console, admin REST API and storage. A deployment has a type. Data replication is the classic CDC use; data transforms and stream analytics are separate types for ELT and event processing. A data replication deployment also has a technology, the family of databases its processes speak: Oracle, SQL Server, MySQL, PostgreSQL, Db2 for z/OS, Db2 for i, or Big Data for targets such as Kafka and object storage.

Databases are described by connections, separate OCI resources that hold the endpoint, the user and the network route. A connection does nothing until it is assigned to a deployment, and a process in that deployment can only reach databases whose connections are assigned to it. This indirection is useful: the same connection can be reused across deployments, credentials are rotated in one place, and an audit of which deployment can reach which database is a list of assignments rather than a search through parameter files.

Inside a deployment are the GoldenGate microservices. The Administration Service runs Extract and Replicat processes. The Distribution Service sends trail data to other deployments over paths. The Receiver Service accepts incoming trails. A metrics service exposes process statistics that OCI Monitoring scrapes.

The pipeline: Extract, trail, path, Replicat

Every GoldenGate flow has the same shape. Extract reads the source's transaction log and writes committed changes, in commit order, to a trail: a sequence of files of change records in GoldenGate's own format. A distribution path reads the trail and streams it to another deployment, where the Receiver Service writes a copy. Replicat reads that trail and applies the changes to the target as SQL. When source and target are both reachable from one deployment you can skip the path and let Replicat read the local trail directly; two deployments are worth the cost when the source and target live in different regions or networks, or when each team should own its half.

The trail is the important idea. It decouples reading from applying, so a slow or stopped target does not stall capture, and it persists changes so that a restart resumes from a checkpoint instead of starting over. Each stage records its own position: Extract stores where it is in the redo stream and which transactions are open, the path stores how far it has read, and Replicat stores the last applied trail position in a checkpoint table in the target database, inside the same transaction as the changes it applies. That last detail is why Replicat does not double-apply after a crash: either both the change and the checkpoint committed or neither did.

How capture works on Oracle

Integrated Extract does not parse redo files itself. It registers with the source database, which starts a logmining server that reads redo, assembles row changes into transactions and hands committed transactions to Extract. This means Extract understands every datatype and storage feature the database does, and it means capture depends on the database keeping redo available: if Extract is stopped longer than archived logs are retained, it cannot resume and the target must be reloaded.

Redo normally records only the columns an update changed plus a row address that means nothing on another database. Supplemental logging fixes that by adding key columns, or all columns, to each change record, so Replicat can find the row on the target. ADD SCHEMATRANDATA enables it for every table in a schema, including tables created later. Forgetting it is the most common reason a new table replicates inserts but fails on its first update.

Each table needs a usable key. GoldenGate uses the primary key, then a unique key, then, failing both, all columns, which turns every update into a full-row comparison on the target. Declare KEYCOLS explicitly for keyless tables, or add a key.

Worked example: on-premises Oracle to Autonomous Database

The goal is to migrate a 2 TB SALES schema from an on-premises Oracle database to Autonomous Database in OCI with minutes of downtime instead of a weekend. The plan: start capturing changes, load a consistent snapshot, apply everything that happened after the snapshot, let the target catch up, then switch applications over. The on-premises database connects through FastConnect or VPN into a private subnet; network design is covered in OCI networking.

Step one is on the source deployment. Create connections for both databases, assign them, add a credential alias, and run the admin client commands below. The order matters: Extract must be running before you take the snapshot, so no change can fall between the snapshot and the first captured change.

-- Admin client, connected to the SOURCE deployment
DBLOGIN USERIDALIAS src_db DOMAIN OracleGoldenGate

-- 1. Log enough column data for every row change in the schema
ADD SCHEMATRANDATA sales ALLCOLS

-- 2. Heartbeat table so lag is measured end to end, not guessed
ADD HEARTBEATTABLE

-- 3. Create the capture and its local trail, starting from now
-- multitenant source: REGISTER EXTRACT exsales DATABASE CONTAINER (pdb_name)
REGISTER EXTRACT exsales DATABASE
ADD EXTRACT exsales, INTEGRATED TRANLOG, BEGIN NOW
ADD EXTTRAIL ea, EXTRACT exsales
START EXTRACT exsales

The Extract parameter file names the trail and the tables. Including DDL for mapped objects means a column added during the migration window reaches the target instead of breaking Replicat.

EXTRACT exsales
USERIDALIAS src_db DOMAIN OracleGoldenGate
EXTTRAIL ea
-- capture DDL for mapped objects so column adds flow to the target
DDL INCLUDE MAPPED
TABLE sales.*;

Step two is the instantiation. Read the current SCN, the database's logical clock, and export the schema as of exactly that SCN with Data Pump. Every transaction committed at or before that SCN is in the dump; everything after it is in the trail. Then create the path to the target deployment, import the dump, and start Replicat with AFTERCSN so it skips trail records the dump already contains.

-- After Extract is running, take the instantiation SCN on the source
SELECT current_scn FROM v$database;          -- say 48211907

-- Export a consistent image as of exactly that SCN, import it into the target
expdp ggadmin schemas=SALES flashback_scn=48211907 directory=DP_DIR dumpfile=sales.dmp
impdp admin@adb_high schemas=SALES directory=DATA_PUMP_DIR dumpfile=sales.dmp

-- Admin client, connected to the TARGET deployment
DBLOGIN USERIDALIAS tgt_db DOMAIN OracleGoldenGate
ADD HEARTBEATTABLE                            -- target side records heartbeat arrival
ADD CHECKPOINTTABLE ggadmin.gg_chkpt
-- the distribution path delivers source trail ea as target trail eb
ADD REPLICAT rpsales, PARALLEL, EXTTRAIL eb, CHECKPOINTTABLE ggadmin.gg_chkpt
START REPLICAT rpsales, AFTERCSN 48211907

The Replicat parameter file maps source to target. Parallel Replicat reads the trail once, computes dependencies between transactions from the key values they touch, and applies independent transactions on several apply threads while keeping dependent ones in commit order.

REPLICAT rpsales
USERIDALIAS tgt_db DOMAIN OracleGoldenGate
MAP sales.*, TARGET sales.*;
-- a table without a primary key needs an explicit key, or every update scans
MAP sales.audit_log, TARGET sales.audit_log, KEYCOLS (log_id);

Step three is catch-up and cut-over. The import may take hours, so Replicat starts with a backlog; watch lag fall to seconds. Then validate row counts and checksums on key tables, stop application writes on the source, wait for lag to read zero against the heartbeat, start applications against Autonomous Database, and keep a reverse flow from the new target back to the old source ready if you need a rollback path. The cloud migration patterns page covers how this fits a broader migration plan.

Sizing and what you pay for

A deployment is sized in OCPUs. You pick a base between 1 and 24 when you create it. Each OCPU brings 16 GB of memory and 1 Gbps of network bandwidth. With auto scaling on, the service can grow to three times the base, never beyond 24, and usage is metered per minute with each hour billed at the highest OCPU count used in it. Oracle's guidance is 1 OCPU for development and test and 4 for production data replication, with auto scaling enabled in both; an Oracle blog suggests budgeting about one OCPU per Extract, Replicat and path plus one for the console. Treat that as a starting point, not a rule.

Memory is the hidden constraint. Extract keeps open transactions in memory until they commit, and a single batch job updating fifty million rows in one transaction can push a small deployment into swapping to disk or stalling. Size for your largest transaction, not your average change rate. Storage grows with trail retention: if Replicat is down for a day, the trail must hold a day of changes.

Monitoring and operations

Lag is the number that matters, and it must be measured, not inferred. The heartbeat table added on the source gets a row updated on a timer; that row travels through Extract, trail, path and Replicat like any other change, and the target records when it arrived. The difference is true end-to-end lag, broken down by stage. Publish deployment metrics to OCI Monitoring and alarm on lag for each process, on process status, and on OCPU and storage use.

• Alarm when any process leaves the running state. An abended Replicat with a healthy Extract looks fine for hours while the trail quietly fills.
• Keep archived redo on the source for longer than your worst-case outage plus the time to notice it. Missing logs force a full reload.
• Review the report files after every abend. The error, the trail position and the failing statement are all there.
• Keep credentials in aliases and connections, never in parameter files, and use OCI Vault for secrets your runbooks need.

Failure modes you will meet

Most outages come from a short list. A row update arrives for a row the target does not have, or an insert collides with one that already exists. Replicat abends on the error; the cause is almost always that someone wrote to the target directly, or the initial load and the start position did not line up. Fix the data, not the error handling: blanket error suppression hides divergence until a reconciliation finds it months later.

DDL drift is next. A column added on the source without DDL replication, or a target table altered by hand, breaks apply. Capture DDL for mapped objects, and keep target schema changes inside the replicated flow. Large objects and unusual datatypes can slow capture or need specific settings, so test your real schema, not a toy.

Finally, two-way replication creates loops and conflicts. If both sides accept writes, a change must not bounce back, and two updates to the same row on different sides need a resolution rule. Avoid active-active unless you have designed for conflicts per table; one writer plus a standby reverse flow covers most needs.

When to use it, and when not

If the target is another Oracle database and you need the whole thing, look at OCI Base Database with Data Guard first. Choose GoldenGate when you need a subset of tables, a different target technology, near-zero downtime across versions or platforms, or a continuous feed into analytics.

What to do next

1. Confirm your source and target versions against the service's current support matrix.
2. Create a dev deployment with 1 OCPU and auto scaling, and replicate one schema end to end.
3. Enable supplemental logging, add the heartbeat table, and list keyless tables before writing any parameter file.
4. Rehearse the SCN-consistent initial load and verify row counts and checksums on the target.
5. Set alarms on process status, per-stage lag, OCPU and storage, and test one deliberately stopped Replicat.
6. Measure your largest batch transaction and size production OCPUs and archived log retention from it.
7. Write the cut-over and rollback runbook, including the reverse flow, and run it once before the real date.