Align |
---|
The replication is a row-based which means that the changes are mined row-by-row on the mine. While any SQL issued on the source database can change arbitrary number of rows, Dbvisit Replicate will only affect changes made to individual rows. The consequence is that the SQL issued at the apply database is not the same issued against mine – instead, each SQL updates/deletes/inserts exactly one row, applying just one change. Definition of a conflict: If the SQL affects zero rows, OR more than one row THEN data divergence occurred and a conflict is raised. Another type of conflict is any error reported by Oracle – this can range from usual primary key or foreign key violation (another type of data divergence) to purely technical reasons (cannot extend datafile). The last type of conflict is lock timeout – if the apply waits for a row lock more than WATCHDOG_TIMEOUT seconds, a conflict is also reported. Note that when applying a row-change, previous values of the row at apply are checked (by means of adding them to the where clause). This effectively detects if the data in that row are inconsistent between mine and apply, and this is reported as a conflict, "0 rows updated/deleted." This can happen for update or delete only (there is no previous row to check for insert) and due to its special role, it can be handled differently.Conflicts and conflict resolution is important in database replication. When a conflict occurs it means there is a potential for the data between the source and target databases to be out of synch. This is also referred to as data divergence. Dbvisit Replicate has build in conflict detection and conflict resolution features that assist with ensuring data divergence does not occur. Dbvisit Replicate offers:
This section discusses all the options and commands around conflict detection and conflict resolution.
|
Page Comparison
General
Content
Integrations