After upgrading to Shareplex 6.x or up from a lower version, one finds that the Capture is stopped due to error:
sp_ctrl (source_servername:port_num)> show
Process Source Target State PID
---------- ------------------------ ------------ -------------------- ------
Capture o.source_SID Stopped - due to error
Read o.source_SID Running 10189
The event log shows the following:
sp_ctrl (source_servername:port_num)> show log reverse
Info 2008-10-30 14:38:08.561242 11414 1 Capture exited with code=1, pid = 10191 (capturing from source_SID)
Error 2008-10-30 14:38:08.541652 10191 1 Capture stopped: Internal error encountered; cannot continue (capturing from source_SID)
Error 2008-10-30 14:38:08.537874 10191 1 Capture: 10703 - can't read partition cache o.source_SID 1 (capturing from source_SID) [module oct]
Error 2008-10-30 14:38:08.532976 10191 1 Capture: 15024 - OCIStmtExecute failed with ORA-942. (capturing from source_SID) [module osp]
Notice 2008-10-30 14:38:07.791338 10191 1 Capture: Replicating according to target compatibility of "6.0.0.0" (capturing from source_SID) [module utl]
Info 2008-10-30 14:38:07.076266 10191 1 Capture launched, pid = 10191 (capturing from source_SID)
Notice 2008-10-30 14:38:07.065254 10176 1 User command: oracle start capture (from source_servername.quest.com)
Failing to run ora_setup after Shareplex upgrade to 6.x is the cause.
When upgrading Shareplex from one version to another, it may be required to run ora_setup. This is to update the internal tables of Shareplex, in case there is any changes to the Shareplex inernal tables in the new version. This need is detailed in Shareplex Installation Guide and Release Notes. Not running ora_setup may cause the Shareplex schema not to be updated resulting in such undesired side effects. If one wishes to retain the existing replication after upgrade, one should keep the same Shareplex user, especially when running ora_setup on source. Be sure to check the Patch Notes or the Release Notes to determine if any changes were made to shareplex internal tables and if ora_setup is required.
In the following example, the user first tried to run ora_cleansp to clean up the Shareplex environment, to see if this resolved the issue. However, it resulted in the following error:
source_servername # ./ora_cleansp username/password
sp_cop is running: are you sure you want to perform the clean? (N) y
SQL*Plus: Release 10.1.0.2.0 - Production on Thu Oct 30 14:41:03 2008
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL> SQL>
Table truncated.
SQL>
Table truncated.
.
.
SQL>
Table truncated.
SQL> truncate table shareplex_partition_cache
*
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> truncate table shareplex_lob_cache
*
ERROR at line 1:
ORA-00942: table or view does not exist
This proved that the Shareplex installation did not had these two internal tables that are supposed to exist in Shareplex 6.0 or up but not in the lower versions. After running ora_setup (which created these two tables) and starting Shareplex, Capture could be started.
If one wants to salvage the existing activation, it would be advisable to avoid running ora_cleansp first and running ora_setup instead. The ora_cleansp should be run as a last resort if the Capture cannot be started even after running ora_setup. Support can be consulted prior to running ora_cleansp.
