DBCC CheckTable has been running for 11 hrs

  • Hi -

    We had a raided harddrive go bad the other day after a 2 hr power outage and it caused misc io errors.

    We have been running dbcc checkdb on all the production dbs and have found errors in all of them (Mostly 8909, 8928, 8944 errors related to indexes).  We stepped through successfully repairing 2 of our smaller dbs all day yesterday.  All DBs have trans replication too. We have had to drop replication, put the db's into single user mode.  Some of the table errors we fixed by running dbcc checktable('xxx' repair_allow_data_loss) repeatedly, others, we have dropped non-clustered idxs, dropped clustered idxs, deleted records, rebuilt clustered idx, rebuilt non-clustered idx and then brought table back. 

    I have been running a dbcc checktable('xxx', repair_allow_data_loss') for the past 11 hrs on a table with ~184 Million rows.

    My question is "What happens if I cancel the query analyzer session running the dbcc checktable?"  Should it cancel quickly, or will it kick off some kind of rollback that will take as long or longer?

    We are thinking of switching to plan B and creater an alternate table

     

    Any input would be greatly appreciated-<CBC>

     

  • Wow.

    I had a CHECKDATABASE run on a 44G database for 10 hours.  I am now attempting a repair of the largest table (21 million rows) and I hope I don't lose another day doing it.

    I had to cancel the CHECKDATABASE job on the original database before we decided to restore from backup.  It cancels very quickly.

  • Thanks Steve -  we suspected that, but didn't have the courage to try yet.  Our largest table is 600 M rows.  the db in question is 0.5 TB.  We ran a checkdb on it yesterday and it took 6 hrs.

    Kindest-<CBC>

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply