dbWarden is a comprehensive database monitoring and alerting solution for SQL Server 2005. 2008 and now 2012. It features email and text notifications with customizable metrics for alerts such as Blocking, Long Running Queries and SQL Jobs, CPU %, Log file and TempDB growth. Another main feature is a detailed HTML based daily health report which provides a thorough overview of your database server.
dbWarden is written completely in SQL and requires sysadmin level permissions to run xp_instance_regread and xp_fixeddrives. Utilizes SQL Agent, DBMail and Operators.
- Completely Free
- SQL-based for easy and quick installation and setup
- Compatible with all editions of SQL Server 2005, 2008 and 2012 except for Express (requires SQL Agent and DBMail)
- Receive a comprehensive and configurable daily "Health Report" that provides a thorough overview of your SQL Server
- Sends alerts via email or text using DBMail
- Includes sp_Sessions to monitor session and query performance
- Monitors your database servers for:
- - Long running queries
- - Long running Jobs
- - Blocking
- - Log file and TempDB growth
- - CPU utilization
- - Schema Change Tracking
- - Reporting on deadlocks
SQL Server 2012 SP3, error in Replication monitor section, need to add another column name of publisher NVARCHAR(128) to the end of the table definition.
I think I found a small bug in the procedure usp_FileStats. When inserting into #FILESTATS you are putting brackets around @dbname. For me this causes the flags in alertsettings table not to work because of the checks in FileStatsHistory table.
A terrific tool that I have deployed on many servers, definitely recommended. thank you very much for your hard work and making it available to everyone. There is a request I would like to make if you don't mind: if you have the time what would be very useful would be a way to collate all the data generated into a central location so aggregate reports could be created for all the servers monitored for MI reporting. I have started working on that myself using your existing code but I am sure you would do a better job. Thanks again.
Very good work. This is amazing at what it is able to do and what it can monitor.
There are some issues. The first is the frequent failing of the Long Running Queries job. The second, is that the RunTime calculations are off. If I compare the datestamp fields between two records in a five minute interval, I'll get all kinds of different increases in the RunTime value. For example, the first record was created at 11:37 PM and the second at 11:42 PM, but it's showing the RunTime value increase from 11,225.48 - 16,276.966 seconds. Same SPID, same statement executing. That's a difference of approx 1.4 hrs. The next 5 minute interval (11:47 PM) shows the jump to 18,725.235 seconds. That's an increase of around 41 minutes. I considered that the time was in something other than seconds, or maybe time actually running on CPU, but that doesn't seem to add up either. If I've missed something or am incorrect, please let me know.