any third-party monitoring tools are available for monitoring databases. These tools are often expensive and sometimes overkill for what amounts to answering the simple question: Can the applications reach the database or not? I've encountered numerous clients who would not spend any money on a database-monitoring solution yet expected 24x7 availability. In those scenarios, you have only two ways to accomplish that level of availability:
- Use the alternate definition of DBADoing Business All night.
- Use a tool.
You can quickly rule out the first option as personally unpalatable. That leaves you with one option: use a tool. Remember, you have no budget. Fortunately, the .NET Framework 2.0 and Visual Studio 2005 make it easy to create a basic but extensible monitoring solution without a lot of complexity or coding.
It's very easy to get carried away with scope creep on a monitoring solution. There are so many things that might be nice to know about. It's very important to keep focused on what really matters. The end users don't care about technical details; they want their critical application to work whenever they use it. Satisfying this simple business requirement requires more than just a working database backend for the application. It also requires that the application can successfully connect to the database. Consequently, it's desirable for the monitoring application to behave similarly to the end user's application. For example, if an end user application connects to a database using ADO.NET 2.0, then the predictive power of the monitoring application is higher if it uses ADO.NET 2.0 to check for database connectivity.
A Windows Service is a logical application type for a database monitoring solution, because if the power fails on the machine hosting a Windows Service, it automatically restarts itself when the machine restarts. However, the Windows Service application should not reside on a server hosting a monitored database. If that server goes down completely, so would the monitoring program. Additionally, in most cases, end user applications (including Web applications) typically run on a different machine than the database server. That makes them susceptible to failure from either database problems or network problems. Having the monitoring program on a remote machine enables it to test for both types of problems.
Framework 2.0 Features Needed for Monitoring
Do not store database connection strings in the application code, because any changes would require recompilation. Use an application configuration file instead. To retrieve connection strings from the application configuration file, use the ConfigurationManager class. To make the database access code provider independent, use the DbFactory classes. Use classes in the System.Net.Mail namespace to send alert messages to the DBA or other designated parties.