Stories from the HealthCheck – part 2

This week I am highlighting the top items that I see on almost every SQL Server I run across that need to be changed in almost every instance.

Number 2:


I’ll give you a little leeway on this one, despite how rampant it is. I get that many of you have never heard of database corruption.

Its a thing.

Its a bad thing

Its a potential data-loss thing! (that got your attention, yeah?)

If your database(s) get corrupted, Microsoft’s standard answer is to restore from your last non-corrupt backup (see yesterday’s post).

Things you should be doing:

  • Set your Page Verification level to Checksum
  • Set up a recurring job to run DBCC CheckDB against ALL of your databases (SQL has built in tools for this, or use Ola Hallengren’s FREE scripts)
  • Turn on alerts for Errors 823, 824, and 825
    • Make sure an email goes to someone that knows how to respond to these errors

Corruption can come from a number of places.

  • Storage subsystem – common
  • Bad versions of SQL Server – less common – patch your servers.
  • Funky Code situations – much less common
  • Other – no, I’m not going to list every possible option, lol

If you do all this and then get that dreaded email or alert from your monitoring tools – read this article before you do anything else.

Now go Check your CheckDBs.  Now.  Go.

Thanks for reading!


Leave a Comment

Sign up for our Newsletter

%d bloggers like this: