SQL Server Needs Built-In Health Check Views

Goes To The Runner

Just like SQL Server needs centralized performance views, SQL Server needs easy views into health data.

Right now, there’s too much spread around too many different places to be helpful to people.

You ever try to assemble a backup report? Worse, what about things you don’t know about?

I seem to catch people weekly with the wrong type of page verification across a bunch of databases.

You shouldn’t need special scripts to figure out when you last ran DBCC CHECKDB.

What Should They Cover?

In a centralized schema, maybe called health (or something else that would stick out to end users — not just an ocean of “sys” views):

• Backups (schedule, failures)
• CHECKDB (last good, failures)
• Agent Job Failures/Operators Notified
• Bad Settings or configurations (like shrinking or auto close)
• Server Events, like restarts, memory dumps, high severity errors, etc.

That’s a pretty good start. It won’t replace All Your Favorite Scripts™, but it’ll help a lot of people out who just don’t know where to start.

Thanks for reading!

Going Further

If this is the kind of SQL Server stuff you love learning about, you’ll love my training. I’m offering a 75% discount to my blog readers if you click from here. I’m also available for consulting if you just don’t have time for that and need to solve performance problems quickly.