jwbrown65 (12/3/2008)

---

2nd pass took 4 hours, 1st was 3.5.

Delighted to find that the 30 remaining consistency errors were found and fixed on the 2nd pass.

We seem to be operable again.

Thanks...

oh - ok then - Gail was right. The data in those fields looked so strange that it looked corrupt to me - being infinitesimally small rather than zero.

So -...

It could be one of two things:

1) some corruptions prevent CHECKDB from being able to check all parts of a structure, so when they're fixed CHECKDB may discover new corruptions

2)...

Note that this is a 2005 specific forum - there is a 7.0+2000 forum (and you're running SQL 2000 - from the DBCC output) - not a big deal but...

Oh go on, be brave Gail! 😉

You can query the system catalogs using the DAC to figure out which of the object IDs referenced in the error messages are for...

This is saying that a bunch of foreign key constraints *partially* exist in the system catalogs.

Was the database upgraded from 2000? When was the last time DBCC CHECKDB ran without...

Hmm - I don't think the corruption was in the nonclustered indexes - I think the corruption was (and still is) in the base table itself. All the "missing" NC...

Nope - but that's the name of the table where the corruption happened.

Do you have backups?

PS You're in India - which is PST + 12.5 - I'm heading to bed...

Yes- if this is a 2000 database (guessing so because of the forum you posted in):

DBCC TRACEON (3604) -- just directs the DBCC PAGE output to the current connection

GO

DBCC PAGE...

And this is a 2005 error message - be aware that this is a 7.0 + 2000 specific forum - there's a 2005 corruption forum too.

The updateusage issue is documented...

Depends on the consistency error - can you post the actual error message too?

Consistency errors are corruption in the database - nearly always caused by the I/O subsystem.

To recover without...

And if you want to know exactly what it does, see http://www.sqlskills.com/BLOGS/PAUL/post/CHECKDB-From-Every-Angle-Complete-description-of-all-CHECKDB-stages.aspx

No - if you change table names, you need to redefine your SPs. You shouldn't change the system tables manually to do this. There are various tools that you can...

With alter index rebuild? Hmm.

Maybe try create index with drop_existing?

Worst case, install CU9 to fix the issue, but then you've got test issues.

Yup - that's what I expected. If you restore all the way up to current and then rebuild the index with ALTER INDEX REBUILD you should be ok.