Oracle GoldenGate Real-Time Replication Internals: Extract, Trail Files, and Replicat

A GoldenGate replication feeding a migration cutover suddenly falls 40 minutes behind. Restarting Replicat doesn't help. The root cause, eventually found: a missing index on the target table that Replicat depends on for efficient row lookups during UPDATE and DELETE apply - invisible without understanding Replicat's actual apply mechanism.

Extract reads committed transaction data from the source's online and archived redo logs. Two modes exist: Classic Extract, which mines logs directly, and Integrated Extract, which delegates mining to the database's own logmining server for tighter integration with newer Oracle features.

The practical difference shows up mostly in feature compatibility rather than raw speed. Classic Extract's own log-reading logic was written before certain newer Oracle features existed, so it can lag behind on support for them, while Integrated Extract inherits whatever the database's own logmining server already understands about the current release. Most new GoldenGate deployments on 19c and later default to Integrated Extract for exactly this reason, though Classic Extract remains simpler to reason about for teams who don't need the newer feature coverage.

Figure 1 · Two ways Extract gets its data from the source database

Trail files are compact, platform-independent representations of captured transactions. A GoldenGate Data Pump process (distinct from Oracle's Data Pump migration utility) ships these files across the network to a remote trail directory on or near the target, decoupling capture speed from network speed.

The GoldenGate Data Pump process in the middle of this diagram is easy to confuse with Oracle's own Data Pump migration utility, but they share nothing beyond the name. Its only job is to ship trail files from the local trail near Extract to a remote trail directory near Replicat, and because that transport is decoupled from both capture and apply, a slow network link delays replication lag without ever blocking Extract from continuing to read the source's redo stream.

Figure 2 · Three components, each independently replaceable, orbiting one replication pipeline

Replicat reads remote trail files and applies each transaction to the target in commit order, using the target's own indexes to locate rows for UPDATE and DELETE operations. Parallel Replicat configurations split apply work across multiple threads, but ordering guarantees within a single transaction must still be preserved.

These four checks, worked through in order, account for the overwhelming majority of Replicat lag incidents in production. Missing supplemental logging prevents Extract from capturing enough information to identify changed rows; missing target indexes force Replicat into slow full-table scans for every UPDATE and DELETE; undersized trail storage throttles throughput during transaction spikes; and any violation of commit ordering during parallel apply risks silent data inconsistency rather than just slowness.

Figure 3 · The four checks that prevent most Replicat lag incidents