-
Title
Export not sending data and target shows "Import: Error add user queue rv=41 que_adduser" -
Description
Activating the new config in a Horizontal Partition environment results in the following errors on source and target and the Export queue does not send any data to the target:
Source event log:
Error 2016-09-12 13:55:59.279336 30074 668153696 Export: sp_xport: failed to send message to import - exiting (exporting to target_server.i.XYZ.com queue export_queue1) [module xpt]
Error 2016-09-12 13:55:59.272716 30074 668153696 Export: Connection reset by peer Export write error (exporting to target_server.i.XYZ.com queue export_queue1) [module xpt]
Target event log:
Info 2016-09-12 14:17:58.536494 9906 2457614176 Import launched, pid = 9906 (importing from source_server.i.XYZ.com queue export_queue1)
Info 2016-09-12 14:17:58.705610 9906 1025058656 Import connected to export on source_server.i.XYZ.com
Error 2016-09-12 14:17:58.709246 9906 1025058656 Import: Error add user queue rv=41 que_adduser(post_queue1+P+o.SOURCE_SID-o.TARGET_SID,+PI+export_queue1+sp_mport+0xnnnnnnnn) (importing from source_server.i.XYZ.com queue export_queue1) [module rim]
-
Cause
Export process from new activation is trying to send data to the named Post queues that existed due to previous activation and the Import is failing due to this with the error for the function que_adduser -
Resolution
Initially there was one Export queue for all partitions but for every partition condition there was a separate Post queue as shown below:
source_server:export_queue*target_server:post_queue1@o.target_SID
source_server:export_queue*target_server:post_queue2@o. target_SID
As a result the target had different Post queues getting data from one named Export queue. Later it was decided to create separate named Export queues for every partition condition and each of those Export queues had a corresponding named Post queues (which already existed from previous configuration) as shown below:source_server:export_queue1*target_server:post_queue1@o.target_SID
source_server:export_queue2*target_server:post_queue2@o. target_SID
However, activating the new config resulted in the following errors on source and target and the Export queue did not send any data to the target:
Source event log:
Error 2016-09-12 13:55:59.279336 30074 668153696 Export: sp_xport: failed to send message to import - exiting (exporting to target_server.i.XYZ.com queue export_queue1) [module xpt]
Error 2016-09-12 13:55:59.272716 30074 668153696 Export: Connection reset by peer Export write error (exporting to target_server.i.XYZ.com queue export_queue1) [module xpt]
Target event log:
Info 2016-09-12 14:17:58.536494 9906 2457614176 Import launched, pid = 9906 (importing from source_server.i.XYZ.com queue export_queue1)
Info 2016-09-12 14:17:58.705610 9906 1025058656 Import connected to export on source_server.i.XYZ.com
Error 2016-09-12 14:17:58.709246 9906 1025058656 Import: Error add user queue rv=41 que_adduser(post_queue1+P+o.SOURCE_SID-o.TARGET_SID,+PI+export_queue1+sp_mport+0xnnnnnnnn) (importing from source_server.i.XYZ.com queue export_queue1) [module rim]
To fix the problem
Shutdown Shareplex on target and delete all the existing named Post queues for that table by invoking the qview utility (located in /proddir/bin directory where proddir refers to SharePlex product directory):
qview –i
qview>qsetup
qview>list (this command will show all the queues including Post queues existing on target)
qview> deleteq post_queue1+P+o.SOURCE_SID-o.TARGET_SID
qview> deleteq post_queue2+P+o.SOURCE_SID-o.TARGET_SID
.
.
qview>exit
Then truncate the Shareplex internal table shareplex_trans and bounce Export on source. This will resolve the issue and new Post queues will spawn and the data will post to the target. If there is any data prior to running the qview command, this data will be lost. Though generally these issues occur when the data sent by previous queue Export queue has drained and the new one is not able to send fresh data to target and if so, there will not be any data loss. If not sure, check with Support prior to removing the queue.
Disclaimer: The qview commands need to be run with care and deleting the wrong queue can result in data loss. This also holds true for all Knowledgebase articles that involve running of qview. If in doubt, call Support so that you can be walked thru the process.