What you will learn
This lab assumes DDL replication is not enabled. A new column must be represented on both sides; supplemental logging is a separate concern from executing the DDL.
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. Use a small APP.EVENTS table with a stable primary key. Record the current mapping and whether filters, transformations, or conflict rules require before-images of the added column.
1. Inspect logging and mappings
DBLOGIN USERIDALIAS source_gg
INFO TRANDATA APP.EVENTS
Check table keys, target definition, and any explicit column lists. A mapping that enumerates columns will not automatically include a new field just because the database DDL succeeded.
2. Coordinate compatible DDL
ALTER TABLE APP.EVENTS ADD (event_status VARCHAR2(20));
For this nullable additive example, prepare the corresponding target column before allowing source writes to populate it. Use the actual mapped target schema. Quiesce affected writes/apply and follow the supported metadata-refresh procedure where required by the capture/apply mode.
3. Add required supplemental logging
ADD TRANDATA APP.EVENTS, COLS (event_status)
INFO TRANDATA APP.EVENTS
This illustrates explicit extra-column logging when the design needs it. Preserve key logging; do not remove existing logging as an intermediate shortcut. Verify the exact syntax and PDB qualification for your release.
4. Test both new and existing rows
Insert a row with event_status, update that field on an existing row, set it to NULL, and delete a test row. Inspect target values and process reports after each action. Include filters or transformations that refer to the new column.
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
Source and target definitions agree, logging inspection shows the intended columns, and all four DML cases apply without conversion, missing-key, or metadata errors.
Troubleshooting
An invalid-column error can come from an explicit MAP/COLMAP or stale metadata. Missing before-images can indicate logging was enabled too late for already captured transactions. Restarting apply cannot reconstruct information absent from the trail.
Recovery and next steps
For a failed additive change, stop use of the new field and preserve the compatible nullable column while correcting mapping/logging. Dropping a populated column to roll back can lose data and requires a separate reviewed migration.