Showing posts with label validation. Show all posts
Showing posts with label validation. Show all posts

Wednesday, March 21, 2012

Merge Replication Problems

I am having a heck of a time trying to get merge replication to work. I have two tables that consistently fail validation - even just rowcount after applying a snapshot that I created seconds before and at a time when there is no activity on the tables.

Is there a guide/info somewhere about how to troulbeshoot this? The tables are fairly straightforward (but 35,000 rows) and there are no filters set up. The remote database is connected over the internet and I was hoping to be able to get the two databases to synch continuously.

Also, when I create the merge agent, the wizard doesn't show the schedule option (i.e. whether to run continuously or on a schedule) and therefore I have to set the -continuous option on the merge agent manually.

I have been struggling with this for 2 weeks so any help/pointers would be most appreciated.

After more playing around, it appears that if I create a merge publication to a database that already has a continuous transactional subscription, I don't get the option to set the merge subscription to update the merge subscription continuously. I've now put all my tables into one big merge publication.... hopefully that will work.

Am I on the right track: in sql2000 is there some limitation that doesn't allow a continuous merge and a continuous transactional publication/subscription to and from the same publisher/subscriber database pair?

thanks....

|||

I don't know if this is the answer to my own question but: it appears that trying to get continuous merge and continuous transactional replication to coexist from the same publisher database to the same subscription database was my problem.

I have no idea why, nor whether this is documented somewhere, but now I have made all of my publications continuous merge (even though transactional would seem to be the reight choice for most of the tables) gets over all the problems I was having with the merge publications continually failing.

Can anyone confirm this? Or did I unknowingly stumble upon some other fix while reconfiguring all replication from scratch?

|||

if you want to do validation, you need to do it when activity on the subscriber and publisher are minimal, otherwise if changes are continuously happening on one end while validation is occuring, there's a chance you'll never be in sync.

If you stop the transactional replication, and stop all other changes, I bet your validation will pass.

Merge Replication Problems

I am having a heck of a time trying to get merge replication to work. I have two tables that consistently fail validation - even just rowcount after applying a snapshot that I created seconds before and at a time when there is no activity on the tables.

Is there a guide/info somewhere about how to troulbeshoot this? The tables are fairly straightforward (but 35,000 rows) and there are no filters set up. The remote database is connected over the internet and I was hoping to be able to get the two databases to synch continuously.

Also, when I create the merge agent, the wizard doesn't show the schedule option (i.e. whether to run continuously or on a schedule) and therefore I have to set the -continuous option on the merge agent manually.

I have been struggling with this for 2 weeks so any help/pointers would be most appreciated.

After more playing around, it appears that if I create a merge publication to a database that already has a continuous transactional subscription, I don't get the option to set the merge subscription to update the merge subscription continuously. I've now put all my tables into one big merge publication.... hopefully that will work.

Am I on the right track: in sql2000 is there some limitation that doesn't allow a continuous merge and a continuous transactional publication/subscription to and from the same publisher/subscriber database pair?

thanks....

|||

I don't know if this is the answer to my own question but: it appears that trying to get continuous merge and continuous transactional replication to coexist from the same publisher database to the same subscription database was my problem.

I have no idea why, nor whether this is documented somewhere, but now I have made all of my publications continuous merge (even though transactional would seem to be the reight choice for most of the tables) gets over all the problems I was having with the merge publications continually failing.

Can anyone confirm this? Or did I unknowingly stumble upon some other fix while reconfiguring all replication from scratch?

|||

if you want to do validation, you need to do it when activity on the subscriber and publisher are minimal, otherwise if changes are continuously happening on one end while validation is occuring, there's a chance you'll never be in sync.

If you stop the transactional replication, and stop all other changes, I bet your validation will pass.

Wednesday, March 7, 2012

merge replication data validation

After addition of new tables to Merge replication data validation fails
if i use only row count and checksum, however if i use binary checksum
and rowcount it is successful.
Checksum is notoriously unreliable. It looks like your tables are out of
sync. I suggest you reinitialize your subscriptions.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"mitsql" <amit.nimje@.tcs.com> wrote in message
news:1135762365.429312.266610@.o13g2000cwo.googlegr oups.com...
> After addition of new tables to Merge replication data validation fails
> if i use only row count and checksum, however if i use binary checksum
> and rowcount it is successful.
>
|||I have dropped and recreated the subsrciption. still gives the same
error.
All published tables have been recreated so there should not be any
difference in the tables..rt?
Also did a manual checksum using sp_table_validation for the table on
both
subsrciber and publisher and both return the same checksum..
Fail to understand how checksum fails and binary checksum successful?
Hilary Cotter wrote:[vbcol=seagreen]
> Checksum is notoriously unreliable. It looks like your tables are out of
> sync. I suggest you reinitialize your subscriptions.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "mitsql" <amit.nimje@.tcs.com> wrote in message
> news:1135762365.429312.266610@.o13g2000cwo.googlegr oups.com...
|||Hi,
Thankyou for the response. I even checked the table manually comparing
the
values row by row and found no difference.
Puzzled by this behaviour...
regds,
amit
|||I take it you have the same collation and there is no filtering involved.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"mitsql" <amit.nimje@.tcs.com> wrote in message
news:1135910034.397450.123480@.g43g2000cwa.googlegr oups.com...
> Hi,
> Thankyou for the response. I even checked the table manually comparing
> the
> values row by row and found no difference.
> Puzzled by this behaviour...
> regds,
> amit
>
|||Hence the comment that checksum validation wasn't always completely
accurate. I've run into this more than once. I've never been able to track
it down and I've never been able to reliably reproduce it.
That's why I look at the validation as a guideline. I still do random
samples of data and directly compare them externally. (This is a lot easier
than you might think.) I basically execute the same query against the
publisher and subscriber and yank all of the data into two tables. If the
rowcount is odd, I know I have a problem. If a union query yields exactly
1/2 of the total rows between the two tables, they are in synch.
Mike
Mentor
Solid Quality Learning
http://www.solidqualitylearning.com
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:u%235eYOgDGHA.2320@.TK2MSFTNGP11.phx.gbl...
>I take it you have the same collation and there is no filtering involved.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "mitsql" <amit.nimje@.tcs.com> wrote in message
> news:1135910034.397450.123480@.g43g2000cwa.googlegr oups.com...
>
|||thanks for respoding back..
Yes have the same collation and no filtering...
Can you tell me which is better binary checksum or checksum
validation?
And how this problem can be resolved for checksum validation failure?
any tracing ?