The Capture queue has 0 messages and does not grow though the "status" issued from sp_ctrl shows that it is running. The event log shows the following:
sp_ctrl (wpst4002:2109)> show log reverse
03/27/08 16:34 Warning: 12035 - OCISessionBegin failed with ORA-1034. [sp_ordr(osp)/18637]
03/27/08 16:33 Warning: 12035 - OCISessionBegin failed with ORA-1034. [sp_ordr(osp)/18637]
03/27/08 16:33 Warning: 12035 - OCISessionBegin failed with ORA-1034. [sp_ocap(osp)/18962]
The "show capture detail" output is:
Host: wpst4002
Operations
Source Status Captured Since
---------- --------------- ---------- ------------------
o.w141prbr Running 0 20-Mar-08 19:54:13
Oracle current redo log : 61548
Capture current redo log : 61017
Capture log offset : 8398352
Last redo record processed:
None
Capture state : Initializing
Activation id : 0
Error count : 0
Operations captured : 0
Transactions captured : 0
Concurrent sessions : 0
HWM concurrent sessions : 3
Checkpoints performed : 39600
Total operations processed : 25113871
Total transactions completed : 13743804
Redo records in progress : 0
Redo records processed : 55497358
Redo records ignored : 30382179
Redo records - last HRID : N/A
And the latest *ocap* log in $SP_SYS_VARDIR/log directory shows that the following entry is appended to the log at all times:
08-03-20 19:54:13.574013 18962 1 ocap_conn = 0
08-03-20 19:55:13.651499 18962 1 ocap_conn = 0
08-03-20 19:56:13.740749 18962 1 ocap_conn = 0<
Variety of reasons can cause this issue.
You may want to check for the following:
1. See if Oracle is running. If not, then start the database and see if the issue goes away.
2. From the session that launches Shareplex, see if you can connect to SQL*Plus and if not, whether the /etc/oratab or /var/opt/oracle/oratab file (depending on your OS) is configured correctly. If not, correct it and see if this helps.
3. Make sure that the environment has correct settings for ORACLE_SID and ORACLE_HOME, and if not, set them correctly before bouncing Shareplex and see if this helps.
4. If the problem started happening after certain events like Oracle upgrade that materially alters the characterisitcs of the Shareplex instance, you may want to check if the ora_setup was correctly run. One way to rule out any problems with ora_setup is to re-run it again. There is no harm in running it again after shutting down Shareplex so long as you do not change the Shareplex user for the database. Please be aware that this is source and changing the user will get rid of current activation and would therefore be a big show stopper. If using Bequeath, the ora_setup can be run as directed in Admin Guide. If using sql*net, you may want to run it while taking care that when prompted for system password use password@<connect string> to use SQLNet connectivity to Oracle.Do the same for shareplex user password. See if starting Shareplex and Capture resolves the issue.
5. Check to see if tnsping on the instance is successful, if not fix that TNS response issue and try bouncing Capture.
6. Check permissions on $ORACLE_HOME/bin/oracle. These should be set by using the chmod 6751 oracle command to set the sticky bit ( -rwsr-s--x ).
7. If it is a RAC system then make sure the oracle shareplex user is using the correct TNS_ALIAS.
Verify in the listener.log .
If it is not using the TNS_ALIAS or is using Incorrect TNS_ALIAS re-run ora_set using the correct TNS_ALIAS.
Enter the SYSTEM account password appended with @alias_name, where alias_name is the TNS alias, for example manager@ora.
Append the password with @alias_name, where alias_name is the TNS alias, for example splex@ora.
Starting with SharePlex 8.6.2, it is no longer required to append the password with the connect string in SQL*net environment. During running of ora_setup, SharePlex is able to gather info on connect string and is able to append the value of connect string to the password field specified by the user. Please refer to the knowledgebase article 184662 for details.
SOL12360 lists a number of other scenarios (besides Oracle upgrade) that can also cause this issue.
