Active-active is a data ownership problem
Oracle GoldenGate can move committed changes in both directions, but bidirectional transport alone does not create a safe active-active database. The difficult problem is deciding what should happen when two sites legitimately change the same logical data before either change reaches the other site. Network latency, replication outages, long transactions, and application retries all enlarge that conflict window. If the design has no explicit ownership or resolution model, it may remain operational while silently discarding a valid business change. That is more dangerous than an abended Replicat because the platform appears healthy while the databases diverge semantically.
The safest design minimizes overlapping write authority. Assigning customers, tenants, accounts, or geographical regions to a home site makes most transactions conflict-free while retaining local write availability. Ownership must be enforced by the application or database rather than documented as an operational convention. A service at site B should reject or route a write for an entity owned by site A, and the ownership record itself requires a controlled transfer protocol. Global active-active writes should be reserved for tables whose conflict semantics are understood at column and operation level.
Tables should therefore be classified before GoldenGate is configured. Reference data may require single-site administration; append-only events can use globally unique identifiers; inventory often requires reservation or escrow semantics; and account balances may need delta-based processing rather than last-writer-wins. Parent and child rows must follow compatible ownership rules because independently resolving them can produce a structurally valid but impossible business state. GoldenGate resolves database changes, not business invariants spanning several transactions or services.
Keys, loops, and the replication contract
Every replicated table needs an immutable primary key or an explicitly selected, stable key. Sequences configured independently at two sites can generate the same value, so allocate non-overlapping ranges, embed a site identifier, or use a globally unique key strategy. Updating a primary key is especially hazardous because it is represented logically as changing row identity and interacts with delete tracking. Foreign keys, unique constraints, triggers, virtual columns, and supplemental logging must be consistent across sites. Integrated Replicat computes transaction dependencies using target constraints, so missing or different constraints can also change apply concurrency and failure behavior.
Loop prevention is equally fundamental. A transaction applied at site B must not be captured there and returned to site A as a new local transaction. For Oracle-to-Oracle replication, use the supported integrated capture and apply mechanisms that preserve origin information, and verify exclusions using actual round-trip tests. Do not treat a parameter file review as proof: insert a trace row at each site, allow both paths to drain, and confirm that each logical operation is applied once. A loop can produce duplicate operations, repeated conflict resolution, trail growth, and a feedback storm that overwhelms both databases.
The replication contract should also define DDL behavior. Uncoordinated DDL can invalidate mappings or make an older trail record impossible to apply after a column change. Deploy compatible additive changes to every site first, validate capture and apply, migrate applications, and remove obsolete structures only after all trails have passed the transition point. Automatic DDL replication does not eliminate the need for release ordering, particularly when applications at different sites run different versions during a rolling deployment.
Choosing conflict semantics with ACDR
Oracle Automatic Conflict Detection and Resolution, or ACDR, is designed for Oracle GoldenGate active-active configurations. It compares logical change information with the current target row and can resolve conflicts using timestamp, column-group, delta, and delete-aware mechanisms. ACDR requires Extract plus integrated Replicat or parallel Replicat in integrated mode, and it automatically configures required supplemental logging for participating tables. It must be enabled in the correct pluggable database and configured consistently at every writable replica. It also cannot be combined on the same table with MAP-level exception mechanisms such as REPERROR or MAPEXCEPTION, which affects established error-handling standards.
The default latest-timestamp approach is appropriate only when overwriting the older version is genuinely correct. It depends on trustworthy clocks and still loses one concurrent intent by design. NTP monitoring, maximum clock-offset alerting, and controlled behavior during time-service failures are therefore correctness controls rather than infrastructure housekeeping. Column groups reduce unnecessary conflicts when independent business domains update different columns in the same row. For example, compensation attributes can be separated from reporting-line attributes so that concurrent changes do not overwrite each other.
BEGIN
DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR(
SCHEMA_NAME => 'HR',
TABLE_NAME => 'EMPLOYEES');
DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR_COLUMN_GROUP(
SCHEMA_NAME => 'HR',
TABLE_NAME => 'EMPLOYEES',
COLUMN_LIST => 'SALARY, COMMISSION_PCT',
COLUMN_GROUP_NAME => 'COMPENSATION_CG');
END;
/Delta resolution is useful when the replicated operation represents an increment or decrement rather than an absolute replacement. If two sites independently add quantities, applying both deltas may preserve the intended total. It is not automatically safe for bounded inventory, credit limits, or balances that must never cross a threshold, because each site can approve a transaction using stale global state. Those workloads need reservations, site-specific allocations, or synchronous coordination at the business layer. A mathematically convergent result is not necessarily a legally or operationally valid result.
BEGIN
DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR(
SCHEMA_NAME => 'OE',
TABLE_NAME => 'ORDERS');
DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR_DELTA_RES(
SCHEMA_NAME => 'OE',
TABLE_NAME => 'ORDERS',
COLUMN_NAME => 'ORDER_TOTAL');
END;
/Deletes require special attention because a missing target row contains no timestamp with which to compare a delayed update or insert. ACDR can maintain tombstone information so that delete-versus-update conflicts remain detectable after the base row disappears. Tombstones consume space and must remain longer than the maximum interval in which an old change could return, including network isolation, retained trails, recovery from backup, and Extract restart positions. Purging them merely by age can resurrect deleted data after a prolonged outage. Purge policy should therefore be derived from measured replication watermarks and the supported recovery window.
Apply performance must preserve correctness
Integrated Replicat and parallel integrated Replicat can apply independent transactions concurrently while respecting dependencies discovered from target constraints. Increasing parallelism helps only when the workload contains independent transactions and the target has sufficient CPU, memory, redo capacity, and storage latency headroom. A hot account, tenant, or index leaf remains serialized regardless of configured apply servers. Excessive parallelism can increase contention, log file sync pressure, and recovery work while providing little additional throughput.
Monitor more than the process state and headline lag value. Extract lag identifies capture delay, Distribution Path lag exposes transport pressure, and Replicat lag indicates trail consumption delay, while heartbeat data provides end-to-end evidence that new changes continue to traverse the entire path. A low process lag with an old heartbeat can mean the process is idle because no new records are arriving. Oracle exposes current and historical path information through the GoldenGate heartbeat tables and the GG_LAG view.
SELECT local_database,
remote_database,
incoming_lag,
incoming_heartbeat_age,
remote_db_oldest_open_txn_age
FROM ggadmin.gg_lag
ORDER BY remote_database;
SELECT table_owner, table_name,
tombstone_table, row_resolution_column
FROM all_gg_auto_cdr_tables
ORDER BY table_owner, table_name;Alerts should cover stopped or abended processes, heartbeat age, lag acceleration, trail filesystem consumption, checkpoint stagnation, discard files, apply errors, database inbound-server health, and the oldest open source transaction. Long-running transactions can hold Extract behind even when redo generation is normal. Also monitor conflict counts by table and resolution type. A sudden increase often identifies an ownership-routing defect, a retry storm, clock instability, or an application release that changed update behavior.
Failure testing is the acceptance criterion
A valid test must create the failure conditions that the architecture claims to survive. Isolate the replication network while leaving both databases writable, perform concurrent update-update, insert-insert, update-delete, and parent-child transactions, then restore transport in both directions. Repeat with a Replicat outage, exhausted trail filesystem, clock skew, long uncommitted transaction, process restart, and application timeout followed by retry. Validate final business values, row counts, keys, conflict records, tombstones, and application responses rather than accepting a zero-lag dashboard as evidence of convergence.
Reconciliation must be continuous and independent of GoldenGate. Compare keyed row hashes or trusted aggregates in bounded partitions, but avoid unordered aggregate checksums that can conceal compensating differences. For critical domains, reconcile business invariants such as order totals against order lines and reservations against inventory allocations. The operational runbook must state when to stop writes, which site has authority, how to preserve trails, how conflicts are reviewed, and how service routing changes during isolation. Active-active succeeds when ambiguous ownership is prevented, unavoidable conflicts are deterministic and observable, and engineers can prove convergence after hostile failure sequences—not simply when both Replicats report RUNNING.
Current behavior and prerequisites should be checked against Oracle’s Automatic Conflict Detection and Resolution documentation and GoldenGate lag-monitoring documentation for the deployed database and GoldenGate release.
