What you will learn
A TABLE rule controls capture; a MAP rule controls application. Both sides need a compatible definition and a usable row identifier. Mapping a table does not initialize its existing rows.
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.
1. Compare source and target definitions
Use APP.EVENTS on the source and REPORTING.EVENTS on the target. Compare primary keys, column types, character sets, nullability, and any transformation requirements. Avoid a wildcard until the exact requested table set has been reviewed.
2. Verify source logging
DBLOGIN USERIDALIAS source_gg
INFO TRANDATA APP.EVENTS
Enable the release-appropriate supplemental logging if it is missing before relying on captured updates/deletes. Do not assume ordinary redo contains every key or filter column required by the mapping.
3. Review capture and apply parameter fragments
TABLE APP.EVENTS;
MAP APP.EVENTS, TARGET REPORTING.EVENTS;
The TABLE fragment belongs in the relevant capture/pump configuration and MAP in Replicat. They are fragments, not complete parameter files. Preserve existing credential, trail, checkpoint and other table settings. Restart/reload the affected process only through the supported parameter-change workflow.
4. Initialize and test the table
For a new empty test table, establish capture/apply before generating test DML. For an existing populated table, use a consistent initial-load/instantiation procedure before releasing queued changes. Insert, update, and delete one synthetic key and compare each state on the target.
Keep the initial load and change mapping consistent
The same source object must be used by the initial load and ongoing capture. Mixing a products source with a customers target, as an old example did, cannot establish a valid replication baseline. Use APP.EVENTS consistently in the lab and compare primary-key definitions and column types on both sides.
Create this synthetic fixture in the source application schema before taking the agreed consistent initial snapshot. Create the matching target structure through the supported initialization procedure.
CREATE TABLE app.events (event_id NUMBER PRIMARY KEY,message VARCHAR2(100));
INSERT INTO app.events VALUES (1,'ready');
COMMIT;
For a same-structure mapping, the relevant fragments are:
-- Capture selection
TABLE APP.EVENTS;
-- Target Replicat mapping
MAP APP.EVENTS, TARGET APP.EVENTS;
These fragments do not configure supplemental logging, credentials, trail positions, or the snapshot boundary. Follow the existing initialization steps in this lesson and retain changes from before the snapshot until the target catches up. After initial load, update event_id=1 to a new message, commit, and verify the changed value on the target. Then test a second insert and a delete independently.
For the initial fixture the expected query result is event_id 1 with message ready. A target row count of one alone cannot detect a wrongly mapped value. Compare keys and payloads at the same consistency boundary. A one-time initial-load process can legitimately finish in STOPPED state; its report and loaded data distinguish successful completion from a failed continuous process.
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
The selected table changes arrive in the intended schema, unrelated tables remain unaffected, and reports show no unresolved mapping or missing-row errors. Verify key-based updates and deletes, not just inserts.
Troubleshooting
Missing-row errors can indicate a bad initial load or key mismatch. Unexpected tables suggest an overly broad wildcard. Column conversion errors require a reviewed mapping/type fix rather than discarding records.
Recovery and next steps
Keep parameter backups and record trail/checkpoint positions. Revert a mapping before further apply if the destination is wrong, then reconcile any already-applied rows. Do not reset the whole Replicat merely to undo one table rule.