SQL table corrupt

[BoydMT]

My backup software for a SQL7 database is failing with the following message:
Table Corrupt: Object ID 734690461, Index ID 2. Keys out of order on page (1:78526), slots 145 and 146.

How can I determine what table is actually corrupt?
I am thinking about running DBCC CHECKDB. Can this cause potential problems?

Any suggestions are greatly appreciated.

Thanks,
Mark

 

[RobertT687]

To find out the object name try:
use yourdbname
go
Select name from sysobjects where id = 734690461
go

 

[BoydMT]

Thanks Robert.
This returned table 'MSmerge_contents'.
Have you ever dealt with table corruption in a system table like this? If so, any suggestions as to a possible solution?

Mark

 

[RobertT687]

I don't recognize that name as a system table. At least it isn't present in any of my SQL7 databases.

I've never run into table corruption, and I've been working with MSSQL since version 6.0.

Part of my nightly (or at least weekly) maintenance is to run DBCC CHECKTABLE on all my database tables.

Also, this is straight out of Books On Line for SQL 7.0

DBCC CHECKDB is the safest repair statement because it identifies and repairs the widest possible errors. If only allocation errors are reported for a database, execute DBCC CHECKALLOC with a repair option to repair these errors. However, to ensure that all errors, including allocation errors, are properly repaired, execute DBCC CHECKDB with a repair option rather than DBCC CHECKALLOC with a repair option.

DBCC CHECKDB validates the integrity of everything in a database. There is no need to run DBCC CHECKALLOC or DBCC CHECKTABLE if DBCC CHECKDB either is currently or has been recently executed.

I don't have any discomfort level running the DBCC utilities. The only effect is to slow down users, so try running it off hours.

 

[Corran007]

ms_mergecontents relates to replication. I believe it exists on the distributor only, but im not 100%. I would try his solution first. If that doesnt work, you could possibly try disabling replication for that database. I believe it will remove it when it no longer needs them for replication, but am not 100% sure.

 

[BoydMT]

Thanks for the input.
Yes, this database is a distributor for replication.
I think i'll wait til the end of the business day, and run DBCC CHECKDB. Hopefully this will resolve it. Otherwise, I will try disabling, then re-enabling the replication.

Thanks again,
Mark

 

[SQLBill]

From the error message it looks like it's an INDEX on that table that has the problem, not the table itself.

You might try rebuilding the index.

Table Corrupt: Object ID 734690461, Index ID 2. Keys out of order on page (1:78526), slots 145 and 146.


-SQLBill

 

[BoydMT]

Bill -
I thought of this, but was concerned that it may cause even more of a problem.
Maybe I'll give it a shot if DBCC CHECKDB doesn't help.

Thanks,
Mark

 

[Bensta]

I am having this error everytime a backup system file is run, which happens on a daily basis.
The error reads: " Consistency Checking DatabaseName
Consistency check excluding Indexes.
There was a problem running the DBCC.
SQL Server returned the following error message:
Table Corrupt: Object ID 261575970 (object 'TableName')does not match between 'SYSREFERENCES' and 'SYSCOLUMNS.'.
Is there any way around this error?
I would appreciate any help. Thank you in advance

 

[BoydMT]

Bensta -
I use Veritas Backup Exec to back up my SQL Server. In order for the backup to complete successfully, I had to uncheck the options 'Consistency Check Before Backup' and 'Consistency Check After Backup'. This should backup your data without a problem, but you do want to eventually resolve the error you're receiving.

Mark