To bring certain tables into replication to a second target which are already replicating to a first target and concurrently sync them from the first target.
Assumptions:
1. There exists a replication between source and two targets.
2. The source replicates a number of tables to first target which are not currently replicated to second target.
3. You want to bring these tables into replication from source to second target.
4. You also want to sync them at the same time when we include them in replication, but wish to use Oracle Export/Import and not hot backup with reconcile.
5. There is a downtime available on source for this.
The following steps should be able to accomplish our objective:
NOTE: This resolution is based on the assumptions made in the problem description. Also, the procedures given in this solution is to be used as a guideline; some replication schemes need extra steps depending on the needs and or resources.
1. Quiet the source tables that need to be replicated to the second target. Then issue flush from source so that Shareplex will put a marker in redolog and the Capture process will in turn gather this message and sent it across to both targets where the Post will stop due to flush. In effect, this is nothing but a reference point at which Post will stop.
sp_ctrl>flush o.SID (Where SID is the source's Oracle SID)
2. Make a copy of the currently active config file, add the second target to the routing map of the tables that need to replicate to second target and activate the copy. This should activate in a very short time as no table needs to be locked for chained row ANALYZE and the lock is very brief. After this the users can resume activity on the source tables.
3. Using Oracle Export/Import or other means, recreate the tables to be replicated in the second target.
4. Disable or modify the triggers, constraints, etc according to your replication strategy in the second target for these new tables.
5. start Post on both targets.
You do not have to carry out the elaborate steps of quieting the source tables, issuing flush, etc. But by executing these steps, you can ensure that there will be no out of sync on second target. To keep the downtime to a minimum, you can keep the copy of the config file ready.
