Managing Conflicts
Uniform conflict-resolution procedures must be in place on all systems in an active-active configuration. Conflicts should be identified immediately and handled with as much automation as possible; however, different business applications will present their own unique set of requirements in this area.
Because Oracle GoldenGate is an asynchronous solution, conflicts can occur when modifications are made to identical sets of data on separate systems at (or almost at) the same time. Conflicts occur when the timing of simultaneous changes results in one of these out-of-sync conditions:
-
A uniqueness conflict occurs when Replicat applies an insert or update operation that violates a uniqueness integrity constraint, such as a
PRIMARY KEY
orUNIQUE
constraint. An example of this conflict type is when two transactions originate from two different databases, and each one inserts a row into a table with the same primary key value. -
An update conflict occurs when Replicat applies an update that conflicts with another update to the same row. Update conflicts happen when two transactions that originate from different databases update the same row at nearly the same time. Replicat detects an update conflict when there is a difference between the old values (the before values) that are stored in the trail record and the current values of the same row in the target database.
-
A delete conflict occurs when two transactions originate at different databases, and one deletes a row while the other updates or deletes the same row. In this case, the row does not exist to be either updated or deleted. Replicat cannot find the row because the primary key does not exist.
For example, UserA on DatabaseA updates a row, and UserB on DatabaseB updates the same row. If UserB's transaction occurs before UserA's transaction is synchronized to DatabaseB, there will be a conflict on the replicated transaction.
A more complicated example involves three databases and illustrates a more complex ordering conflict. Assume three databases A, B, and C. Suppose a user inserts a row at database A, which is then replicated to database B. Another user then modifies the row at database B, and the row modification is replicated to database C. If the row modification from B arrives at database C before the row insert from database A, C will detect a conflict.
Where possible, try to minimize or eliminate any chance of conflict. Some ways to do so are:
-
Configure the applications to restrict which columns can be modified in each database. For example, you could limit access based on geographical area, such as by allowing different sales regions to modify only the records of their own customers. As another example, you could allow a customer service application on one database to modify only the
NAME
andADDRESS
columns of a customer table, while allowing a financial application on another database to modify only theBALANCE
column. In each of those cases, there cannot be a conflict caused by concurrent updates to the same record. -
Keep synchronization latency low. If UserA on DatabaseA and UserB on DatabaseB both update the same rows at about the same time, and UserA's transaction gets replicated to the target row before UserB's transaction is completed, conflict is avoided. See Tuning the Performance of Oracle GoldenGate for suggestions on improving the performance of the Oracle GoldenGate processes.
To avoid conflicts, replication latency must be kept as low as possible. When
conflicts are unavoidable, they must be identified immediately and resolved with as much
automation as possible, either through the Oracle GoldenGate Conflict Detection and
Resolution (CDR) feature, or through methods developed on your own. Custom methods can
be integrated into Oracle GoldenGate processing through the SQLEXEC
and
user exit functionality. See Manual Conflict Detection and Resolution for more information about using Oracle GoldenGate to handle conflicts.
For Oracle database, the automatic Conflict Detection Resolution (CDR) feature exists. To know more, see Automatic Conflict Detection and Resolution.