dbWatch is marketed as a "virtual DBA." It is a database monitoring tool for Windows which monitors database servers over time, allows you to report on key performance indications and parameters, and flags any issues that it considers abnormal.
It’s very encouraging when you go to the vendor’s website for the first time – it mentions support for Oracle, SQL Server, MySQL , DB2, Informix and Sybase. This is misleading, though, since you only currently get Oracle 8/9/10 and SQL Server 2000/2005 – when you click for details you discover that MySQL support is pencilled in for late 2007, DB2 for early 2008, and there’s not even a suggestion of when Informix and Sybase might be supported. If they’d got any sense, they’d have done MySQL already (after all, it’s insanely popular) and wouldn’t have mentioned Informix or Sybase at all until there was some clue as to when they might be included.
The product runs on Linux or Windows, of which we chose the former. There are two components: the Server, which sits in the background and does the monitoring; and the Monitor, which is the GUI-led front end into the system and provides the interface for configuring the server and looking at the data it’s producing.
When you’ve installed the package, you first need to tell it what servers and databases to monitor. There’s a simple wizard for adding a server, which asks you basic questions like the server’s address and type, along with an admin-level user ID and password, which it needs because it installs a new database instance on the monitored machine for storing the data it’s gathering. Once you’ve added your various databases they appear in the "database pool" list on the main screen.
Associated with each database instance is a list of tasks (items that are scheduled to happen at given times/intervals) and checks (scheduled actions that alert you if some aspect of the database goes outside user-defined parameters). As you’d expect, you can right-click on each item to change its schedule or the parameters it uses to run, enable/disable it, view the stats that have been collected for that item, or (in the case of a check) define the thresholds for alerting purposes.
In its basic form, the package provides on-screen information about what your systems are doing. With all but the free version you can also add plug-ins that extend the functionality, simply by dropping them in a particular folder. dbWatch has produced some extensions that allow, for instance, email connectivity for alerts, or integration with OpenView/BigBrother/Tivoli. Extensions are simply Java archives, so the potential is there to develop your own.
The package comes in four versions. The free "Community" edition supports up to two database instances and gives just basic checks, tasks and reporting (but not plug-in extensions, as we’ve mentioned). Next up is "Standard", which handles up to five databases and adds a load of extra bits such as the ability to add tasks and checks to the standard list, along with system-wide reporting and the inclusion of an email plug-in. "Professional" adds to the feature list with stuff like support for custom extensions (along with a 10-instance limit) and finally the "Enterprise" edition removes the instance limit.
dbWatch is an OK product in its basic form: that is, the basic layout of the GUI is acceptable and the tasks/checks concepts seem to work fine. The vendors have made a couple of howling errors, however.
First is the GUI. We’ve said that the basic structure is OK, but the actual detail is bloody awful. For example, when you define a schedule you do so using the Unix “cron” format. So if you wanted something to run every 15 minutes during working hours you’d express this as “0,15,30,45 9-17 * *” instead of picking some nice things from a pretty GUI.
And say, for instance, you’re configuring the thresholds of the memory usage check: you have an entry called “keep data for” (no capitalisation) with an up-down counter that gives no clue whether it’s minutes, hours or days. Click "Help" and it tells you that the data type is a java.lang.Long and that it’s the "Number of days to provide statistics for".
The user shouldn’t be faced with behind-the-scenes stuff like Java data types, and why not put “Number of days to provide statistics for” in the GUI and avoid the need to go into the help section (which, by the way, is a two-pane HTML-driven window that seems to have had five minutes of design effort put into it). Oh, and a package that tells us it "Cheks [sic] the amount of memory" ranks, quite simply, as shoddy.
The other problem is the licensing model. The free version is, frankly, a waste of time because you can’t add extensions – and anyway, you’re limited to two database instances. And the basic commercial version, despite costing almost €500, only supports up to five instances – which isn’t very much. We’d rather see a less restrictive low-end commercial version (10 or 20 instances, say), and in fact we’d rather see no free version at all than something that’s so restrictive it’s a waste of time.
dbWatch is, then, a good idea implemented abysmally. What it tries to do is fine – but the GUI seems to have been put together with no consideration for what a user would expect, and the website instantly pisses off by teasing you with MySQL, DB2, Informix and Sybase support and then informing you that there isn’t even a date for some of them to be made available.
If it sorts out the GUI and stops misleading customers, the vendor actually stands a chance of this becoming a decent product, but there's some way to go yet.
Don’t buy it until they’ve sorted out the GUI and the licensing model.