System Alerts

This article assumes that you configured both database mail and system operators. Please see my previous articles if you have not done these tasks already.

Today, I am going to talk about setting up alerts for system error messages that might occur with your SQL server database. Since alerts have been around for a long time, most of this information is backward compatible with older software versions.

The database engine defines the importance of an error messages with a severity level.

Low importance errors are defined by levels 0 to 10 (informational only); medium importance errors are defined by levels 11 to 16 (user/process issues); and high importance errors are defined by levels 17 to 25 (critical database issues).

Every good database administrator should have alerting on high importance error messages. Optional alerting can be enabled on medium importance error messages if you have time to research possible issues.

The code below uses sp_add_category to create a category for these alerts, sp_add_alert to add a new alert based upon severity, and sp_add_notification to ensure a email goes out to the operator when the alert happens. A simple WHILE construct is used to setup alerts for errors with severity ranging from 17 to 25.

The sp_help_alert stored procedure will return all alerts that are defined in the system. These alerts are stored in the msdb.dbo.sysalerts table.

The sp_help_notification stored procedure used below shows all the alerts in which I am the notified operator.

Like most system objects, alerting can be enabled or disabled. The sp_update_alert allows me to disable the ‘Alert For Severity 25’ alert.

Last but not least, SQL Server supplies the sp_delete_alert stored procedure to remove the alerts. The code below uses the WHILE construct to remove all alerts we just defined.

In summary, I talked about adding alerting for high importance errors. Each alert needs to be associated with an operator to be notified. Optional alerting can be done on medium importance errors. One feature that I did not go over is the @job parameter which allows a DBA to define a job to execute if an alert is fired. I will continue next time by talking about setting performance alerts which depends upon WMI queries to monitor operating system counters such as memmory and CPU.

Related posts

One Thought to “System Alerts”

  1. Appreciate it for all your efforts that you have put in this. Very interesting information. “He who despairs over an event is a coward, but he who holds hope for the human condition is a fool.” by Albert Camus.

Leave a Comment