Saturday, February 25, 2012

Merge replication data loss

I have serious problem regarding merge replication. After couple of pull
subscription synchronizations, data loss occurred in several tables (both
publisher and subscriber databases).
Publication has 62 articles, but only few are affected. Agents reports several
errors (including really nasty "general network failure").
I think problem is not in dynamic or join filters, because some of those
tables are not filtered at all.
Example: with tables T1 and T2 (FK constraint) users confirmed data loss in
child table T2 "right after synchronization" (sometimes couple of hundreds of
records).
So, question is how this could possibly happen (FK constraint maybe or general
network failure)?
Any help is appreciated,
Tom
general network error means your network hic cupped.
Merge replication refreshes the data on the subscriber when you send the
snapshot. This could account for the data loss. Also check the conflict
viewer to see if there is a record of conflicts which also might account for
it.
Make sure if you have any cascading deletes that they are disabled on the
subscriber.
"Tom" <tomislav.hrvoic.rimuv.dis@.inet.hr> wrote in message
news:uM5NnqIGEHA.4084@.TK2MSFTNGP11.phx.gbl...
> I have serious problem regarding merge replication. After couple of pull
> subscription synchronizations, data loss occurred in several tables (both
> publisher and subscriber databases).
> Publication has 62 articles, but only few are affected. Agents reports
several
> errors (including really nasty "general network failure").
> I think problem is not in dynamic or join filters, because some of those
> tables are not filtered at all.
> Example: with tables T1 and T2 (FK constraint) users confirmed data loss
in
> child table T2 "right after synchronization" (sometimes couple of hundreds
of
> records).
> So, question is how this could possibly happen (FK constraint maybe or
general
> network failure)?
> Any help is appreciated,
> Tom
>
>
|||what type of connectivity you are using?
those records might be on the publisher, you just need to
update the child records and replicate them to subscriber.

>--Original Message--
>general network error means your network hic cupped.
>Merge replication refreshes the data on the subscriber
when you send the
>snapshot. This could account for the data loss. Also
check the conflict
>viewer to see if there is a record of conflicts which
also might account for
>it.
>Make sure if you have any cascading deletes that they are
disabled on the
>subscriber.
>"Tom" <tomislav.hrvoic.rimuv.dis@.inet.hr> wrote in message
>news:uM5NnqIGEHA.4084@.TK2MSFTNGP11.phx.gbl...
After couple of pull
several tables (both
Agents reports
>several
failure").
because some of those
confirmed data loss
>in
couple of hundreds
>of
constraint maybe or
>general
>
>.
>
|||"Kiran" <anonymous@.discussions.microsoft.com> wrote in message
news:175be01c418c4$e0f0f180$a301280a@.phx.gbl...
> what type of connectivity you are using?
Subscribers use 56K modem or ISDN adapter to dial-in to company domain.
Network protocol is TCP/IP, DNS works fine, I did notice some lost packets
when pinging publisher from subsribers. However, that was before system
administrators replaced dial-in server and reconfigured network (replication
data loss problem is still unsolved though).

> those records might be on the publisher, you just need to
> update the child records and replicate them to subscriber.
Nope, older database backup is the only place where I can find those
records. Publisher is also missing those records and that makes it very
tricky.
Regards,
Tom

No comments:

Post a Comment