SentryOne has been running a series of blog posts to help customers get the most out of its solutions for building, testing, documenting, and monitoring data-centric applications, including SQL Sentry.


SQL Sentry, the solution for SQL Server performance problems, can help users ensure alerts are meaningful and actionable with the right tweaks, according to SentryOne blogger Patrick Kelley.


"Many database admins (DBAs) are overwhelmed with the numerous roles and responsibilities," Kelley says. "This leads to a whack-a-mole management process that doesn’t address core issues."


Kelley goes on to offer user tips and tricks for alert mining and how to find the cause of problems. He also refers readers to his alert tuning basics and common alert tuning examples posts for more information.


To set up effective alerts, customers can use the Topology they create in the Navigator pane to override and modify conditions and settings. The level or object selected in the Navigator pane defines the conditions shown in Conditions and Settings.


A frequent culprit when it comes to alert noise is job failures, he says. Users should first work out which jobs are generating the alerts, then decide whether those jobs are expected to fail often or indicate a resolvable issue with the jobs -- rather than a need to tune alerting for them.


"Do you need to be alerted to every single occurrence?" Kelley asks.


The next most common cause of alert noise in these circumstances is deadlocks. There are queries capable of pulling deadlock counts by application, database, user, resource, or text data, he says.


"For example, you could receive alerts only when there have been X number of deadlocks within Y amount of time," Kelley says. "Consider more meaningful ways of being alerted (if you need to be at all). I recommend doing this every two to four weeks initially. Once things get to a better place, I always recommend running through this script at least quarterly."


In subsequent tuning sessions, set the EventStartTime to a date after the final round of tuning. Otherwise, 'old data' can skew the true impact of a previous tuning. Because of this, Kelley recommends adding a comment noting the date of the last time the user went through the script.


Read all his tips in the full blog post.


( Photo by Etienne Girardet on Unsplash )