Is there actually an easy way to check the output from DBCC CHECKDB?I currently scan the SQL log using xp_readerrorlog for the DBCC output info, another way is to use TABLERESULTS clause, and check for the completion line.However, both methods could be called undocumented - you won't find either in BOL!

I recently talked my boss into getting a drive big enough to restore all of our DBs so we can pull them from tape and do tests on a few each week. Now just comes the job of automating that which is likely to be very fun. It would also appear that we need to do some work to secure our backups a little better.

charles.wong (9/24/2012)Great article.

Is it possible to use DBCC CHECKDB to check the database first before backing up (with all your other recommendations), so that we don't have to restore the backup to perform that test?

You can run CHECKDB first but there's no guarantee that the DB doesn't get corrupt before the backup is done. It also won't guarantee that the backup file itself doesn't get corrupted. Some people recommend doing an integrity check and if the DB is corrupt not to back it up (assuming that this means you may be deleting the last good backup.) Our process here is to backup the database since we send the backups to another location so we shouldn't be destroying a good backup. It also means that we have a copy of the corrupt DB so if we need to restore we can then do some comparisons to try and recover some of the changes. The thing you need to be careful of is making sure you're not destroying the last good backup because then you have a problem.

Some of the questions:1) If you can run CHECKDB on the prod system, go for it. But also do the backup/copy/restore/CHECKDB process too. Defense in depth - just like with security.2) Did CHECKDB complete and find errors? Check the value of @@ERROR afterwards - guarantees to be non-zero if CHECKDB found/had a problem.