Page Comparison

To force the conflict, update a record in the target table is going to be updated to a different value than in the source table.

1. On the target table on the target server (dbv02), run the following SQL to update the value

sqlplus oerepoe/oe@ttorclrepoe@ttorcl_trg

SQL> updateUPDATE SALESsales setSET AMOUNTamount_RECEIVEDreceived = 60 
whereWHERE SALESsales_STATUSstatus = 'OVERDUE' 
andAND PRODprod_IDid = 101;
commitCOMMIT;

2. The AMOUNT_RECEIVED column in record PROD_ID = 101 on the target now differs from the source.

3. Update the AMOUNT_RECEIVED for PROD_ID = 101 on the source database. On source server (dbv01) run the following SQL to update the value

sqlplus oerepoe/oe@ttorclrepoe@ttorcl_src

SQL> update SALES set AMOUNT_RECEIVED = 120 
where SALES_STATUS = 'OVERDUE' 
and PROD_ID = 101;
commit;

...

6. The type of conflict is shown against the sales table. The conflict is "Command affected 0 rows".

OEREPOE.SALES:                      80%  Mine:5/5             Unrecov:0/0         Applied:4/4         Conflicts:1/1       RETRY:Command affected 0 row(s).

7. Type " list conflict" in the command console to view the complete SQL statement causing the conflict

...

8. As can be seen from the SQL statement in the above list conflict, the SQL statement contains the OLD value of "AMOUNT_RECEIVED IS NULL". This is the reason for the "Command affected 0 rows". The AMOUNT_RECEIVED was updated from NULL to 60 on the target database in step 1 and so the original value of "AMOUNT_RECEIVED IS NULL" is no longer valid. In order to detect such changes in the data, the replication has added the old value of the value to be update in the where WHERE predicate. This is true for most logical replication technologies.

...