What you will learn
Understand the software home, database credential alias, Manager, parameter files, and trail storage before creating a replication path. Use certified 19c media for a historical lab, not an assumed current default.
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 supported database/client libraries, OS architecture, free space, filesystem ownership, and the exact patch readme. Use dedicated software and trail directories with a recorded backup.
1. Inventory the existing boundary
Record the intended source/target database services, architecture, software version, capture/apply types, and ownership of the software and trail directories. Verify supplemental logging and required database permissions before creating groups.
2. Prepare the destination software
Install verified media into a separate home using the vendor-supported installer. Apply only the matching patch procedure and retain installer/patch logs. Check the executable version and library resolution before starting a process. For RAC, validate the intended database service through a client connection and confirm its failover behavior.
3. Prepare credentials and configuration
CREATE SUBDIRS
INFO ALL
For a new Classic home, CREATE SUBDIRS prepares its working subdirectories. Configure Manager with the approved port policy and credential-store aliases through the documented secure workflow. Transfer credential material only using a supported protected procedure; never place plaintext passwords into copied examples.
4. Preserve a known restart position
For a fresh lab, create capture, pump and apply groups using the exact supported mode, initialize the target consistently, and record the first usable trail/checkpoint. Installation itself does not configure replication.
5. Start in dependency order and prove continuity
Verify the new Manager/transport endpoint, then start the prepared capture/transport/apply path according to the migration plan. Confirm checkpoint progression and inspect reports. Commit a synthetic source transaction and verify its target result before switching ownership of monitoring and scheduled operations.
Understand the capture transport and apply path
In this two-host Classic Architecture lab, host1.sample.com runs EDEMO and PDEMO, while host2.sample.com runs RDEMO. Manager manages processes and transport endpoints; it does not read database redo itself. Extract captures supported committed changes, the local trail buffers them, the pump transports them, and Replicat applies the target mapping. A GoldenGate data pump is an Extract process reading a trail; it is unrelated to the Oracle Data Pump expdp/impdp utilities.
For an already configured capture group writing ./dirdat/lt, the following GGSCI commands add a fresh pump. They are a component example, not a complete capture/initial-load configuration. Confirm no group named PDEMO already exists and that the target Manager and dynamic transport ports are configured on the private lab network.
ADD EXTRACT PDEMO, EXTTRAILSOURCE ./dirdat/lt
ADD RMTTRAIL /u02/ogg/dirdat/rt, EXTRACT PDEMO
EDIT PARAMS PDEMO
Use this pump parameter fragment on host1. The remote trail path belongs to host2; prepare that directory with the correct owner and capacity.
EXTRACT PDEMO
PASSTHRU
RMTHOST host2.sample.com, MGRPORT 7809
RMTTRAIL /u02/ogg/dirdat/rt
TABLE APP.EVENTS;
The target Replicat must read the same remote trail and map APP.EVENTS to the intended target table. PASSTHRU is appropriate only when this pump does not need database lookup or transformation. Configure the supported encryption and transport controls before using sensitive data. Record the initialization boundary before starting apply; do not assume adding a group also loads existing rows.
Oracle pump administration describes the matching group and trail relationship.
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 intended binaries and database services are in use, trail/checkpoint positions progress without a gap, and inserts, updates, and deletes reach the target. For RAC, rehearse a supported service failover and verify capture/apply remain correct after reconnection.
Troubleshooting
A missing-trail error requires identifying the exact requested sequence and whether a valid retained copy exists. Advancing the checkpoint to the newest trail can skip transactions. Library or connection errors require checking Oracle homes, service names, wallet/alias configuration, and certification.
Recovery and next steps
Retain the old software and state until acceptance. If the new path fails before new writes/apply diverge, use the documented restart plan at the saved boundary. After divergence, reconcile state before changing direction. Never start two independent copies of the same apply path against one target.