Starting with Shareplex 6.0 and up, the "copy table" has been introduced to sync tables. It uses Oracle's Export/Import utility and has a number of options available which includes synchronizing tables not involved in replication. This solution delves on the limitations of the copy command when synchronizing object(s) in a High Availability (HA) environment. The solution also applies to the "append table" command.
The "copy table" command may not always be suitable in a HA environment. The series of steps occurring during sync may result in the Capture in secondary side gathering the DMLs that were executed to sync the table on HA side by the Oracle Import process. This may warrant additional steps after the copy to maintain the integrity of the data.
Running "copy table" in HA environment may run into issues because of the way the command operates and may need special considerations.
There are two ways of handling the issue of Capture gathering DMLs that were applied by the Oracle Import on secondary Shareplex:
A. Removing such messages:
As opposed to compare, the copy command results in Oracle Import process executing DMLs on target that are gathered by the Capture process in the reverse config. If you issue a "qstatus" command on the sp_ctrl prompt on the secondary after the successful completion of the "copy table", you will see that its Export queue has messages accumulated as a result of the resync done by the copy assuming that the Shareplex Export process is stopped on the HA side (which is normally the case). If you do not normally keep the Export stopped in your HA environment, you need to keep it stopped at all times if you intend to run the "copy table" to prevent the loopback. It also requires that prior to planned or unplanned failover, the messages in Export queue be removed with the help of qview utility. See Solution # SOL540 for details on using qview. The Admin Guide chapter titled "Using SharePlex in a High-Availability Environment" section "Failing back to the primary system after an unplanned system failure" delves on getting rid of the queues using deleteq command in sp_ctrl instead of using qview utility and this will also work in lieu of solution SOL540. Support can be contacted for any help in this.
B. Letting Capture ignore such DML for the duration of Oracle Import:
You can force the Capture process on secondary to ignore the transactions that occur due to Oracle Import run on it for resync purpose. This will let Capture only gather row chaining info if any, since it needs it during UPDATE DMLs as otherwise the target rows may have out of sync issues later. Other than this, the Capture will not gather any transactions. You can later undo the change so that Capture will be ready to gather transactions, once the failover happens and the secondary becomes the primary database. The following is the procedure:
1. Set the parameter SP_OCT_GEN_STOP as follows:
sp_ctrl> set param SP_OCT_GEN_STOP 0x03
2. Carry out the Oracle Import on target to resync the table. Then unset the parameter as follows:
sp_ctrl> reset param SP_OCT_GEN_STOP
NOTE: As a word of caution, if the parameter is not unset, then Capture will not gather any changes to secondary database and this can cause out of sync problems when this secondary becomes primary during a failover. So, if using option B, make sure to reset the parameter SP_OCT_GEN_STOP once the Import finishes.
The details on how to get rid of queues on the HA side are also available in solution # SOL24046 which deals with a situation somewhat similar to what is experienced in this solution.