Active-Active Oracle GoldenGate Across Regions: Decide Who Owns the Data Before You Resolve Conflict

A hospitality software firm built a two‑region GoldenGate pipeline that lets each site write the same tables and relies on GoldenGate’s conflict detection and resolution (CDR) to reconcile differences. The test harness simulated 40 hotel rooms, 4 booking requests per second per site for 30 seconds, and average replication lag of 57 ms. With “last‑writer‑wins” (LWW) and perfectly synchronized clocks, each run lost about 0.49 updates and oversold roughly 3.8 rooms; adding a 0.5‑second clock skew changed which write survived but not the loss count. Switching to delta resolution eliminated lost updates but still oversold (0.10 rooms per run) because concurrent decrements weren’t coordinated. Only a “single‑owner” design—where each row’s home region processes all writes—produced zero conflicts and zero oversell, at the cost of an extra network hop for half the requests. The experiment shows that GoldenGate’s built‑in CDR cannot enforce business rules such as “do not sell more rooms than exist” without an explicit ownership strategy.

The findings echo long‑standing research on multi‑master replication: as node count and traffic grow, conflict rates explode, and naïve conflict handlers merely mask deeper consistency problems. Systems like Dynamo, Bayou, and CRDT‑based counters push reconciliation into application logic, while Google Spanner’s TrueTime demonstrates that bounded clock uncertainty is essential for correct timestamp ordering. Oracle’s own guidance now advises column‑ or row‑level write segregation, effectively nudging customers toward single‑owner or escrowed models rather than unrestricted active‑active. The hospitality case highlights a broader industry tension between low‑latency local writes and the need for strong invariants in transactional domains such as inventory, finance, or reservations.

Enterprises planning active‑active GoldenGate deployments must first classify tables—single‑owner, escrowed, commutative, last‑value, or disallowed—and enforce that classification through tags, partitioning, and before‑image logging. They also need robust clock‑sync procedures; even sub‑second skew can flip winners and produce silent data loss. Monitoring tools that only compare row hashes (e.g., Veridata) will miss lost updates that converge to the same wrong value, so business‑level reconciliation processes are mandatory. Future releases that expose logical clocks or tighter integration with Oracle’s Time Safe features could mitigate some risks, but the core lesson remains: active‑active is a data‑ownership problem, not a configuration toggle.