My guess is you've hit a known bug in 2000 SP4.

See my old blog post Why won't my log clear in SIMPLE recovery mode? SQL 2000 bug or very large...

I don't think it's been fixed yet.

If this is the only error, then repair won't cause any data loss, as the image that it references isn't linked into the table.

Is this a database that you've recently...

Look like you only lost two rows of table data. Restore your latest backup and checkout:

Page 1:18331 slot 85

Page 1:660206 slot 8

using DBCC PAGE. Looks like you've got some large...

If you post the output from repair, I'll tell you what was deleted. You can then use the list of pages that were deleted to look in an older backup...

You'll lose clustered index (table) rows too - CHECKDB can't delete just the broken LOB data, it will delete the entire row.

Glad you enjoyed the video - that's a fun session!

Hmm - yup, you can't do single-page restore on a SIMPLE mode database. Best bet may be to select all the...

ok, so it was the first value that is wrong - 50/50 chance until I saw the surrounding slots.

Yes - this is the direct cause of the error you posted....

That's a critical system table that you can't repair and you can't rebuild the index to fix this. Something corrupted the cluster key in the table - from the pattern...

You can make it go back as far as any still-existing LSN.

A log reader tool can't work without the actual database to get the table metadata, to make sense of what the log records describe.

Gail - the log file doesn't work...

Short, simple answer - no.

See TechEd Demo: Creating, detaching, re-attaching, and fixing a suspect database for complete instructions.

No, nothing to do with having too many VLFs or the size of your transaction log - it's your I/O subsystem. You just threw away the log and made it...

I've got to agree with you on this one. I joined the SQL team at MS in the late 90s at the height of the coolness, just after 7.0 shipped...