<%NUMBERING1%>.<%NUMBERING2%>.<%NUMBERING3%> PRTG Manual: Monitoring Databases
Monitoring your databases enables you to ensure that, on the one hand, database queries are processed in time, and, on the other hand, that the database itself performs within the defined parameters. Furthermore, database monitoring with PRTG makes it possible to be alerted via a corresponding sensor status if database queries return an unexpected result value.
PRTG comes with built-in native sensors for the most common databases:
- Microsoft SQL servers
- MongoDB servers
- MySQL servers
- PostgreSQL servers
- Oracle SQL servers
However, it is possible to monitor many other database servers. For this concern, PRTG uses the ActiveX Data Objects (ADO) interface in combination with the PowerShell scripting language.
There are two types of database sensors:
- Sensors monitoring databases directly: Monitor databases from the user perspective. These sensors send a request to the database server and receive corresponding values. You can optionally process data tables and show values in individual channels or monitor transactions.
- Sensors monitoring database performance: Monitor databases with a more abstract view on the servers. Usually, these sensors monitor performance counters via Windows Management Instrumentation (WMI).
PRTG provides several sensors which can "look into" the content of databases. Sensors of this type connect to the database server, execute a defined query, and show the execution time of the whole request and the query. You can use these sensors to process the data table and show requested values in individual channels.
The following sensor types are available for this kind of monitoring:
- Microsoft SQL v2 Sensor: Monitor your Microsoft SQL server 2005 or later.
- MySQL v2 Sensor: Monitor your MySQL server version 5.0 or later.
- Oracle SQL v2 Sensor: Monitor your Oracle database server version 10.2 or later.
- PostgreSQL Sensor: Monitor your PostgreSQL database version 7.x or later.
For these sensor types, you can define valid SQL statements that the sensors send to the database server. Define the queries in an SQL script file and store it into the respective \Custom Sensors\sql\ subfolder of your PRTG installation (see section Data Storage for details). You can select this SQL script when you add the sensor to PRTG. With every scanning interval, the sensor executes this script with the defined query against the database and the database returns corresponding values in individual channels. Use the Sensor Channels Settings to define limits for specific values.
Note: These sensor types need .NET 4.0 or later installed on the computer running the PRTG probe.
Alternatively, you can monitor almost all available database servers with the ADO SQL Sensor via an ActiveX Data Objects (ADO) connection and a PowerShell script.
Note: Although you can still use the outdated sensor versions for Microsoft SQL, MySQL, and Oracle SQL, we strongly recommend you to use the superseding sensor types ("v2") for more information, higher stability, and better performance.
Performance sensors for database servers have a more "abstract" view on databases and regard performance "from the outside". They do not read out any values of the database, neither do they send SQL queries to databases. This sensor type is only available for Microsoft SQL and MongoDB servers.
The Microsoft SQL server sensors monitor performance via Windows Management Instrumentation (WMI). You can manually set up different performance counters for your server instances, for example, general statistics, access methods, buffer and memory manager, locks, and SQL statistics. The MongoDB System Health Sensor reads information about connections and operations via HTTP and the MongoDB admin web console.
Microsoft SQL Server performance sensors are available for Microsoft SQL Server 2008, 2012, and 2014:
- WMI Microsoft SQL Server 2008 Sensor
- WMI Microsoft SQL Server 2012 Sensor
- WMI Microsoft SQL Server 2014 Sensor