What you will learn
Use a deliberately small table to learn how an Oracle consistent export boundary relates to GoldenGate apply. Retain the old target copy and prove the replacement before releasing traffic. The worked export uses Oracle Data Pump; the matching instantiation method must fit the actual Replicat mode.
Before you begin
Use an isolated Oracle Database/GoldenGate combination certified for your exact platform and release. The examples use GoldenGate 19c Classic Architecture and GGSCI; Microservices deployments use different administrative workflows. Configure credential-store aliases, required database privileges, keys, supplemental logging, and a verified backup. Example groups are EDEMO (Extract), PDEMO (pump), and RDEMO (Replicat); first confirm the actual names in your lab. Confirm undo can support the export window, redo/trails are retained through the refresh, and source/target DIRECTORY objects and privileges are prepared.
1. Establish the consistency design
INFO ALL
INFO EXTRACT EDEMO, DETAIL
INFO REPLICAT RDEMO, DETAIL
Save process type, trail prefix, sequence/RBA, lag, checkpoint age, and database/service identity. A process can be RUNNING while no useful transaction is reaching the target.Choose a documented per-table instantiation workflow or a dedicated apply group for the affected scope. Record how transactions at/before the snapshot will be excluded and how later transactions will be retained. Do not rely on HANDLECOLLISIONS to conceal an unknown boundary.
2. Choose and record the source boundary
SELECT current_scn FROM v$database;
Record the actual SCN from the intended source/PDB context. The number below is only an illustrative placeholder. Coordinate any write pause and the affected apply state so the export and restart plan agree.
3. Export a consistent table copy
DIRECTORY=DP_DIR
DUMPFILE=events_refresh.dmp
LOGFILE=events_refresh_export.log
TABLES=APP.EVENTS
FLASHBACK_SCN=123456789
expdp export_user@source_service parfile=events_export.par
Replace the SCN and DIRECTORY with the approved values. Authenticate through the normal prompt/wallet. Review the completed export log and retain the archive. A local shell path is not an Oracle DIRECTORY object.
4. Restore without losing the accepted target
Validate the dump in an isolated schema first. Quiesce the affected target workload/apply and restore the intended table through the reviewed import plan, preserving grants, indexes and dependencies. Do not add TABLE_EXISTS_ACTION=REPLACE casually to a shared target.
5. Resume using the matching instantiation boundary
Use the release’s documented per-table instantiation filtering or the deliberately dedicated group’s position. Verify the first applied changes after the snapshot. Never reposition a shared group past transactions belonging to tables that were not refreshed.
Example output
The following is an illustrative, normalized lab result, not output captured from a live customer system. Your versions, addresses, timings, and row counts will differ.
Illustrative INFO ALL snapshot:
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
EXTRACT RUNNING EDEMO 00:00:00 00:00:02
EXTRACT RUNNING PDEMO 00:00:00 00:00:01
REPLICAT RUNNING RDEMO 00:00:00 00:00:01
This normalized snapshot shows the example groups only; real group placement differs by host. A pump is reported as EXTRACT. RUNNING and zero checkpoint lag are not proof of data correctness—commit a synthetic transaction and verify its target result as described above.
Verify the result
Compare keys and representative values at a quiet boundary, then commit a new source transaction and confirm its target result. Verify insert/update/delete behavior, lag, constraints, indexes, and the absence of unexplained discarded rows.
Troubleshooting
Duplicate-key errors can mean snapshot rows are being replayed twice. Missing-row errors can mean a gap, incomplete copy, or unsuitable keys. ORA-01555 during export requires reviewing undo and the snapshot window, not inventing a new SCN after the fact.
Recovery and next steps
Keep the old target copy, export, SCN, parameter backup, and trail positions. If validation fails, stop affected apply and investigate the boundary before retrying. Do not purge retained trails until the resynchronized table has caught up and been accepted.