Content Comparison

...

Lets insert some simple row and check in console, how did the replication workedwork.

We are going to insert a row to the table REPOE.CARD_DETAILS. We will create u a unique value of CARD_TYPE column in order to be able to check, whether the row was replicated or not.

...

Open any SQL tool, connect as repoe/repoe@TTORCL_SRC to source database and run following querycommand:

REPOE@TTORCL_SRC> insert into REPOE.CARD_DETAILS (card_id, customer_id, card_type, card_number, expiry_date, is_valid, security_code)
2 values (CARD_DETAILS_SEQ.nextval, 1287, 'REPOE_TEST', 9102450385, sysdate, 'Y', 1000 );
1 row created.
REPOE@TTORCL_SRC> commit;
Commit complete.

...

When we see in the console, that the row was sucessfully replicated to the target database, we can should check, if it is correctly replicated. Connect to target database as user repoe/repoe and run following command:

...

In order to simulate conflict in replication, we have to create at least one row, that is precise clone of another row. This cannot be created on table, that has primary key defined. In RepAttack prepared testing environment, there are just two tables, that do not have primare primary keys defined:

REPOE.LOGON and REPOE.ORDERENTRY_METADATA. We will use the REPOE.LOGON table for duplicate creation. Run following insert on source database to create duplicity:

...

Check in the console, that we have really created the conflictOn source database run following update command.

REPOE.LOGON:                   33%  Mine:3/3             Unrecov:0/0         Applied:1/1         Conflicts:1/1       
Last:23/01/2015 04:05:29/RETRY:Command affected 2 row(s).

At this moment the apply process stopped and is waiting for manual resolve of the conflict. 

Listing and Resolving Conflicts

As we have created a conflict, we have to see what exactly happened.

...

dbvrep> list conflict
Information for conflict 32010159940 (current conflict):
Table: REPOE.LOGON at transaction 000a.01f.000001df at SCN 653532
SQL text (with replaced bind values): update "REPOE"."LOGON"
set "LOGON_ID" = 100000000
where (1=1)
and "LOGON_ID" = 1000000
and "CUSTOMER_ID" = 496840
and "LOGON_DATE" = to_date('2006.03.31 04:18:40','yyyy.mm.dd hh24:mi:ss')
Error: Command affected 2 row(s).
Handled as: PAUSE
Conflict repeated 21 times.

Take a note of how was the original query transformedwas transformed. You can see, that except except our original "LOGON_ID" = 1000000 condition, there were automatically added "CUSTOMER_ID" = 496840 and "LOGON_DATE" = to_date('2006.03.31 04:18:40','yyyy.mm.dd hh24:mi:ss') search conditions. These were added in order to apply be able to uniquely identify the row it needs to change.

Also look at the row "

Error: Command "affected 2 row(s)." This 

Create duplicate using more rows DML

...