Loose all data from tables
in [Replication]
|
Prev: move backward in transaction log with usage of sp_repldone
Next: error "Unexpected EOF encountered in BCP data-file" when initializ
From: Adam Simpson on 21 Sep 2009 11:42 I am still getting this problem every so often. There are some records in the msmere_tombstone table on the distributor but only 400. This time every record in every table was deleted and this was for one subscriber only, and not the same subscriber as before. This subscriber had been using the database for at least 2 months since they had the problem last, And before that I the database had been funning for 2 years without problem. Any pointers would be gratefully looked into. Thanks Adam "Adam Simpson" <adam(a)ccsys.co.uk> wrote in message news:OcvYxD9KKHA.1488(a)TK2MSFTNGP03.phx.gbl... > Thanks Paul > I am not on site for the next couple of days but will look into it and > post any findings when I get back. > > Regards > Adam > > > > "Paul Ibison" <Paul.Ibison(a)ReplicationAnswers.Com.(donotspam)> wrote in > message news:4DF612E8-440F-43A4-B68F-7DC1C3947083(a)microsoft.com... >> If there are no relevant filters and conflicts, then this is really >> strange. >> It looks like the rows are removed without firing the replication delete >> triggers on this particular subscriber which would be a manual process. I >> say >> this because they'd be also removed from the other nodes if it was a >> normal >> delete. You could verify this by checking in msmerge_tombstone for the >> guids >> of these particular rows - there should be corresponding records when the >> rows are removed and if these records don't exist then I'd suspect that >> the >> trigger has been disabled. If it occurs at the same time, then I'd look >> at >> running a profiler trace to keep an eye on it. >> HTH, >> Paul Ibison >> >> >> >> "Adam Simpson" wrote: >> >>> Thanks for getting back Paul. >>> >>> I am not using any filtering >>> >>> The Resolve conflicts interactively is set to false on each subscriber. >>> Looking at the system tables in the database there are a few records in >>> some >>> of the conflict tables, but not all the tables where the records were >>> removed have conflict records. >>> >>> Is there anything particulay I should be looking for. >>> >>> Thanks Adam >>> >>> >>> "Paul Ibison" <Paul.Ibison(a)ReplicationAnswers.Com.(donotspam)> wrote in >>> message news:E153A6BC-FCD9-4551-99CF-04709C8DD290(a)microsoft.com... >>> > Are you using some filters (dynamic)? >>> > Also, do you have evudence of conflicts? >>> > Thanks, >>> > Paul Ibison >>> > >>> >>> >>> > >
From: Paul Ibison on 24 Sep 2009 04:29 OK - like before I assume there are no filters or conflicts recorded? What about the merge agent history - do you see the deletes recorded there? If there have been many deletes but far less records in msmerge_tombstone then check the default trace for anyone disabling the triggers - not sure this is recirded there but worth a look. I'd have a server-side trace running to capture anything relevant on all the subscribers to aid in diagnosing this next time if you can't determine the cause this time. HTH, Paul Ibison
From: Adam Simpson on 24 Sep 2009 06:18 Paul There are no filters set in the publication. and only a few records in the conflict tables. I am not sure how to look at the merg agent history, but if it is the MSmerge _history tables, there is nothing in the database MSmerge _history table table and the distribution MSmerge _history table only goes back 4 days so I have missed that. I have found in the Distribution MSrepl_errors table the following errors around the time of the data loss and after: -2147201016 - The merge process could not retrieve column information for table 'dbo.Clients'. Verify that you have sufficient privileges on the database and retry the operation. 2812 - Could not find stored procedure 'dbo.MSmerge_sel_sp_1B8500762F6346EB39128FA469BA4996'. 20671 - Cannot find the identity range allocation entry for the Subscriber in the MSmerge_identity_range table. Reinitialize the subscription. -2147201001 - The schema script '' could not be propagated to the subscriber. -2147201001 - The schema script 'Budget_25.prc' could not be propagated to the subscriber. I have not looked into the default trace before so I am not too sure what I am looking for. Virtually every entry starts with "MSmerge_" and I can't find any entries with a user login. Though I'm not sure this goes back far enough, only 4 days. How do you create a server-side trace for the subscribers? Thank you for your help Adam "Paul Ibison" <Paul.Ibison(a)ReplicationAnswers.Com.(donotspam)> wrote in message news:A0F751A9-BA5A-429D-9CA3-C6AC0220822D(a)microsoft.com... > OK - like before I assume there are no filters or conflicts recorded? What > about the merge agent history - do you see the deletes recorded there? If > there have been many deletes but far less records in msmerge_tombstone > then check the default trace for anyone disabling the triggers - not sure > this is recirded there but worth a look. I'd have a server-side trace > running to capture anything relevant on all the subscribers to aid in > diagnosing this next time if you can't determine the cause this time. > HTH, > Paul Ibison
From: Paul Ibison on 25 Sep 2009 16:21
I'd do some verbose logging (see here http://support.microsoft.com/?id=312292). and I'd probably also open a support case with MS. This is not a normal error and might be related to network authentication issues but it is difficult to understand. There is a circumstance in which non-convergence occurs due to security issues (http://consultingblogs.emc.com/jamesrowlandjones/archive/2009/06/05/merge-replication-resolving-the-permissions-bitmask-in-merge-security.aspx) which might be relevant - worth a look. Even so I'd probably open a support case. HTH, Paul Ibison |