Versions Compared

Old Version 10

changes.mady.by.user KrupeshD (Deactivated)

Saved on

compared with

New Version Current

changes.mady.by.user Mike Donovan (Deactivated)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The consequence is that the SQL issued at the apply APPLY database is not the same issued against mine MINE – instead, each SQL updates/deletes/inserts exactly one row, applying just one change.

...

  1. SQL affects zero rows. This causes data divergence and so a conflict is raised. This could also mean that the target data has changed independently of the source data.
  2. SQL affects more than one row. This causes data divergence and so a conflict is raised.
  3. Oracle error. This can range from usual primary key or foreign key violation (another type of data divergence) to purely technical reasons (cannot extend datafile).
  4. Lock timeout. If the apply APPLY waits for a row lock more than WATCHDOG_TIMEOUT seconds, a conflict is also reported.

...

 

Note
  • Data divergence means that the data between the source and the target database is no longer in sync. The sooner data divergence is detected the easier it is too fix. Dbvisit Replicate will detect and notify as soon as any of the above issues are true (unless default conflict settings have been changed).
  • 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.

How is a conflict detected?

...

PROD_IDAMOUNT_RECEIVED
101250

 

When the following SQL is issued on the source database:

Section
Column
width5%

 

Column
width95
Panel No Format
bgColorCCC
update SALES set AMOUNT_RECEIVED = 120 where PROD_ID = 101;

 

The replicated SQL that is applied on the target database is as follows (note the WHERE clause contains the old value of AMOUNT_RECEIVED):

Section
Column
width5%

 

Column
width95
panel No Format
bgColorCCC
update SALES


set AMOUNT_RECEIVED = 120


where (1=1)


and AMOUNT_RECEIVED = 250
250 

and PROD_ID = 101;

 

If in the meantime, another transaction on the target database had changed AMOUTAMOUNT_RECEIVED from 250 to another value (say 199), then the above update would affect zero rows and the conflict would occur. This is because the WHERE clause (AMOUNT_RECEIVED = 250) would not be satisfied.

This ensures that the user is notified and no previous data will be lost.