Published by Paessler Editorial Team
Last updated on January 23, 2024
•
7 minute read
In many enterprises, database systems are the most important server installations of all. Most sector-specific solutions rely on databases and store information directly in the database, rather than in individual files.
Aside from the technical aspects of the software, the question arises as to what the database or system administrator wishes to see in terms of monitoring reports. Ultra-high performance, professional databases use cluster systems in order to ensure a high level of uptime, or use NLB (Network Load Balancing) mode to optimize the allocation of performance overhead. In these cases, administrators must configure their monitoring routines appropriately, as the desired information will not otherwise be available. In terms of the accessibility of the system via the network, a ping check on the cluster address and further checks on the relevant nodes are also required. In order to exclude DNS issues preventing this access, many network administrators monitor the availability of both the hostname and the IP address per ping.
Database servers behave in the same way as all server systems in respect of many more monitoring parameters. Free disc storage space, network card throughput, the number of different connections via the network card and the CPU/RAM utilization are all values that need to be monitored on a regular file server as well.
Database-specific Issues
In the database context, trend information is especially significant. It does not help administrators to have visibility of just a few snapshots, without knowing how these values will change over time. Regular activities, such as billing runs or the recalculation of statistical data, require more storage space on the hard disks or temporarily reduce the operating speeds of the database.
Table space values, free disc storage space or the ongoing allocation of index numbers from a number range table do not tell administrators very much without regular logging and evaluation. Typically, administrators do not determine the run speed of SQL Selects directly; instead, they interpret data that is returned by the database as an output. This data certainly requires interpretation, and, where applicable, should trigger automated actions. The wealth of innovation that this represents is scarcely limited and depends heavily on the sector of the specific enterprise.
When armed with scripting languages and connections to the database, a lot can be achieved in conjunction with a scheduler running on the operating system. Nevertheless, it is not a comfortable approach, even though (as an example) inventive administrators are able to log successfully executed Selects in the Event Viewer. Regardless of how the IT professional spins it, the result is always what the IT sector (and other sectors) refer to as a "kludge." Well-ordered documentation addressing topics such as "When and where do specific SQL jobs start, and for what purpose?" is absolutely essential, if the calls and commands are not to be integrated into an already-established monitoring system.
Database Monitoring With Third-Party Solutions
Many standard monitoring solutions support monitoring of SQL databases out of the box. In addition to querying standard values such as user connections, transaction volumes, or memory utilizations, tools such as these also have the ability to transmit their own database queries and measure the processing involved in dealing with them. The major benefit of using this kind of solution lies in the wide variety of evaluation, alerting and reporting options that these solutions generally offer. Moreover, database monitoring is incorporated into the overall monitoring solution, with the result that administrators gain an insight into the status of the infrastructure as a whole and thus are not required to use a variety of separate tools to stay up-to-date.
You there!
