Skip to content
TwinCommitDocs

Migrating from Oracle GoldenGate

You can move a replication flow from Oracle GoldenGate to TwinCommit without changing the source database or interrupting consumers. Translate each flow into a TwinCommit pipeline, run it in parallel against a new target, verify, then cut over.

Concept mapping

Section titled “Concept mapping”
GoldenGate concept TwinCommit equivalent
Extract process The pipeline’s source: block; TwinCommit reads the log itself
Trail files No equivalent needed. Transactions are buffered in memory or spill_dir until applied.
Data pump Not needed. One process reads and applies.
Replicat process The pipeline’s target: block
TABLE / MAP statements in parameter files tables: entries with source, target and exclude_columns
COLSEXCEPT exclude_columns
Checkpoint table state_schema tables on the target
Initial load twincommit snapshot
Lag reporting twincommit_lag_seconds, /status, MCP get_lag

Runbook

Section titled “Runbook”
  1. Inventory. List every MAP statement per flow. Each source/target pair becomes one pipeline file.
  2. Prepare the source. Supplemental logging you already use for GoldenGate is enough. Run twincommit check to confirm.
  3. Create a shadow target. Use a new schema (for example replica_tc) so both tools can run at once.
  4. Snapshot and stream.
    Terminal window
    twincommit ddl -config flow-01.yaml -apply
    twincommit snapshot -config flow-01.yaml
    twincommit run -config flow-01.yaml
  5. Verify. Run twincommit verify during a quiet window, and compare the row counts your consumers rely on.
  6. Cut over. Repoint consumers (views, synonyms or connection strings) at the TwinCommit-managed schema.
  7. Decommission the old flow once you have run in parallel for your agreed confidence period.