I repeat the phrase “If you aren’t monitoring it, you can’t measure it” all the time. Through my IT career, this has been a constant. If you don’t have a baseline or know what normal looks like, then how can you quantify what isn’t normal when a user starts complaining of performance issues.
For SQL Server there are lots of easy things that you can do to be more proactive for knowing when something isn’t going well on your server.
For one, you should setup alerts. Built-in to SQL Server is the ability to setup SQL Agent Alerts. Enabling SQL Agent Alerts for certain severity level errors can let you know immediately when that condition is met.
SQL Server logs can contain a wealth of information. Reviewing the SQL Server logs for any errors or problems should be a normal process during any troubleshooting session, however there are numerous tools out there than can scan logs for keywords, such as ERROR to proactively let you know when issues are occurring.
Having a baseline is critical to knowing how things look when performance is normal. There are several good 3rd party tools out there that can monitor your environment and capture your baselines as well as alert when certain events or metrics are met. I love having a professional monitoring solutions in place, but those come with a cost. It is very possible to capture key metrics yourself such as page life expectancy, cpu utilization, disk I/O, database file sizes, wait statistics, and more. If you’d like more details on how to capture these yourself, I blogged about that a few years ago here.
In conclusion, make sure you are capturing proper metrics to have a baseline to know what ‘normal’ looks like, so that when users are complaining about slowness, you have something to compare the current state against what normal should look like.
The post Why Aren’t You Monitoring SQL Server appeared first on Tim Radney.