If the source is already replicating to one target and a second target is being added to this replication stream, the procedure listed in this solution can be used. This procedure uses source as a reference when synchronizing the target. The advantage to this approach is that the newly added target can have certain characteristics which are distinct from the original target, such as objects in replication, constraints on replicating objects, etc.
General information.
The following procedure is a corollary to the procedure listed in Shareplex Administrator Guide Chapter titled "Starting Shareplex Replication" section titled "Synchronizing data using an Oracle hot backup on an active database":
1. On the source and new target system, go to the bin sub-directory of the SharePlex product directory, and start sp_cop and sp_ctrl.
2 On both systems, verify that the SharePlex processes are started.
sp_ctrl(sysA)> status
sp_ctrl(sysB)> status
3 On the new target system, stop the Post process. This allows replicated data to accumulate in the post queue until the database has been recovered and reconciled.
sp_ctrl(sysB)> stop post
4 On the source system, run the Oracle hot backup.
5 When the backup is finished, activate the configuration on the source system, using live activation. To do this:
sp_ctrl>copy config old_config to new_config
sp_ctrl>edit config new_config (This configuration will have the information related to new target as well.)
sp_ctrl(sysA)> activate config new_config live
6 On the source system, issue the show activate command to view activation status. The command retains control of sp_ctrl until activation is finished.
sp_ctrl(sysA)> show activate
7 When activation is complete, switch log files on the source system and make a note of the highest archive-log sequence number.
svrmgrl> alter system switch logfile;
8 On the new target system, recover the database from the hot backup using the UNTIL CANCEL option in the RECOVER clause, and cancel the recovery after Oracle has fully applied the log from step 7.
9 On the new target system, open the database with the RESETLOGS option.
10 On the new target system, run ora_setup on the database, but do not create a new user. Choose the existing SharePlex user and password (copied in the backup) by choosing "N" when prompted "Would you like to create a new SharePlex user [y]" In this case, you need not shut down SharePlex when you run ora_setup.
11 On the new target system, issue the reconcile command. If using named post queues, issue the command for each one. Substitute the sequence number of the log that you noted in step 9. Issue the qstatus command if unsure of the queue name. The reconcile process retains control of sp_ctrl until it is finished, and then the sp_ctrl prompt returns.
sp_ctrl(sysB)> reconcile queue queuename for datasource-datadest seq
sequence_number
For example: if you are replicating from instance oraA on SysA to oraA on SysB, the syntax would be:
sp_ctrl(sysB)> reconcile queue SysA for o.oraA-o.oraA seq 1234
12 On the new target system, run the cleanup.sql script to truncate all of the SharePlex internal tables. Instructions for running this script are given in Shareplex Administrator's Guide Chapter titled "Shareplex Utilities" section titled "Truncating the Shareplex tables with cleanup.sql".
13 On the new target system, disable triggers on the tables, or run the sp_add_trigger.sql utility script so that the triggers ignore the SharePlex user.
14 On the new target system, disable cascading deletes, check constraints, and scheduled jobs that perform DML.
(if you wish to retain constraints on the new target, then you can omit some of the actions from step # 14)
15 On the new target system, start the Post process. The two instances are now in synchronization, and SharePlex will continue replicating to maintain synchronization.
sp_ctrl(sysB)> start post
The above procedure assumes that there are no LOBs involved in replication. Nor is there any partition scheme involved.
