GoldenGate vs Data Pump: When to Use Which for Oracle Migration

Every logical migration decision comes down to one question: how much downtime can the business tolerate? Data Pump exports and imports a full logical copy - simple, reliable, but the source is effectively frozen during the transfer. GoldenGate replicates changes continuously, letting the source stay live until the final, near-instant cutover.

Both tools fall under "logical migration" - they move data via SQL-level operations rather than raw block copies - but they sit on opposite sides of the offline/online divide.

The bars are drawn to relative scale on purpose, because the difference is not marginal – it's close to two orders of magnitude. That gap exists because Data Pump's outage window scales with the size of the database being exported, while GoldenGate's outage window scales only with how long it takes to redirect application connections, since replication has already been running in the background the entire time. If your database keeps growing, a Data Pump window keeps growing with it; a GoldenGate cutover generally does not.

Figure 2 · Outage window, drawn to relative scale

• Data Pump (Logical Offline): A point-in-time export followed by import. The source can keep running, but any changes made after the export starts are lost unless a second incremental pass is scripted.
• GoldenGate (Logical Online): An Extract process mines the source redo/transaction logs continuously, and a Replicat process applies changes to the target in near real time, keeping both databases in sync until cutover.

It's worth being precise about what these two tools actually share, because the overlap is easy to overstate. Both operate at the logical, row-and-column level rather than the physical block level, which is why either one can remap schemas, filter objects, and move data between different Oracle versions or even different character sets. Where they diverge completely is time: Data Pump captures a single instant and replays it once, while GoldenGate captures a continuous stream of change and keeps replaying it until you tell it to stop.

Figure 3 · Same migration category, fundamentally different relationship with time

The Extract process reads committed transactions from the source's redo stream and writes them to compact trail files. A Data Pump process (GoldenGate's own, distinct from Oracle Data Pump the migration tool) ships trail files to the target, where Replicat applies them, typically within seconds of the original commit.

The Extract process reads committed transactions from the source's redo stream and writes them to compact trail files. A Data Pump process (GoldenGate's own, distinct from Oracle Data Pump the migration tool) ships trail files to the target, where Replicat applies them, typically within seconds of the original commit. Source and target stay fully decoupled by this transport layer - slow network throughput delays replication lag, but it never blocks Extract from continuing to read the source's redo stream, which is exactly what lets GoldenGate keep the source fully live throughout.

Figure 4 · One redo stream splits into the four stages of the GoldenGate pipeline

1. Match Tool to ToleranceIf the business can accept a maintenance window, Data Pump is simpler and license-free.
2. Size the Trail File StorageGoldenGate trail files need adequate staging disk on both source and target during long-running syncs.
3. Validate Supplemental LoggingGoldenGate Extract requires supplemental logging enabled on key columns before capture starts.
4. Plan the Cutover Checklist SeparatelyEven with GoldenGate, application connection cutover needs its own tested runbook.