The event log show the following entries with a Shareplex process failure to write to afile:
.
.
02/05/08 06:51 Error: process sp_opst_mt killed due to SIGQUIT [sp_cop/10529]
02/05/08 06:51 System call error: No space left on device Can't write statusdb [sp_cop(stt)/10529
02/05/08 06:51 Notice: process sp_opst_mt killed due to SIGQUIT; (core file = /replication/splexm
p_cop/10529]
02/05/08 06:51 Process launched: sp_opst_mt (for o.SID1-o.SID2 queue queue_name) [pid = 7852]
.
02/05/08 06:51 Process launched: sp_opst_mt (for o.SID1-o.SID2 queue queue_name) [pid = 7852]
[1] 02/05/08 06:51 Notice: Oracle env - SID2:/opt/oracle9i/app/product [sp_opst_mt(pdb)/7852]
[1] 02/05/08 06:51 Error: 13015 - Error writing magic number (4 bytes) to file /replication/splexSID2/state/0x0aaa3d8f+
PP+queue_name+sp_opst+o.SID1-o.SID2-objcache_sp_opst.15: No space left on device [sp_opst_mt(osp)/7852]
[1] 02/05/08 06:51 System call error: No space left on device Can't write statusdb [sp_opst_mt(stt)/7852]
.
.
Lack of disk space in Shareplex variable directory at some point may have caused this.
This error is always associated with situations involving disk holding Shareplex variable directory become full at some point in time in the past resulting in failure to write to the object cache file, and is invariably accompanied by the message "No space left on device Can't write statusdb".
At times it resolves on its own when the space issue is not there anymore. So one may have to restart any Shareplex process if it exited. At other times, the following happens and the resolution for each of them is different:
a. Some files in the data subdirectory may get corrupted and typically they are either statusdb or paramdb. Since these files barely change, one can restore them if one has a recent backup of the variable directory. This can be done after sutting down Shareplex. If this is the source, the statusdb contains activation entry and one may have to contact Support to generate a fresh activation entry by manipulating the statusdb if the activation happened since the last time it was backed up. Regarding the paramdb, it can easily be restored from a backup and at most there may be some parameter changes that may not be reflected in it. If no backup exists, a new file can easily be recreated from another one from another server and may just require running of ora_setup.
b. Sometimes disk full can result in queue corruption whereby the data is stuck in one of the queues (Capture or Export on source, Post on target). Depending on which side is affected, one can try the following to resolve it or call Support to do it:
1. cleanly shutdown Shareplex
2. while in /proddir/bin, invoke the qview utility and do the following:
qview -i
qview>fixup all
qview>exit
3. Restart Shareplex (and the affected process, if it stopped due to error)
© ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center