Wednesday, March 21, 2012

Merge replication problem

I have one corporate server that acts as both publisher and distributor.
Remote locations all have SQL server loaded and act as subscribers. This
setup has worked great until yesterday. Somehow, and it is still under
investigation, the corporate server "lost" all subscriptions and became
disconnected from the remote locations.
Each location is on a 5 minute schedule for the merge agent to run.
After recreating all the subscriptions and "pushing" them down to the remote
locations, there has been information lost during the down time. The
snapshot agent had to be run in order to recreate the subscriptions. I am
trying to figure out how I could have reconfigured the setup so that when
the subscription was made all the data in the remote locations would have
been preserved and "Merged" with the data from the server.
Thank you in advance for you input.
WB
Should this situation happen again I suggest:
1. Prevent further updates on remote stations until replication is re-setup
OR choose a time for the resync that least interferes with operations - the
longer you leave it the worse your problem becomes
2. Remove publication(s) and subscriptions
3. Use a tool like Red Gates "Data Compare" to see what data the publisher
is missing - it will generate the sql inserts for you, this sql may need to
be manually tweaked
4. Apply update scripts
5. Recreate publication(s) and subscriptions
6. Find the person who caused the problem and apply thumbscrews
Jim.
"WB" wrote:

> I have one corporate server that acts as both publisher and distributor.
> Remote locations all have SQL server loaded and act as subscribers. This
> setup has worked great until yesterday. Somehow, and it is still under
> investigation, the corporate server "lost" all subscriptions and became
> disconnected from the remote locations.
> Each location is on a 5 minute schedule for the merge agent to run.
> After recreating all the subscriptions and "pushing" them down to the remote
> locations, there has been information lost during the down time. The
> snapshot agent had to be run in order to recreate the subscriptions. I am
> trying to figure out how I could have reconfigured the setup so that when
> the subscription was made all the data in the remote locations would have
> been preserved and "Merged" with the data from the server.
> Thank you in advance for you input.
> WB
>
>
|||I don't know how successful I will be at applying the thumbscrews to myself,
as it appears to have happened on my watch. It appears that while trying to
create a new remote server (from the remote location) and then send down the
snapshot and merged replication data, that the SQL server at the main office
removed the subscriptions of all the remote locations. Not sure how the
subscriptions were removed or why SQL thought it needed to do that, but I
may never know....
I will definitely look into the data compare tool; that will probably come
in handy in the future.
"Jim Breffni" <JimBreffni@.discussions.microsoft.com> wrote in message
news:C3E8DA76-F717-4353-8E0B-FACDA058F3DB@.microsoft.com...
> Should this situation happen again I suggest:
> 1. Prevent further updates on remote stations until replication is
re-setup
> OR choose a time for the resync that least interferes with operations -
the
> longer you leave it the worse your problem becomes
> 2. Remove publication(s) and subscriptions
> 3. Use a tool like Red Gates "Data Compare" to see what data the
publisher
> is missing - it will generate the sql inserts for you, this sql may need
to[vbcol=seagreen]
> be manually tweaked
> 4. Apply update scripts
> 5. Recreate publication(s) and subscriptions
> 6. Find the person who caused the problem and apply thumbscrews
>
> Jim.
>
> "WB" wrote:
This[vbcol=seagreen]
remote[vbcol=seagreen]
am[vbcol=seagreen]
when[vbcol=seagreen]
have[vbcol=seagreen]

No comments:

Post a Comment