-
Title
Capture is not processing any changes to the database and the message “Capture: Failed to laun -
Description
Capture is not processing any changes to the database and is stuck at a particular log offset as seen in the output of “show capture detail”. The message “Capture: Failed to launch slave thread (code=-6)...exiting...” keeps appearing in the event log. It is in state of incomplete recovery as evidenced by the message “Capture: Queue write recovery started” and the absence of the corresponding message “Capture: Queue write recovery completed”. The following are sample entries from the event_log:
Error 2010-10-26 23:31:44.889000 3400 2600 Capture: Failed to launch slave thread (code=-6)...exiting...(d:\starsrc\james\nemmco-6.1.1.11\src\olog\olog.c:1740) (capturing from NAME) [module oct]
Info 2010-10-26 23:32:33.894000 2972 1996 Capture exited with code=250, pid = 3400 (capturing from NAME)
Notice 2010-10-26 23:32:34.097000 3172 2520 Capture: Replicating according to target compatibility of "6.0.0.0" (capturing from NAME) [module utl]
Info 2010-10-26 23:32:34.097000 3172 2520 Capture launched, pid = 3172 (capturing from NAME)
Notice 2010-10-26 23:32:34.300000 3172 2520 Capture: The SharePlex supplemental logging state is: Enabled (capturing from NAME) [module oct]
Notice 2010-10-26 23:32:34.300000 3172 2520 Capture: ocm set upgrade version from 0 to 610 (capturing from NAME) [module oct]
Error 2010-10-26 23:32:34.409000 3172 2520 Capture: Error creating LOB Cache on un_checkpoint: o.NAME 2 (capturing from NAME) [module oct]
Notice 2010-10-26 23:32:34.487000 3172 2520 Capture: Queue write recovery started, qrw_srcseq=413594000 msg.mpseq=410839000 (capturing from NAME) [module que]
-
Cause
The internal queue for Capture is filled up and consequently it is not able to launch the slave thread.
-
Resolution
The behavior has to do with the internal memory used by Capture for storing messages in its internal queue (not the external Capture queue) before sending it to the Capture queue. Once the Capture falls too much behind, the internal queue can get full resulting in failure of Capture to launch a slave thread.
To resolve the issue, increase the value of Capture parameter SP_OCT_OLOG_LOGPAR_QSIZE from its current setting to say, double the value. The default value for the parameter is 5000 and it denotes the maximum number of messages that can be stored in the internal Capture queue. The parameter takes effect once the Capture is bounced (stopped and then restarted). For example, if the current value is 5000, increase it to 10000 as below:
sp_ctrl>set param SP_OCT_OLOG_LOGPAR_QSIZE 10000
sp_ctrl>stop capture
sp_ctrl>start capture
Once the issue is over, and when the Capture catches up with Oracle, the parameter can be reset with:
sp_ctrl>reset param SP_OCT_OLOG_LOGPAR_QSIZE
sp_ctrl>stop capture
sp_ctrl>start capture
If the issue persists despite doubling or quadrupling the initial value, contact Support for further investigation.