Cool (- that you found the problem).

As far as DR to avoid this, there isn't any way to circumvent a bug like this. It'll be in your transaction log backups...

You've got corruption in the sysindexes table in the 2000 database. As part of the upgrade to 2005, all the system tables are changed and the old ones deleted. My...

Yes, if the situation applies then this could be it. I didn't know about this problem - nice 🙁

Ah - from the error messages, you're on SQL 2000, not 2005, right? Note that there's a separate forum for 7.0/2000 problems.

Looks like you may be hitting this bug -...

Best way to recover with no data loss is always to use backups, log backups, and a final tail-of-the-log backup. You said that you couldn't use your backups because too...

Shripad - horrible advice as you describe it. You're missing the warning about the effects of rebuilding the log (i.e. causing more corruption) and that you should run a checkdb...

Gail pinged me to take a look - I'm busy at SQL Connections this week so haven't been watching the forums.

Unfortunately your database is toast. The sysobjects error from running...

There's no way to tell SQL Server to automatically run DBCC CHECKDB - so there *has* to be an Agent job or other connection that's running it.

Your other problem sounds...

Well, not back to normal. You can try DBCC REBUILD_LOG and then DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS - that might make the database be usable again but some data will be...

ok - you need to statr the process again and follow the steps exactly - i.e. same size files etc. I haven't tested this using different steps so I can't...

Is there any activity in the database? I mean is CHECKDB actually doing anything?

Check whether any I/Os are happening. Also, look at the percent_complete column of sys.dm_exec_requests for the DBCC...

Hi,

Welcome to SQLServerCentral! Usually creating a new thread is the way to go, but no big deal.

Well, unfortunately you've done the worst thing you could do by detaching the database....

These errors shouldn't take that long to repair on a small database like yours. To confirm, you're saying that CHECKDB has been running for 3 days without completing?

The fact that this was running normally and then failde means that your database has corruption in it.

What's the output of DBCC CHECKDB (srvepsqldb01) WITH ALL_ERRORMSGS, NO_INFOMSGS?

Can you post the results of the following command please:

DBCC CHECKDB (yourdbname) WITH ALL_ERRORMSGS, NO_INFOMSGS

It shouldn't take 3 days to run on a 4-GB database unless there's something very badly...