When you click on “Details”, you bring up the predefined report for this alert:
You can save this report in different formats, such as HTML, PDF, or just send it to the printer. Of course, you can also edit the tasks from this report dialog, but we’ll save this for now and come back to it later as the reporting functionality is one of the clear highlights in dbWatch and therefore deserves special attention.
Let’s now explore at the “Configure” option of the context-menu:
The above dialog pop up in which you can set custom values for this alert, such as at which percentage a warning or an alarm is raised, or for how long the data will be retained for statistics and reporting.
When you look at the “Set schedule” option of the context-menu, you can’t help but immediately notice the similarities of the dbWatch scheduler to the *nix crontab configuration file. You can customize each setting to suit your needs and when you click on the “Preview” button you’ll get the entered schedule in plain English.
The “Edit” option of the context-menu is the heart of alert management. From the above depicted screenshot you can see that you can management all aspects of an alert or a task. You can create new task for all supported database platforms, modify existing ones, install tasks that are available, but have not yet been installed in a particular database, etc….
While you can use the dialog to edit a task, you can also click on the “Edit RAW” button and you’ll see the above screenshot. All dbWatch tasks are XML files on the file system and are “just” loaded into the Task Editor for easy and user-friendly editing. So, if you want, you could do all editing of tasks using any text editor, but I’ll stick to the GUI. Let us now have a look at selected aspects in the Task Editor.
In the above screenshot you can see that this particular task is implemented using two database objects: 1 procedure and 1 table. More on this implementation in just a moment, let me just use this moment to mention that dbWatch uses stored procedures as much as possible. This offers several advantages for a monitoring software supporting multiple platforms. While the code for the procedures is certainly platform-specific, the name of the procedure that implements it is not. It is (or can be) the same name for all platforms and this gives a certain recognition value which should not be underestimated when working in a heterogeneous database environment.
You can see the actual implementation when you expand the “Implementation” node in the tree view. In the above example I’m looking at the code for the stored procedure that is called when the task is executed. You need at least a stored procedure that is called by the dbWatch engine, but in many cases you will want to keep the determined values in a table for more detailed statistical analysis over a certain period of time.
Let me now come back to the report. The reporting features of dbWatch are undoubtedly a highlight and the remainder of this review is more or less exclusively devoted to this topic. Every task and alert that ships with dbWatch comes along with its own report and consists of the underlying query, the result set, and the presentation.
The underlying query of the report for the “Instance memory check” tasks that I’ve chosen can be seen when you select the “Query” item in the Instance Memory check node. You can immediately check the result set by hitting the “Execute” button.
Under the “Resultset” item, you can define how the result set from the query should be interpreted in terms of returned data types and column names.
As you can see from the above screenshot you have plenty of different presentation types available to visualise the data. This should be more than enough to suit even the most sophisticated reporting requirements.
As mentioned above, you can generate such a report when you click on the “Details” item from the context-menu of the task.
An even more interesting reporting option you get when you open the dbReport Manager from the Monitor menu.
This is the centre in dbWatch from which you can control all things report-related. You can generate report, edit, or create reports. Let’s first have a look at generating some of the built-in reports.
Once you’ve clicked on the “Generate Report” button, the above depicted wizard is launched
First you need to select the database(s) against which the report(s) are run. This is a quite interesting feature since it allows you to run the report against all production servers, for example on a scheduled basis for a variety of reasons such as compliance and/or audit purposes.
Next you select the reports you want to run.
You can choose between running the reports immediately or create a schedule. For scheduled reports you can supply a list of recipients to which the report is send automatically when the mail extension is configure correctly. More on how to configure the mail extension in just a moment. As you can see as well, you further have the choice of what format shall be used for the report and which orientation the report shall have.
Once you’ve clicked on “Finish” the reports will be
