What you will learn
Bidirectional transport does not resolve conflicting business writes automatically. This design tutorial focuses on correctness boundaries; capture mode, database version, and conflict policy determine the final parameter set.
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. Prepare two independent databases, A and B, reachable through private routes and certified database services.
1. Define which side owns each write
Start with disjoint key ownership: A writes tenant A and B writes tenant B. Use noncolliding key generation and equivalent constraints. Document what happens if both sides update the same key; “last writer wins” is a business decision, not an automatic guarantee.
2. Validate one direction first
Build A-to-B capture, transport, and apply. Initialize tables at a consistent point, then test insert/update/delete transactions. Inspect lag and errors before adding the reverse path. Repeat the same checks for B-to-A with distinct groups and trails.
3. Prevent applied transactions from looping
For the Oracle 19c lab, explicitly tag applied transactions and exclude that tag from capture on the same database. For example, place the following fragment in each inbound Replicat parameter file:
DBOPTIONS SETTAG 01
In the Extract that captures that database, use:
TRANLOGOPTIONS EXCLUDETAG 01
Reserve the hexadecimal tag for replicated changes; ordinary application sessions must not use it. Apply the pairing at both sites and verify the supported capture/apply combination. Excluding an apply username is not interchangeable across capture modes. Test that a remote transaction is applied once and is not recaptured.
4. Test failure and conflict cases
Write one owned key at A and verify one arrival at B with no recapture loop. Repeat from B. In the lab, test duplicate keys, concurrent updates, network interruption, backlog growth, and recovery. Record whether conflicts are rejected, quarantined, or resolved by the approved rule.
Use noncolliding keys and test both directions
Give host1.sample.com ownership of site_id A and host2.sample.com ownership of site_id B. A composite key (site_id,event_id) allows each side to use its own sequence without colliding. Create the same table on both databases before initialization:
CREATE TABLE app.site_events (
site_id VARCHAR2(1) NOT NULL,
event_id NUMBER NOT NULL,
message VARCHAR2(100),
CONSTRAINT site_events_pk PRIMARY KEY(site_id,event_id)
);
Use matching TABLE and MAP selections for APP.SITE_EVENTS in both paths. Insert (A,1,from host1) only on host1 and (B,1,from host2) only on host2, committing each. Both targets should eventually contain exactly those two rows. Then update each owned row, pause one apply path, and prove correct catch-up after restart.
Loop prevention does not resolve two legitimate application writes to the same row. Document and test conflict behavior separately. Retain trails during the pause and inspect capture statistics for repeated recapture. A successful A-to-B test cannot substitute for testing B-to-A.
Oracle Replicat transaction exclusion documents the tag pairing.
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
A transaction traverses one intended direction without bouncing indefinitely. Both sides retain equivalent accepted data after a pause/resume, and conflicting writes produce the documented outcome with visible diagnostics.
Troubleshooting
Rapid repeated changes can indicate a replication loop. Duplicate-key failures can reflect overlapping key ownership or a bad initial load. Increasing lag after a network interruption requires capacity and retention checks before reconnecting writers indiscriminately.
Recovery and next steps
If correctness is uncertain, stop conflicting application writes and isolate the affected apply path while preserving trails. Reconcile the authoritative values before restarting. Disabling one direction alone does not undo conflicts already committed.