Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The controllers on one of my cluster's SAN's are periodically restarting themselves. Apparently it can be fixed by a firmware update, but until we can apply the update in a few days, I have to live with the issue. The problem is, if one of them fails while DBCC CHECKDB is running (during nightly maintenance), CHECKDB hangs. I can't seem to kill shows that it's waiting on ASYNC_IO_COMPLETION forever. Do I need to cycle the instance, or is there another way to kill CHECKDB?

SQL Server 2005 RTM & SP2 instances.

share|improve this question
up vote 2 down vote accepted

Ok - this is proper behavior. What's happening is that you've killed DBCC CHECKDB while it's still creating the database snapshot it needs. Part of creating the snapshot is running crash recovery on the database being checked, but into the context of the database snapshot. Crash recovery cannot be stopped, and a spid that's running it cannot be killed. So - your only options are to wait for it to finish, or cycle the instance - which will drop the snapshot. When I changed CHECKDB to use database snapshots we knew this would be a potential issue, but there was no alternative.

Check out this blog post where I explain a bit more: Do transactions rollback when DBCC CHECKDB runs?


share|improve this answer

When you say you can't seem to kill it, are you trying to cancel the job? Or are you killing the SPID from activity monitor?

share|improve this answer
Thanks, Brad. I should have been more specific. Had tried my spid is stuck in the KILLED/ROLLBACK state. – Aaron Alton Aug 24 '09 at 18:21
Are the CPU and IO on the SPID still advancing? If so, then all you can do is wait until the rollback completes. If not, then the spid might be actually hung, and you'd have to restart the SQL instance to get rid of it. DON'T restart SQL unless you're sure its not still active in rolling back, or the database will stay in "recovering" mode (and inaccessable) until the rollback is complete. – BradC Aug 24 '09 at 18:36
CPU > 0; Physical IO > 0. Wait time is increasing, but that's it. – Aaron Alton Aug 24 '09 at 18:49
So if CPU and IO aren't still moving, then you probably need to restart SQL. I'd probably want to restart the server entirely after a SAN blip, anyway, but that's just me. – BradC Aug 24 '09 at 19:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.