My boss wanted to try the REPAIR_ALLOW_DATA_LOSS first before restoring from the backup and we tried that...it ran for 25 mins when I was instructed to kill it.
So he wants to try the last resort, that may fail, that will likely leave your database transactionally inconsistent, that will lose an unknown amount of data before the solution that will recover with an intact database at a known point in time?
Maybe point him at my corruption article, the part that says 'don't just run repair'...
There's a reason why I react 'No!No!No!' to people suggesting that. It should almost never be the first thing you try or the default action. Especially when you have as much damage as you have.
We're obviously going to go ahead and just restore from the backups, but I can't do anything until this rollback completes...it's taking forever and we don't need to worry about it anymore as we're going to blow away the DB with the recovery process, can i force this to stop somehow by restarting the services or will i still have to wait for the automatic checkdb to complete upon the service start up
There's no automatic CheckDB on startup.
If you want to restore, stop SQL, delete the database's files, restart SQL, start your restore.
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)SQL In The Wild
: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass