Import goes into recovery and messages from export are lost or do not make it to target due to import discarding them or they accumulate on source. Import can go into recovery due to a number of reasons relating to OS or server, one such reason could be the system panic. Another common reason may be network problems. Sometimes disk full problems can show the error "sp_mport: rim_writecommit failed" which is also accompanied by Import in recovery. Improper running of hotbackup reconcile can lead to Import recovery. Post queue corruption can lead to Import recovery. The Post seems to be running but nothing gets posted to the target. The Post queue may have some messages or no messages but the figure remains constant. The following type of messages keep repeating in the target event log indicating a problem with "queue write recovery" with Import process errors out all the time.
11/06/03 23:41 Process launched: sp_mport (from vrbhds02.quest.com queue vrbhds02) [pid = 998]
11/06/03 23:41 Connected to export on vrbhds02.quest.com
11/06/03 23:41 Notice: sp_mport(que) (from vrbhds02.quest.com queue vrbhds02) Queue write recovery started, qrw_srcseq=791559842464 msg.mpseq=791559731464
11/06/03 23:58 Cannot connect to export on vrbhds02.quest.com
11/06/03 23:58 Process exited sp_mport (from vrbhds02.quest.com queue vrbhds02) [pid = 998] - exit(1)
1. No network connection between the source and target
2. Post queue corrupted
Resolutions are listed in the degree of ease
Resolution 1
Stop Post and truncate Shareplex_trans table in the database. Then start Post and see if the problem goes away.
Resolution 2
See if nslookup by hostname and IP from source to intermediate and vice versa resolves fine. If not, correct the problem.
Resolution 3
Set debug on Export and Import to see if there are any connection problems:
sp_ctrl>stop export
sp_ctrl>set param SP_XPT_DEBUG 0xffffffff
sp_ctrl> start export
On the other system set the debug on import:
sp_ctrl> stop import
sp_ctrl> set param SP_IMP_DEBUG 0xffffffff
sp_ctrl> start import
Let each of these run for 5-10 minutes then turn them off by doing the following:
On the system where export is slow:
sp_ctrl>stop export
sp_ctrl>reset param SP_XPT_DEBUG
sp_ctrl> start export
On the other system turn the debug off on import:
sp_ctrl> stop import
sp_ctrl> reset param SP_IMP_DEBUG
sp_ctrl> start import
This debug will generate a log file called trace_log and it is located in the vardir/log directory. The trace_log will point to connection problem if any, as the following entry shows:
02/23/01 10:27 Error: sp_xport (sending data to OracleDev2) sp_xport: couldn't write data to socket
02/23/01 10:27 System call error: sp_xport (sending data to OracleDev2) Broken pipe Export write error
Resolution 4
1. Shutdown SharePlex on the target
2. qview -i
qview>qsetup <port>
qview>deleteq P -select the corrupted post queue
qview>exit
3. truncate table Shareplex_trans
4. restart shareplex
