Active-active database architectures solve one of the most difficult availability problems in enterprise computing: maintaining two or more databases that are simultaneously available for read and write activity while keeping their data synchronized.
Oracle GoldenGate has supported bidirectional and active-active replication for many years. The fundamental challenge has not changed. Because GoldenGate is an asynchronous logical replication technology, two applications can modify the same logical data at different locations before either change has reached the other database. The resulting collision must either be prevented, detected and resolved, or escalated for human intervention.
Oracle GoldenGate Automatic Conflict Detection and Resolution—commonly referred to as ACDR—provides database-integrated mechanisms for handling many of these situations automatically.
The original Oracle GoldenGate Auto Conflict Detection and Resolution architecture introduced database-maintained timestamp columns, delete tombstones, supplemental logging, delta resolution, and column groups to simplify active-active deployments. Those concepts remain fundamental today. Oracle GoldenGate 26ai extends the operational model around them with modern Microservices Architecture, improved ACDR lifecycle management, enhanced observability, REST-based administration, stronger bidirectional controls, and tighter integration with Oracle AI Database 26ai.
The most important lesson, however, remains unchanged:
Conflict resolution should be the safety net. Good active-active application architecture should prevent as many conflicts as possible before GoldenGate ever needs to resolve them.
GoldenGate supports several replication patterns:
A live-standby architecture is relatively straightforward because only one database normally accepts writes. Replication keeps the secondary database synchronized, but concurrent modification of the same row at both locations is generally avoided.
Active-active is fundamentally different.
Both databases may accept writes:
Application Traffic
/ \
/ \
v v
+---------+ +---------+
| Oracle A| | Oracle B|
| R / W | | R / W |
+----+----+ +----+----+
| |
Extract Extract
| |
+---- OGG ------+
| |
Replicat Replicat
| |
+----+----+ +----+----+
| Oracle A|<--->| Oracle B|
+---------+ +---------+
GoldenGate moves transactions asynchronously between the databases. There is therefore always a finite interval during which each database may contain a slightly different view of the data.
Oracle describes active-active GoldenGate as a bidirectional architecture in which writes may occur against two or more active databases. Because replication is asynchronous, conflict management is required whenever the same data can be changed at multiple sites.
That asynchronous window is the source of the conflict problem.
The best conflict-resolution mechanism is one that rarely has to execute.
Several application and database design techniques substantially reduce the probability of collisions.
Applications can establish logical ownership of data.
Examples include routing writes according to:
A customer located in North America might normally write to Database A while a European customer writes to Database B.
Both systems remain capable of assuming the other's workload during an outage, but routine transaction ownership dramatically reduces simultaneous modification of the same rows.
Duplicate key generation is one of the most avoidable active-active problems.
If Database A and Database B independently generate the same primary key, both transactions may be completely legitimate locally while becoming incompatible when replicated.
For sequence-generated keys, designs can partition the sequence space.
For two databases:
Database A: 1, 3, 5, 7, 9 ...
Database B: 2, 4, 6, 8, 10 ...
For additional sites, an N-way allocation strategy can be used.
Modern applications can alternatively use globally unique identifiers or application-generated keys.
The principle is simple:
A new row created at any active site should receive an identifier that no other active site can independently generate.
Unique constraints beyond the primary key require similar thought. A globally unique primary key does not prevent two users from simultaneously creating the same supposedly unique email address, account number, reservation number, or other business identifier.
Replication latency does more than affect Recovery Point Objective.
It directly affects the size of the conflict window.
If a transaction reaches the second site in milliseconds or seconds, there is relatively little opportunity for another transaction to modify the same row before replication arrives.
If GoldenGate is minutes behind, the probability increases dramatically.
For active-active systems, lag should therefore be treated as a data-consistency risk indicator, not merely an operational performance statistic.
Administrators should monitor at least:
GoldenGate 26ai Microservices Architecture exposes these areas through Administration Service and Performance Metrics Service, as well as REST-based interfaces.
One of the biggest changes since the original GoldenGate active-active material is architectural.
GoldenGate Microservices Architecture was relatively new when the original material was produced. It is now the normal architecture for a new GoldenGate deployment.
In fact, Oracle desupported GoldenGate Classic Architecture beginning in the 23.x generation.
A GoldenGate 26ai deployment contains services such as:
The watchdog and top-level deployment management component.
Manages Extract, Replicat, credentials, parameters, supplemental logging, checkpoint objects, tasks, and process lifecycle.
Moves trail data from source deployments toward destination deployments.
Accepts or retrieves incoming trail files.
Collects operational and performance information across the deployment.
The resulting flow resembles:
Oracle Database A
|
Integrated
Extract
|
Local Trail
|
Distribution
Service
|
HTTPS /
WebSocket
|
Receiver
Service
|
Remote Trail
|
Parallel Replicat
Integrated Mode
|
Oracle Database B
The same architecture operates in the opposite direction for active-active replication.
GoldenGate 26ai also consolidates Microservices monitoring into a common web console rather than requiring administrators to log into the individual services separately.
Another important architectural evolution concerns Replicat.
Traditional Integrated Replicat continues to appear in compatibility requirements for ACDR, but Oracle has deprecated Integrated Replicat as a standalone deployment choice and recommends Parallel Replicat in Integrated mode as the modern alternative.
For a new GoldenGate 26ai Oracle active-active implementation, the logical design is therefore generally:
Integrated Extract
|
Trail
|
Distribution / Receiver
|
Parallel Replicat
Integrated Mode
|
Oracle AI Database
Automatic CDR requires Extract capture and an integrated apply mechanism. Oracle's current documentation explicitly supports Integrated Replicat or Parallel Replicat in Integrated mode and recommends leaving LOGALLSUPCOLS at its default behavior.
Conflict resolution is only part of bidirectional replication.
Another fundamental requirement is preventing this sequence:
Database A
|
| transaction X
v
Database B
|
| Extract captures X again
v
Database A
|
| Extract captures it again
v
Database B
Without loop detection, the same transaction can continuously circulate.
Modern Oracle-to-Oracle GoldenGate accomplishes loop prevention by tagging Replicat-applied transactions.
For example, the Replicat may apply:
DBOPTIONS SETTAG 01
The local Extract then ignores transactions carrying that tag:
TRANLOGOPTIONS EXCLUDETAG 01
Replicat uses tag 00 by default, although deliberate tags can make multi-site architectures easier to understand and troubleshoot.
Oracle specifically recommends EXCLUDETAG as the Oracle bidirectional mechanism.
This is particularly important in GoldenGate 26ai because several older loop-detection parameters associated with earlier architectures have been removed or desupported.
Five broad conflict categories remain useful when designing active-active systems.
| Conflict | Example |
|---|---|
| Insert/Insert | Same logical key created independently at two sites |
| Update/Update | Same row changed differently at two sites |
| Delete/Delete | Same row deleted independently |
| Update/Delete | One site changes a row while another deletes it |
| Column-Level | Different logical portions of the same row are changed |
Not all conflicts should be handled identically.
Consider these examples:
Customer address
Two sites change an address. Latest timestamp might be appropriate.
Inventory
Site A subtracts three items while Site B subtracts two. Choosing one transaction would be wrong; a delta calculation may be required.
Airline seat
Two customers purchase seat 12A. Automatically selecting one transaction may have business consequences requiring additional application processing.
Account status
Headquarters may be authoritative regardless of which transaction happened last. Site-priority resolution may be more appropriate.
Conflict-resolution rules are therefore business rules implemented by replication technology.
Oracle ACDR moves significant conflict-management intelligence into the Oracle Database itself.
ACDR remains specifically an Oracle-to-Oracle capability. GoldenGate provides manual CDR mechanisms for non-Oracle targets and sources.
When ACDR is enabled, Oracle automatically manages much of the metadata needed to determine which change should survive.
Key features include:
This allows conflict management to occur without adding application-visible columns to business tables.
A table can be enabled using DBMS_GOLDENGATE_ADM.
For example:
BEGIN
DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR(
SCHEMA_NAME => 'APP',
TABLE_NAME => 'ORDERS'
);
END;
/
The procedure must be run in the appropriate PDB and should be executed by a properly privileged GoldenGate administrator.
ACDR configuration must exist consistently across the databases participating in replication.
Once enabled, Oracle creates the internal infrastructure necessary for automatic conflict processing.
The most intuitive resolution policy is:
The newest change wins.
ACDR adds an invisible timestamp that represents the modification time of the row.
Assume both databases initially contain:
CUSTOMER_ID = 100
CITY = Atlanta
Timestamp = T0
Database A changes:
CITY = Charlotte
T1
Database B changes:
CITY = Greenville
T2
where:
T2 > T1
When the changes cross, GoldenGate determines that the Database B version is newer.
Eventually both databases converge on:
CITY = Greenville
Timestamp = T2
In current ACDR, latest-timestamp processing handles INSERT, UPDATE, and DELETE conflicts and uses tombstone information where necessary to determine whether a deleted row represents a legitimate later state.
GoldenGate also supports the inverse policy:
The first accepted transaction wins.
Earliest-timestamp resolution is useful when the first successful claim should retain ownership.
Examples might include:
Because deletes and reinserts can otherwise make timestamp reasoning ambiguous, Oracle uses key-version tracking through an internal KEYVER$$ value when this resolution method is enabled.
Deletes create an interesting distributed-data problem.
Suppose Database A deletes a row.
Moments later, an older UPDATE for that row arrives from Database B.
Without additional metadata, Database A cannot distinguish:
"The row never existed"
from:
"The row existed but was deliberately deleted after
the incoming transaction was created."
ACDR solves this with a delete tombstone.
Conceptually:
Base Table
CUSTOMER_ID | NAME
------------+------
101 | Alice
After deletion:
Base Table
<no row>
while internal tombstone metadata retains something like:
CUSTOMER_ID | DELETE_TIMESTAMP
------------+-----------------
101 | T12
An incoming update with timestamp T8 can therefore be correctly recognized as older than the delete at T12 and ignored.
Oracle's 26ai documentation also describes key versioning and primary-key-update tracking in the tombstone infrastructure, allowing ACDR to distinguish different generations of what appears to be the same logical key.
Tombstone tables are operational metadata, and they can grow.
Oracle provides:
DBMS_GOLDENGATE_ADM.PURGE_TOMBSTONES
to remove sufficiently old tombstone entries.
A production active-active implementation should therefore include a deliberate tombstone retention policy.
Retention should always exceed any realistic interval during which an old transaction might arrive.
Purging aggressively merely to save space can undermine the reason the tombstone exists.
GoldenGate lag, outage duration, recovery procedures, retained trails, and replication restart scenarios should all be considered when establishing the policy.
Some data cannot be safely handled using "winner takes all."
Consider inventory:
Initial Quantity = 100
Database A sells ten:
100 -> 90
Database B sells five:
100 -> 95
Latest timestamp would produce either:
90
or:
95
Both answers are wrong.
The correct answer is:
85
Delta conflict resolution captures the mathematical difference associated with each transaction and applies both deltas during convergence.
Configuration uses:
BEGIN
DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR_DELTA_RES(
SCHEMA_NAME => 'APP',
TABLE_NAME => 'INVENTORY',
COLUMN_NAME => 'QUANTITY'
);
END;
/
Oracle describes delta resolution as particularly appropriate for values where concurrent increments and decrements must all survive, including financial-style balances and similar numeric accumulations.
Row-level conflict detection can sometimes be too coarse.
Consider:
EMPLOYEE
--------------------------------
EMPLOYEE_ID
OFFICE
TITLE
SALARY
PHONE
Database A changes:
OFFICE
while Database B changes:
TITLE
Technically, the same row changed at both locations.
Semantically, however, the two transactions do not conflict.
ACDR allows related columns to be divided into column groups.
For example:
LOCATION_GROUP
OFFICE
PHONE
COMPENSATION_GROUP
TITLE
SALARY
Each group receives independent conflict metadata.
Configuration might resemble:
BEGIN
DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR_COLUMN_GROUP(
SCHEMA_NAME => 'HR',
TABLE_NAME => 'EMPLOYEES',
COLUMN_LIST => 'OFFICE, PHONE',
COLUMN_GROUP_NAME => 'LOCATION_CG'
);
END;
/
Now Database A can change the employee's office while Database B changes compensation information, and both changes can converge rather than one unnecessarily overwriting the other.
Current Oracle documentation specifically identifies column groups as a mechanism for allowing different sites to update independent portions of the same row concurrently.
Not every business rule should be determined by time.
An organization may establish an authoritative site.
For example:
Headquarters > Regional System
for selected data.
GoldenGate supports site-priority handling in which a source-target relationship can be configured to overwrite or ignore conflicting changes based upon the designated site.
This enables business policies such as:
Customer demographics:
Most recent update wins.
Credit status:
Headquarters wins.
Inventory:
Delta resolution.
Employee compensation:
HR master site wins.
This illustrates an important architectural point:
There does not need to be one universal conflict-resolution strategy for an entire enterprise.
Resolution should correspond to the semantics of the data.
GoldenGate also supports a policy where a legitimate delete takes precedence over conflicting modifications.
This is useful for data where deletion represents a strong business decision—for example, deactivation or removal of an object that should not be unintentionally resurrected by a late-arriving update.
Oracle uses tombstone key versioning with this strategy so that a truly new generation of the same key can still be distinguished from the row version that was deleted.
One weakness of traditional column-comparison approaches was handling LOB values.
Modern ACDR provides special handling for LOB columns. Each LOB can be managed as its own column group with timestamp information used to determine whether an incoming piecewise LOB update should be applied or discarded.
That allows ACDR to manage data types that are difficult to include directly in ordinary SQL predicates.
A particularly useful 26ai enhancement is not a new conflict algorithm—it is operational maintainability.
Historically, removing ACDR metadata from a very large table could involve costly physical column removal.
With Oracle AI Database 26ai, when ACDR is removed, its internal columns can instead be marked UNUSED.
Administrators can physically remove those columns later during an appropriate maintenance window.
Oracle also supports DBMS_REDEFINITION for ACDR-enabled tables, allowing online reorganization activities such as:
while preserving ACDR hidden timestamp handling during redefinition.
This matters considerably for large enterprise tables where immediately dropping internal columns might otherwise create a lengthy maintenance event.
ACDR should not simply be added indiscriminately to an existing Replicat parameter file.
Oracle specifically notes that Automatic CDR cannot be combined for the same table with certain MAP-level exception/error mechanisms such as:
REPERROR
MAPEXCEPTION
The design must choose the appropriate conflict-handling approach for that table.
This is another reason ACDR should be treated as application architecture rather than merely a Replicat tuning parameter.
DML conflict resolution does not eliminate the need for disciplined DDL deployment.
A good active-active model continues to designate a controlled source for schema changes.
Examples include:
ALTER TABLE
CREATE INDEX
DROP INDEX
ADD COLUMN
RENAME COLUMN
Partition changes
Constraint changes
Schema modifications should not independently originate from multiple sites.
GoldenGate 26ai also changed default handling of tagged DDL. Beginning with the 23.26 release stream, tagged DDL is filtered from capture by default; Oracle Data Pump DDL uses tag 00.
That behavior can be overridden, but Oracle explicitly cautions that tag inclusion in bidirectional configurations can create duplicate DDL or replication loops.
For active-active environments, DDL therefore deserves the same change-control discipline as application deployment.
GoldenGate Studio 26ai provides an additional orchestration option for designing replication pipelines.
For an Active-Active pipeline, Studio can enable Automatic Conflict Detection and Resolution for selected tables and allows configuration of resolution choices including:
This does not eliminate the need to understand ACDR.
It does, however, reduce the amount of manual configuration required for standardized replication deployments.
A production active-active architecture should detect abnormal conditions before they turn into data-quality incidents.
GoldenGate 26ai has expanded its diagnostic interfaces, including an Integrated Diagnostics REST API for performance data associated with integrated Extract and integrated/parallel-integrated Replicat.
Useful operational measurements include:
Extract status
Replicat status
Checkpoint position
End-to-end lag
Transactions/sec
Operations/sec
Trail generation rate
Trail disk utilization
Distribution backlog
Receiver backlog
Discard activity
Replicat errors
Tombstone growth
Conflict frequency
Conflict counts themselves should be monitored.
A correctly functioning ACDR implementation that suddenly starts resolving thousands of conflicts per hour may not be "healthy."
It may be successfully hiding an application-routing problem.
For a modern Oracle-to-Oracle implementation, a strong baseline architecture is:
SITE A SITE B
+----------------+ +----------------+
| Oracle AI DB | | Oracle AI DB |
| Active R/W | | Active R/W |
+-------+--------+ +--------+-------+
| |
Integrated Extract Integrated Extract
| |
Local Trail Local Trail
| |
Distribution Service Distribution Service
| |
+----------- TLS ----------------+
| |
Receiver Service Receiver Service
| |
Remote Trail Remote Trail
| |
Parallel Replicat Parallel Replicat
Integrated Mode Integrated Mode
| |
+--------------------------------+
Bidirectional
ACDR Enabled
SETTAG / EXCLUDETAG Loop Control
Security should use TLS, with GoldenGate 26ai supporting modern TLS capabilities for Microservices communication. Oracle recommends TLS 1.3 where practical.
A production deployment should proceed in deliberate stages.
For every replicated table determine:
Can writes occur at both sites?
Can the same row be updated at both?
What uniquely identifies a row?
Are business unique keys present?
Can deletes occur?
Can primary keys change?
Are LOBs involved?
Classify each table as:
Conflict prevented by routing
Latest timestamp
Earliest timestamp
Site priority
Delta
Column groups
Delete always wins
Manual/business escalation
Establish Replicat tags and corresponding Extract exclusions.
Configure DBMS_GOLDENGATE_ADM.ADD_AUTO_CDR and optional column groups or delta resolution consistently on participating databases.
Use:
Integrated Extract
Parallel Replicat in Integrated mode
Microservices Distribution/Receiver architecture
for new 26ai implementations.
Do not merely test ordinary replication.
Deliberately create:
Insert/Insert
Update/Update
Update/Delete
Delete/Insert
Concurrent delta changes
Concurrent column-group updates
Primary-key updates
Network delay
Replicat outage and recovery
and prove the expected final state.
After every test:
Database A == Database B
should be demonstrated, not assumed.
Implement:
Lag alerting
Trail management
Tombstone purge policy
ACDR configuration auditing
DDL governance
Conflict reporting
Replication health monitoring
The database exposes metadata views for inspecting ACDR configuration.
For example, Oracle documents ALL_GG_AUTO_CDR_COLUMNS as a way to see which columns and column groups participate in automatic conflict resolution.
A mature GoldenGate environment should periodically inventory:
Database
PDB
Schema
Table
ACDR enabled?
Resolution strategy
Column groups
Delta columns
Tombstone table
Replicat
Extract
Trail
Loop-prevention tag
This configuration should be treated as production metadata and preferably tracked through version control or an enterprise configuration repository.
The greatest mistake in an active-active project is assuming that enabling ACDR makes every application automatically active-active safe.
It does not.
ACDR can decide which transaction survives.
It cannot always decide which transaction should survive.
A transaction involving:
an airline seat
a hotel room
a securities trade
a payment
a medical order
an inventory allocation
a legal status change
may require business semantics that no generic timestamp algorithm can infer.
The correct architectural order remains:
1. Prevent conflicts where possible.
2. Detect conflicts reliably.
3. Resolve deterministic conflicts automatically.
4. Escalate business-sensitive conflicts where necessary.
5. Monitor why conflicts occurred.
The underlying ACDR concepts remain remarkably durable.
What has changed is the environment surrounding them.
| Earlier GoldenGate Environment | GoldenGate 26ai Direction |
|---|---|
| Classic and Microservices both common | Microservices Architecture is the strategic architecture |
| Traditional Integrated Replicat | Parallel Replicat in Integrated mode preferred for new designs |
| Individual service administration | Unified Microservices console |
| Basic REST administration | Broader REST-based management and diagnostics |
| ACDR internal-column removal potentially disruptive | 26ai can mark ACDR columns UNUSED |
| Limited table-maintenance options around ACDR | DBMS_REDEFINITION supported with ACDR |
| Older loop-control techniques | SETTAG / EXCLUDETAG is the recommended Oracle pattern |
| Parameter-centric deployment | Web UI, REST API, Admin Client and GoldenGate Studio options |
| Conflict resolution largely operational | Increasingly managed as an architectural policy |
The transition is significant.
The replication engine is no longer the entire product.
GoldenGate has become a managed distributed-data platform in which replication, observability, security, orchestration, and conflict management operate together.
Oracle GoldenGate 26ai provides a mature platform for building active-active Oracle architectures, but the technology works best when conflict handling is designed rather than improvised.
The architecture should begin by determining which site owns which data, ensuring globally unique keys, minimizing replication latency, controlling DDL, and preventing replication loops.
Automatic Conflict Detection and Resolution then provides a powerful second layer of protection.
Through invisible timestamp metadata, delete tombstones, key versioning, column groups, delta resolution, timestamp policies, site priority, and delete handling, Oracle can automatically resolve many conflicts that historically required custom Replicat logic or application code.
GoldenGate 26ai strengthens that model through a modern Microservices Architecture, Parallel Replicat, improved diagnostics, REST-based administration, unified monitoring, and significantly improved ACDR maintenance capabilities.
The final objective is not merely replication.
It is deterministic convergence:
Regardless of where legitimate transactions originate, every participating database must eventually reach the correct and consistent business state.
That is the real measure of a successful GoldenGate active-active architecture.