SQL Sentry Review
November 23, 2018
SQL Sentry Review
Score 10 out of 10
Vetted Review
Verified User
Overall Satisfaction with SQL Sentry
SQL Sentry is being used to monitor SQL Server performance across our entire organization, providing trending, alerting, and helping us solve the "death by a thousand cuts" types of issues that are more of a challenge to pinpoint.
- SQL Agent Jobs runtime trending and alerting - out of the box alerts runtime deviations send alerts.
- Ad hoc trending against a previous week, day, or sampling period - pretty colors with ranges and averages to share with others.
- Reporting against multiple counters - this is available to compare time periods as well.
- I'd like to see a "Response Time" - measuring/tracking 'Select 1' out of the box instead of having to add a custom counter.
- There is so much functionality in the product that we need additional training to more fully utilize it. For many DBAs this type granularity is preferred over simplicity - I'd rather have more options than too few in a monitoring product.
SQL Sentry seemed to answer these scenarios better than competitors:
2."The database seems slow compared to last week" - shows how to trend against last week, which metric(s) of SQL Server are slower, and the root cause.
3.Parameter sniffing: One stored procedure has changed in the last 3 days and now the SQL instance has very high CPU. Looks like the cause is parameter sniffing. Alert off of the change and prove that parameter sniffing is the issue, including providing an easily explainable report for the senior management team.
1."Death by a thousand cuts" - an execution plan now takes 1.2 seconds that used to take .2 seconds to run. The underlying query is run thousands of times per hour and the load on the server has more than doubled as a result. Demonstrate why this is happening and alerting off of it.
2."The database seems slow compared to last week" - shows how to trend against last week, which metric(s) of SQL Server are slower, and the root cause.
3.Parameter sniffing: One stored procedure has changed in the last 3 days and now the SQL instance has very high CPU. Looks like the cause is parameter sniffing. Alert off of the change and prove that parameter sniffing is the issue, including providing an easily explainable report for the senior management team.