One of the more popular products currently on the market is SQL Monitor, a product designed specifically for working with SQL Server. Its success is largely due to its ease of use and accessibility to those without professional DBA training. It works reasonably well for those used to working solely within Microsoft's product environment. As many companies have corporate policies to work specifically with Microsoft as their main, if only, product platform, it's a helpful tool.
It has a number of handy features, such as a fairly decent dashboard for identifying which servers have issues, and you can see how well a specific server is performing, and which queries are taking the longest to execute. It's good at providing the administrator with the feeling that he or she is in control, and can provide basic information and alerts if one of your servers is under attack. It is very well suited if a company is only running SQL server, and there is no dedicated DBA; it does automate many of the tasks that a professional DBA would handle manually and is very good for administrators who have little knowledge of how the server actually works.
Given all of the above information, your company made a decision and purchased a license, and have been doing fairly well with it. Sure it seemed a bit pricey but it worked pretty solidly as you only had one server, running only one platform.
So what are the drawbacks?
So it was great for managing your one or two SQL Server implementations. However, reality being what it is, not every database you have is running SQL Server. You have some applications which are deeply embedded into Oracle, so despite some of the great features of SQL Server, you still need a DBA to manage that database. The same is true for the Sybase systems. You would love to use SQL Monitor to keep track of how it is running, however, despite its claims, it does not work as well with this platform.
Now, bit by bit, you've discovered a few issues, such as a sluggish web interface. You notice a few other things that are mild annoyances; it's good at giving a good overview of where problems are occurring, but it's not particularly helpful when comes down to pinpointing specific performance issues, so you've started bringing in some DBAs to deal with more complicated issues.
Despite this, you've managed to creep by. You like using SQL Monitor; its interface is good, and some of your managers like it because it's easy to understand. But then more complications start to come into play. Your company has expanded. The number of instances you are running has grown to over a hundred. It's starting to get sluggish.
On top of this is the annoyance that it requires its own database to keep track of statistics, which with each new instance is growing; it starts to sag under its own weight. You buy more components but due to the pricing structure, the costs start to increase rapidly with each new server.
Your newer DBAs are now recommending other platforms. You start adding in some MySQL instances for certain areas of the company. Some new development areas are now relying on Postgre. You're finding that not only do the number of instances you’ve created cause you problems, SQL Monitor just can't handle all of these different platforms.
Even if you've found a way to get it working, each different platform starts requiring its own interface for monitoring purposes. You're losing time, simply jumping from one interface to the other and then trying to note if patterns are occurring. And in many cases, you're finding it just doesn’t work, and the cost... oh yeah, the cost.
So you start to try customising...
As you've been progressing, you or your DBAs are getting better at finding workarounds, you've written some great scripts in T-SQL that can start to automate some of the problems, such as pinpointing individual types of issues that you've discovered, and you'd love to be able to customise SQL Monitor. Unfortunately, one of the “features” with working with products solely associated with Microsoft's platforms is that they are somewhat obsessed with keeping their source closed. While it's understandable that they wish to keep some control over their intellectual property, customisation is becoming a nightmare
But you're finding that you can't add tasks, or procedures to the dashboard; it’s designed for monitoring. It doesn't pretend to do more, but you really would prefer a way of actually adding tasks and jobs to the tool itself.
At this point, you find you're ready for something that will do this as well to move forward...
All of the above problems can be solved with a single product: dbWatch.
Instead of simply using an expensive product that only handles the monitoring side of database management, it makes a lot of sense to use a tool that can help you perform many more of the tasks that you need to be able to accomplish. All of the features and functionality that SQL Monitor provides are available within dbWatch, but dbWatch can do a lot more and for a mere fraction of the cost.
You can monitor all of the myriad databases that you are managing, regardless of the platform, be they Oracle, Sybase, SQL Server, Postgre, or MySQL and MariaDB. You have a simple interface which will allow viewing and managing these as if they were one database. It's as easy to manage 200 instances (or more) as it is to manage 20, whether they are hosted locally or in the cloud in different parts of the world.
Not only can you monitor the databases, you can use dbWatch to perform many management tasks
Unlike SQL Monitor dbWatch is very customisable. It provides the ability to customise the UI; you can install whatever scripts that help achieve the day-to-day tasks in managing your databases.
You can use it to create regular reports and can use it to drill down into specific areas and manage and administer all form the same interface, regardless of the platform.
While SQL Monitoring is a monitoring tool, dbWatch is a complete operations tool. When you consider this extra features and the cost differential, you'll wonder why you were using anything else.