When I was a DBA involved with the management of a large number of database servers, I didn’t have many third-party tools to help me do my job. For the most part, I relied on scripts that I found or wrote. I enjoyed writing scripts to manage the servers, as it taught me a lot about the internals of SQL Server. Many of these scripts were eventually automated using SQL Server’s agent to run and save data on the different servers so we could review the results, looking for issues.

Some of these tools written over 20 years ago still run to this day. We captured tons of data about everything we wanted to know about the server in case there were issues. Loads and loads of data. We had some processes that would scan that data and send emails when obvious errors occurred, but it was hard to keep synchronized over many different servers.

Over the years, the number of servers and mix of database platforms grew (PostgreSQL, MySQL, for example), but not the number of DBAs, keeping up with the changes in technology and complexities of everything we needed to manage was nearly impossible. The process was basically akin to playing whack-a-mole with the users popping up saying, “My app seems slow,” “I can’t do payroll,” “Why can’t I get to…” and all the fingers would point to the database server. So, we would go to the server and prove them wrong (or occasionally, find that it was the database server’s fault…it happens.)

Over time, as we fixed more and more issues, we grew a great library of scripts to diagnose issues with our SQL Servers, but no matter how complete your script library is, as database platforms get more and more complex, it is harder and harder to keep up. Especially when the average DBA doesn’t have 40 hours a week to only sit and keep up with performance problems.

As we continue into the era of supporting more and more database platforms in our data estates, self-monitoring goes from being a very difficult task to a truly daunting task. I am personally advanced at diagnosing Microsoft SQL Server performance issues, but when that PostgreSQL server gets added, I just have to hope nothing goes wrong for a few years while I learn.

Enter monitoring tools

A monitoring tool can help DBAs keep track of things like drive space, licensing, and version end-of-support that can aid in budget discussions. Using baselining features can show whether the server is performing the same or worse over time. And using more advanced software than the average DBA has time for, it can coalesce data from multiple sources and tell you the complete picture of what an issue may be. Best of all, a software company offering monitoring tools will almost certainly keep up with the changes to the various performance monitoring options that all the RDBMS vendors support over time as new versions are released.

Monitoring tools help you swivel from being reactive to being proactive because they can watch as many servers as you license them to, 24/7, and tell you where you might be going wrong. That is right, “might”.

Every data estate is different, and monitoring tools don’t know what all your organization does. Highlighting issues that might be a problem allows you to be proactive. Your server is at 98% CPU usage at this time every day. Here are the processes and queries running at that time. Then you decide, is it a query, is it hardware, or is it that an executable name Asteroids.exe starts up every day at this time for some reason and uses a lot of extra CPU?

A necessity, not a luxury

Unfortunately, some shops see buying tools to monitor database servers as a waste of resources when they are already paying the salaries of their DBA staff. This is like a construction worker who can’t get a bulldozer to do some landscaping because “I already pay that construction worker’s salary.” Sure, the worker has a shovel and can get to it, but that bulldozer can do in one hour what the person can do in 3 weeks. And the bulldozer is still useless without the person driving it.

Most organizations don’t have enough DBAs to start with, and hence their job turns into that aforementioned Whack-a-Mole game just fixing whatever pops up next. But if you have ever played Whack-a-Mole, can you imagine how much easier if you knew where to whack before you saw that pesky critter staring you in the face? Augmenting your database management staff with proper monitoring tools will help them react to many issues before they are even noticed. Any time saved without customers not saying, “why can’t I do my job?” or “why can’t I spend my money with you?” is worth a lot more than a monitoring tool will ever cost.

If you liked this article, you might also like this Redgate product article:  How to convince your boss you need SQL Server monitoring.