The "copy table" or "append table" command fails with "Failed - Could not lock table(s)" on sourc (4330551)

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. You issue the "copy table" and then check its status after some time with the command "copy status" to find that it fails as below:

sp_ctrl (source_servername:port_num)> copy owner.table1

  copy started; job id 23

sp_ctrl (source_servername:port_num)> copy status

Job ID   : 23
Host     : source_servername
Started  : 06-NOV-08 16:10:18
Job Type : Copy
Status   : Failed - Could not lock table(s)

ID     Tablename                            Total Rows %Comp Status     Status e
------ ------------------------------------ ---------- ----- ---------- --------
1      "owner"."TABLE1"                              6       Locking          44

The copy table log on source named sync_svr* log also shows that the table is locked on source as shown:
.
.
Thu Nov 06/16:10:56.489:: Locking Tables
Thu Nov 06/16:10:59.587:: 002: WARNING: Table "owner"."TABLE1" locked by owner session(1091),process(1829),mode=EXCLUSIVE(6),OSuser(oracle) at sync/oci/sync_oci_utils.cpp:154
Thu Nov 06/16:10:59.589:: Locking thread completed in 2.98172 seconds
Thu Nov 06/16:10:59.608:: Could not lock any tables requested
Thu Nov 06/16:10:59.636:: ERROR: Could not lock tables at sync/svr/sync_server.cpp:136 at sync/svr/sync_server.cpp:159
Thu Nov 06/16:10:59.733:: Logged off from Oracle, 1 OCI connections open

The same thing can be encountered when running "append table" and hence the solution applies to that command as well.

The "copy table" could not lock the source table.

One of the requirement for successful running of this command is that it needs to lock source table briefly when it kicks off the Oracle Export with CONSISTENT=y.  If it were not to lock the source table when starting Export, then it may not be able to sync the target table. Once it locks the source table and then starts consistent Export, the lock can then be removed so that users keep accessing the source table and the disruption to the users is very brief. If, for any reason, the copy table server is not able to lock the source table, then the setting of the parameter SP_OSY_LOCK_TIMEOUT determines how long will the sync server keep trying to lock the source table before giving up on it. If the copy table failed due to the existing setting of the parameter, then the parameter can be set via sp_ctrl and then another copy table command issued.  The unit of this parameter is seconds. So, if you want to wait for 50 seconds while the sync server keeps retrying to lock the source table, you will issue the following command before launching the "copy table" again:

sp_ctrl>set param SP_OSY_LOCK_TIMEOUT 50

Another thing you can do is to either run the "copy table" during quiet time when there is a lesser probability of any application locking the source table or modify the application on source so that the locking by application is minimum.