The copy/append commands to sync the target table are very useful tool in certain situations. These commands have their own pros and cons vis-à-vis compare and other means for synchronization. This solution delves on the impact on the target table when cancelling or aborting copy or append.
General information.
Cancelling or aborting a copy or append has different impact on the target table. When a copy or append is run, there is a sync marker (a kind of token message) sent via Shareplex queues from source to target and once the Post receives the marker, it truncates the target table in case of copy but not when running append.
If cancelling a copy process, this can cause target table to be empty or incomplete. If the table in question is very large, this can cause inconvenience as even a makeshift re-creation of target table using ordinary Export/Import may take some time. One way to avoid this may be to make a duplicate copy of the target table prior to running a copy by using “create table <name> as select * from <name1>” or any other means. This way at least users will have at least have another table to fall back upon, even though it is not completely in sync.
If cancelling an append process, it will cause the target table to have incomplete rows but since the Post does not truncate the target table on receiving the sync marker, the target table will not be empty because of the abort (unless it was empty to begin with).
The best practice is to let these sync commands run till their logical conclusion instead of intervening half way. For very large tables, this may take time.
