Hi Gethyn,

We run Checkdb within another action plan and if problems are reported we look at the database then.

I think you may be missing the point I am trying to help put across for Grasshopper to think about. Your last good backup may be from last night (in a good senerio) or you may not have one at all if your backup is not running because of a CheckDB detects an error and stops it running.

Consider the two senerios below

Good Senerio

This corruption may be one value in a record that is corrupted and easily fixed (as we have had). If you pick this up just before the next backup you could have lost a days worth of transactions fixing the corruption with a database restore from last night. (may be less if using transaction backups and you can find out when the corruption occured)

Bad Senerio

Your database, due to corruption, may be getting further corrupted until the point where it is unrecoverable. You have no backups because they have not run due to CheckDB stopping the backups running. Where do you restore from? You may only keep a couple of days backup for one reason or another or a low expiry (these are all options open to the DBA depending on his/her requirements).

The point I am making to think about is, if you have a corrupt database that will restore at least you have a fighting chance. If you have a corrupt database you can't get in to, no backup because it was stopped due to CheckDB and all good backups have expired/been overwriten/removed. Where do you go from here?

Al

🙂