August 18, 2005 at 5:09 pm
Hi there,
Is there a possibility of table being corrupted after running DBCC INDEXDEFRAG?
My company uses MS Merge Replication in replicating data across different cities.
Here's the merge replication model:
Site A: (merge replication)
- 4 servers - A1, A2, A3, A4
- A1 is the publisher
- A2, A3, A4 subscribe to A1
Site B: (merge replication)
- 3 servers - B1, B2, B3
- B1 is the publisher for site B.
- B1 also subscribes to A1, in order to get Site A's data.
- B2 and B3 subscribe to B1
DBCC INDEXDEFRAG is scheduled to run on all the servers at 4:30AM on a daily basis.
About 3 weeks ago, there was some index corruptions on Server B2, a day or two later, there was a table corruption on A2.
Couple days ago, there was a table corruption on A1, and then today we discovered a table corruption on A3.
What's weird is the table corruptions all happened on the same table in one particular database. This table is a binary table, and it is the only binary table in the database.
The index corruptions that happened on server B2 was on this binary table as well.
Anybody has any comment?
Thanks,
baes
August 22, 2005 at 8:00 am
This was removed by the editor as SPAM
August 24, 2005 at 3:11 am
As far as I am aware, changes made by the INDEXDEFRAG should not be replicated (there doesn't appear to be any structure within the mSMerge_ tables to store this kind of information).
What is more likely to have happened is that something in the data went awry on B2 that was "merged" back to A1 and then onto A2 and A3.
Depending on the paritioning/filtering you have applied to the merge replication scenario for any given server/subscriber combination, and then compare the timings of when the merge occurs in relation to the INDEXDEFRAG might provide clues as to why A2 was affected before A1.
Lastly, as far as I am aware, there are no issues with replicating binary data.
Regards,
Mark
August 25, 2005 at 10:57 am
Thank you Mark!
August 25, 2005 at 12:48 pm
In the past when I have had errors when running dbcc checkdb, they seemed to be related to pending disk i/o problems. You might look at the hardware and see if there is a problem.
Tom
August 29, 2005 at 3:42 pm
Hi Tom,
Thanks for the suggestion. In this case, I don't think it's disk I/O related, since it affected the same table in the same database in 4 servers at different times, and the only difference this table is from the rest of the database is that it's a binary table.
Thanks,
baes
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply