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.
I recently worked through an interesting Oracle GoldenGate situation during a large enterprise migration from on-premises Oracle databases to OCI.
Names, system identifiers, and some implementation details have been changed, but the technical lessons are real.
The environment had grown to dozens of GoldenGate deployments supporting replication between legacy on-premises systems and OCI. As the migration expanded, the team began seeing very large trail-file storage consumption and concerns about whether additional CPU capacity was required for the GoldenGate infrastructure.
The natural reaction was to ask:
Do we need to scale the GoldenGate deployment?
But before adding CPUs, memory, or infrastructure, we started looking more closely at what GoldenGate was actually doing.
One of the first things that stood out was trail-file retention.
Some deployments had accumulated hundreds of gigabytes of trail files. The immediate assumption could easily have been that the replication workload itself was simply generating enormous volumes of data.
But trail-file size alone doesn't tell you that.
The more important questions are:
PURGEOLDEXTRACTS configured appropriately?If automatic trail cleanup isn't configured correctly, adding CPU doesn't solve the underlying problem.
It just gives an improperly managed environment more resources.
The environment also illustrated another issue I've seen increasingly with infrastructure automation.
Automation is great.
But automation can also automate architectural decisions that should have been reviewed first.
In this case, GoldenGate deployments had multiplied as replication requirements were added. Infrastructure-as-code made creating new deployments easy, but over time the result was a fairly large collection of deployments with varying configurations, authentication states, processes, and operational requirements.
Some deployments contained active Extracts or Replicats.
Others contained little or no active processing.
That creates an important distinction:
Provisioning automation is not the same thing as lifecycle management.
A mature GoldenGate implementation needs both.
For every deployment, I want to be able to answer:
If those questions can't be answered easily, scaling the environment should probably not be the first action.
Cloud interfaces and managed GoldenGate services change how the product is administered, but the fundamentals haven't disappeared.
Extract behavior still matters.
Replicat behavior still matters.
Checkpoints still matter.
Trail-file management still matters.
Error handling still matters.
Sequence handling still matters.
And parameter management absolutely still matters.
During migrations, it is especially important to establish ownership of GoldenGate configuration changes. Application teams may understand the business requirements for the data, while DBAs understand replication mechanics and operational risks.
Both groups need to participate, but someone needs to own the final configuration.
Otherwise, GoldenGate can slowly become a collection of individually reasonable changes that collectively form a difficult environment to operate.
Another lesson involved database sequences.
When replication becomes bidirectional, blindly replicating sequence behavior can create problems. Sequence strategy has to be intentionally designed for the topology.
Depending on the architecture, that may involve excluding sequences from replication, allocating different ranges, using different increment strategies, or resetting sequences appropriately when environments are cloned or transitioned.
The important point is that GoldenGate replicating data successfully does not automatically mean the overall application architecture is safe for bidirectional operation.
The biggest takeaway from this experience is simple:
Don't use infrastructure scaling as the first response to a GoldenGate operational problem.
Before increasing CPU or storage, determine whether the environment actually has a capacity problem.
I would normally check:
Replication
Infrastructure
Trail management
Architecture
Only after those are understood does scaling become an informed decision.
This wasn't really just a GoldenGate issue.
It's a common cloud-migration pattern.
Modern platforms make it incredibly easy to provision infrastructure.
That is valuable.
But the ability to create resources quickly can lead to environments where provisioning grows faster than operational governance.
The solution isn't less automation.
It's better automation.
Ideally, every GoldenGate deployment should be created with:
That's where I think the real opportunity lies.
Instead of treating GoldenGate deployments as individual infrastructure objects, treat the entire replication estate as a managed system.
Provision it. Inventory it. Monitor it. Audit it. Clean it up. And only then decide whether it needs more horsepower.
#Oracle #GoldenGate #OCI #OracleDatabase #CloudMigration #DatabaseAdministration #Exadata #DevOps #Automation #DatabaseArchitecture
MAA GoldenGate Performance
https://www.oracle.com/technetwork/database/availability/maa-gg-performance-1969630.pdf
GoldenGate 23c
https://www.oracle.com/middleware/technologies/goldengate-downloads.html
https://www.oracle.com/middleware/technologies/goldengate-downloads.html
One of the Oracle GoldenGate parameters that deserves more attention during migrations is:
HANDLECOLLISIONS
It sounds harmless enough. In fact, it can be extremely useful.
But it is important to understand why it exists and when it should be removed.
Oracle GoldenGate uses HANDLECOLLISIONS primarily to deal with duplicate-record and missing-record conditions that can occur when an initial data load and transactional replication overlap.
A common migration sequence looks something like this:
Source Database → Initial Load → Target Database
while at the same time:
Source Database → Extract → Trail → Replicat → Target Database
That overlap creates an interesting timing problem.
Imagine that a row exists in the source when the initial load begins.
While the initial load is running, the application updates that same row.
The update gets captured by GoldenGate.
Depending on timing, Replicat may encounter situations such as:
Those are exactly the situations HANDLECOLLISIONS was designed to help manage.
The important part comes next.
Once the initial-load synchronization period has completed and the source and target are properly aligned, continuing to run with:
HANDLECOLLISIONS
can potentially mask replication problems that should instead be investigated.
A duplicate key after synchronization is no longer necessarily an "initial load collision."
It may indicate:
If GoldenGate is allowed to automatically work around those situations indefinitely, the environment may appear healthy while the source and target slowly diverge.
That is why a mature GoldenGate migration process should have an explicit transition point:
Initial Load
HANDLECOLLISIONS
↓
Validate Source and Target Synchronization
↓
NOHANDLECOLLISIONS
↓
Normal Replication
At that point, duplicate or missing-record errors should generally be treated as diagnostic information, not automatically suppressed.
When inheriting an existing GoldenGate environment, don't just ask:
"Is Replicat running?"
Also ask:
"What parameters is Replicat running with?"
A Replicat showing RUNNING does not necessarily mean replication is configured correctly.
Reviewing parameter files should be part of any GoldenGate operational assessment, particularly after a migration, initial load, rebuild, or recovery operation.
A parameter that was absolutely correct during migration can become exactly the wrong parameter six months later.
HANDLECOLLISIONS is a perfect example.
#Oracle #OracleGoldenGate #GoldenGate #OracleDatabase #OCI #DatabaseMigration #DataReplication #DBA #DatabaseAdministration #CloudMigration