| Tags: Manually, dropping, subscription, from, rs subscriptions, |
|
Manually dropping subscription from rs_subscriptions
|
|
01-19-2010, 05:22 PM
Post: #1
|
|||
|
|||
|
Manually dropping subscription from rs_subscriptions
I'm testing replication from ASE --> IQ using rep server on a test machine.
Anyway, I had a problem dropping a subscription so I manually deleted the entry from rs_subscriptions delete rs_subscriptions where subname = 'sub_test1' I was then able to drop the replication definition from repserver using the drop command. :-( However, now the log is filled with the following error: E. 2010/01/19 11:44:05. ERROR #32059 DSI EXEC(104(1) RAPStore.dr) - /nrm/nrm.c(556) Invalid object identifier for table or function 'repdef_test1'. id = 0x0100006500000067. E. 2010/01/19 11:44:05. ERROR #5204 DSI EXEC(104(1) RAPStore.dr) - /dsiutil.c(3655) Error from unpacker or parser. See previous message for more information. DSI will retry. E. 2010/01/19 11:46:05. ERROR #32059 DSI EXEC(104(1) RAPStore.dr) - /nrm/nrm.c(556) Invalid object identifier for table or function 'repdef_test1'. id = 0x0100006500000067. E. 2010/01/19 11:46:05. ERROR #5204 DSI EXEC(104(1) RAPStore.dr) - /dsiutil.c(3655) Error from unpacker or parser. See previous message for more information. DSI will retry. E. 2010/01/19 11:48:06. ERROR #32059 DSI EXEC(104(1) RAPStore.dr) - /nrm/nrm.c(556) Invalid object identifier for table or function 'repdef_test1'. id = 0x0100006500000067. E. 2010/01/19 11:48:06. ERROR #5204 DSI EXEC(104(1) RAPStore.dr) - /dsiutil.c(3655) Error from unpacker or parser. See previous message for more information. DSI will retry. Any ideas how to fix or clean this up again? Has anyone seen this before? |
|||
|
01-19-2010, 07:51 PM
Post: #2
|
|||
|
|||
|
RE: Manually dropping subscription from rs_subscriptions
Hi,
I am looking for following input from your side : 1. What was the error message which you were getting during drop sub? 2. Do you the subcription ddl which will help us to understand the rep def , table coloumn subcribed and materialization method? Alos the corresponding rep def ddl? Thanks. Regards, AnVa http://sybaseblog.com TechSupport-SeniorMember Synergy Project (SybaseTeam.Com) |
|||
|
01-19-2010, 08:21 PM
Post: #3
|
|||
|
|||
|
RE: Manually dropping subscription from rs_subscriptions
Also please try the below.This may help.
select * from rs_subscriptions where objid=0x0100006500000067 delete this entry if it is linked to other server. Please try and let us know. JP, TechSupport-Member(SybaseTeam.Com) |
|||
|
01-20-2010, 12:19 PM
Post: #4
|
|||
|
|||
|
Hi Asif,
Have you tried the Joshi's suggestions? Is it worked for u? As per my findings, If you look into the rs_subscription table in RSSD database, it has lot of dependent tables on it. So deleting the row from rs_subscription is not the solution for the same, it requires the proper understanding of create sub command , means which tables it updates during create sub command. Even Sybase also doesn't recommend the manually delete from the system table, if you don't have proper understanding. It will leave the db in inconsistent state. Its best dba practice. My suggestion is, if you have the backup of this table, please bcp in all the rows and try to remove the error whatever you were getting during drop sub earlier, then go for the drop sub finally. If you still have any issues, please let us know and also provide the earlier mentioned details. Thanks. Regards, AnVa http://sybaseblog.com TechSupport-SeniorMember Synergy Project (SybaseTeam.Com) |
|||
|
01-20-2010, 04:28 PM
Post: #5
|
|||
|
|||
|
RE: Manually dropping subscription from rs_subscriptions
Thanks for the response guys. I tried the suggestions above.
It appears that this error is a known bug in RS 15.5 I dont have any backups, but I have the 'go ahead' to trash the rssd and start again.......any ideas how to do this? |
|||
|
01-20-2010, 10:14 PM
Post: #6
|
|||
|
|||
RE: Manually dropping subscription from rs_subscriptions
(01-20-2010 04:28 PM)asifm Wrote: Thanks for the response guys. I tried the suggestions above. sorry guys, i've now resolved this. There was a (de)materialization queue hanging in the system and I simply dropped it with sysadmin drop_queue queue number, queue type I then had to clean up the stable queues with sysadmin sqm_purge_queue queue number, queue_type Finally, I quiesced the replication system and retstarted the server, problem solved! I'm not sure if this is a bug with RS 15.5, I have to verify this.....thanks guys! |
|||
|
« Next Oldest | Next Newest »
|


Chat Support
Search
Disclaimer & Rules
Help


