...
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.
...
- 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.
- SQL affects more than one row. This causes data divergence and so a conflict is raised.
- 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).
- Lock timeout. If the apply APPLY waits for a row lock more than WATCHDOG_TIMEOUT seconds, a conflict is also reported.
...
| Note |
|---|
|
...
|
...
|
...
|
How is a conflict detected?
...
| PROD_ID | AMOUNT_RECEIVED |
|---|---|
| 101 | 250 |
When the following SQL is issued on the source database:
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
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 | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
update SALESset AMOUNT_RECEIVED = 120
where (1=1)
and AMOUNT_RECEIVED = 250250
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.