That would be my gut feel too, but no way to tell. With lots of NC index corruption or a really crappy IO subsystem, or an...

Ha - CHECKDB From Every Angle: How long will CHECKDB take to run?

CHECKDB will tell you the option to use - most likely REPAIR_ALLOW_DATA_LOSS.

Run DBCC CHECKDB - it's the only thing that will tell you how corrupt your database is. And start taking backups - so you don't lose data when corruption occurs,...

There's no easy way to find which page has a certain row on it. You can look with DBCC IND to see all pages allocated to a table, or in...

From what I've seen, that should do it - hopefully!

Gail asked me to chime in. There are two options here:

1) the page that was identified as corrupt is...

And of course, you could restore from your backups. Do you have backups?

Gail asked me to comment on this.

Yup - you've got corruption. On 2005 there's a documented way to check for this - DBCC CHECKDB ... WITH DATA_PURITY, but there's no...

She should be able to reinstall the resource database from the install media - it's a non-changing database.

Thanks

No problem - 'thanks' is enough.

SP3 will also resolve the problem and fix a whole bunch of other bugs. As with any upgrade, make sure you test it before putting it into production - just...

Btw - REPAIR_FAST doesn't do anything in SQL 2005 onwards. I removed the code when I rewrote DBCC CHECKDB and left the option in for backwards compatibility reasons.

No - never run repair without first getting the list of corruptions and deciding on a course of action to take.

Ok - first problems is that you're running vanilla SP2, which has a bunch of bugs in maintenance plans. From the output you've sent, you're hitting the one where it...

Got 'em.