Can you run the following command and post the output? You may have corruption.

DBCC CHECKDB (yourdbname) WITH ALL_ERRORMSGS, NO_INFOMSGS

Thanks

Which is exactly the advice given in a post further up... although its great that you're posting advice, it would be more useful to post on threads that haven't *already*...

Waste of time - I already time him where the corruption is - in one of the critical system tables, that he can't do anything about. I wrote that error...

varun_3g (2/4/2009)

---

If you have just one .mdf file you can use sp_attach_single_file and just use the one .mdf fille which will built your .ldf file. If you have multiple .mdf...

In addition to what Gail said, what you're really asking is whether there's a way to fix these corruptions without losing data using DBCC - the answer is no. The...

(I guess this post puts me over 1000 points - wooo!)

You've got corruption in one page at the leaf-level of the clustered index for that table. Running repair will cause...

Yup - you're screwed. Without a backup to restore from, repair is your only option. If REPAIR_ALLOW_DATA_LOSS doesn't fix everything (it's not able to fix all corruptions) then your only...

You have corruption in that table in your database - most likely caused by IO subsystem problems. You have a number of choices to recover from this:

1) restore from a...

Yup - CHECKDB can't get past this. If you don't have a backup, you'll need to extract out to a new database (plus do root cause analysis).

ok - so somehow in the sequence of what they did, they've disconnected the files from the database - a guess would be that a transaction that was involved in...

Do they have the database attached? If not, and the secondary files are missing, are they in the primary filegroup or a secondary filegroup? If in the primary filegroup then...

You're most welcome.

Try the WITH PHYSICAL_ONLY option. You can also see how much tempdb space will be necessary using the WITH ESTIMATEONLY option.

You might also find this useful - http://www.sqlskills.com/BLOGS/PAUL/post/CHECKDB-From-Every-Angle-Consistency-Checking-Options-for-a-VLDB.aspx

Almost impossible to completely avoid corruption due to the complexity of the I/O subsystem. Best thing you can do is limit the chance for it happening and be able to...

ok - but you've got something going wrong in the IO subsystem that you need to fix - so next time it happens the corruption isn't permanent and debilitating.

See http://www.sqlskills.com/BLOGS/PAUL/post/Conference-corruption-demo-scripts-and-example-corrupt-databases.aspx for a bunch of pre-corrupted databases.

Also see http://www.sqlskills.com/BLOGS/PAUL/post/Example-20002005-corrupt-databases-and-some-more-info-on-backup-restore-page-checksums-and-IO-errors.aspx