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: these days I have AI do the annoying stuff for me. My new video course teaches you to work the same way, and I teach whole teams in a one-day workshop. Someone still has to know enough SQL Server to keep the robots in check, and that’s what my training is for.