...
When a new table is added to the replication, it is usually necessary to ensure that the historical data is in the target table before the replication starts.
For 2-way replication this process is slightly more complicated. One cannot simply take a source data as of given SCN and move it to the target server, as these data would be replicated back to the source as soon as the apply APPLY process is resumed (which would cause replication conflicts on the source server). It is necessary to label the data for the apply APPLY process to recognize it and ignore it.
To ensure data is synchronized correctly and there is no gap between loading the historical data and starting the replication, follow these steps:
| Note | |||||||||
|---|---|---|---|---|---|---|---|---|---|
In the following example we are using a 2-way configuration described by this table:
|
1. Pause the
...
APPLY processes
It is necessary to pause the apply APPLY process for both replication directions. To do so choose one replication, pause the first apply APPLY process and then choose the second replication a pause the second apply APPLY process:
| No Format | ||
|---|---|---|
| ||
dbvrep> choose show Process MINE chosen, it is a MINE. Process APPLY chosen, it is a APPLY. dbvrep> pause apply Apply requested to pause. dbvrep> choose replication mine1 Process type MINE set to: mine1. Process type APPLY set to: APPLY1. dbvrep> choose show Process mine1 chosen, it is a MINE. Process APPLY1 chosen, it is a APPLY. dbvrep> pause apply1 Apply requested to pause. dbvrep> list status MINE IS running. Currently at plog 10441 and SCN 43299785 (03/14/2013 11:50:59). APPLY is PAUSED. Currently at plog 10441 and SCN 43299607 (01/01/1988 00:00:00). MINE1 IS running. Currently at plog 3298 and SCN 43252417 (03/14/2013 11:50:59). APPLY1 is PAUSED. Currently at plog 3298 and SCN 43252398 (03/14/2013 11:50:49). |
...
Use the SCNs from step 2 to load the historical data.
For 2-way replication you cannot simply move the historical data from the database A to B and vice versa, because Dbvisit Replicate would try to replicate this data back as soon as the apply APPLY processes are resumed. This would cause the data corruption and replication conflicts, as the data is already in both databases.
...
Run the following command to obtain an Apply APPLY database name:
| No Format | ||
|---|---|---|
| ||
dbvrep> show apply_database APPLY1.APPLY_DATABASE = UNITSRC APPLY.APPLY_DATABASE = UNITTRG APPLY1.APPLY_DATABASE_DBID = 433515465 *.APPLY_DATABASE = APPLY.APPLY_DATABASE_DBID = 742136697 *.APPLY_DATABASE_DBID = |
...
Note that for every table within the schema you have to synchronize the data as described above. These are the steps to follow:
Pause the apply APPLY processes for both replication directions .
...
Synchronize the data for all tables (using transaction names as shown above)
Resume both apply APPLY processes
Removing tables & schemas
...