SentryOne Team Blog (blogs.sentryone.com)

T-SQL Tuesday #66 : Monitoring

T-SQL Tuesday

This month’s T-SQL Tuesday is hosted by Catherine Wilhelmsen (b|t), and is on a topic near and dear to my heart: Monitoring!

It would be very easy to write a long post on the topic of monitoring in general, and talk about all the reasons you should choose the SQL Sentry platform, but I am not going to do that. Instead, I want to touch on a subject that I believe beneficial to everyone, no matter what you choose as your monitoring solution.

I hope we can all agree that monitoring is important. Consistent, effective monitoring of your data environment provides you with the ability to be alerted about problems as they arise. It allows you to perform analysis to prevent future problems, and to plan for capacity. It also provides you with a mechanism to measure how productive your efforts are, and report those measurements to management, allowing them to make well informed decisions.

Everything I just mentioned is very important to a DBA’s success. Imagine if you will though, that your monitoring solution is in place, and all is well. Suddenly the phone rings, and your sales department launched an amazing special. Everyone wants in on it, but it’s taking 2 minutes to process each order. Worse, you want to analyze performance using data you’ve collected in your monitoring system, but you can’t because queries against it are timing out. Nightmare!

Why didn’t your monitoring system tell you this was happening? Why has it failed you so horribly? Maybe a better question is, did you remember to monitor (and maintain) the thing that is doing the monitoring?

If you just stopped reading to go check performance on your monitoring servers, then I’ve already achieved my objective.

Whether you’ve built your own monitoring, or you’ve purchased a monitoring solution from a vendor, one thing remains constant. The monitoring system is an important member of your production environment, and it must be monitored and maintained to remain effective, just like all of your line of business systems.

Now, I’m not saying to put in a monitoring system separately for this. We could end up in a deep monitoring recursion loop that way. I am saying that your monitoring solution should, from day one, be pointed to itself. If it is, you should know about it when things start going wrong rather than being unable to use it when you need it the most.

If you’re using a vendor provided system, keep in mind that the database is likely already tuned based on the settings used by the majority of users. Settings can be changed to be more aggressive or less aggressive depending on your needs, but those changes can create a different operating environment than the database was tuned for. The vendor can’t plan for every possible variation to that operating environment, so it is on you to monitor activity and performance, then adjust and maintain the environment accordingly.

When you have 5 or more servers being monitored for performance, SQL Sentry provides an additional license that works exclusively on monitoring the SQL Server instance that houses its data. This is not just because we’re nice (we are nice though!). It’s because we wanted to provide the ability to monitor that environment, without having to commit a paid license to it. We decided to do this several years ago, and it was in response to working in environments where we noticed the monitoring system was taking a back seat to everything else, or being completely ignored, when it came to monitoring coverage.

So, as a call to action, I invite everyone to ensure that the monitoring solution itself is being regularly monitored and maintained.

Until next time,

-JRH

Comments ( 0 )

    Leave A Comment

    Your email address will not be published.

    This site uses Akismet to reduce spam. Learn how your comment data is processed.