SQL Sentry Reviews

We use SQL Sentry to manage in-house production and development databases as well as production databases of our clients. SQL Sentry allows us to effectively, efficiently manage many databases in our high volume, highly transactional system. This tool allows us to help us keep our system running smoothly and proactively fend off possible problems, greatly reducing and even eliminating the dreaded "the system seems slow today" phone call.

SQL Sentry is used to identify issues with our custom SAAS solution for the education industry. It is used by IT to identify issues in our SQL environment and by the development team to find the root cause of SQL issues and correct and/or improve them.

We found that specific common queries were causing deadlocks which impacted both performance and usability of our application. We then worked with the development team to determine the cause and deploy a patch for our software which resulted in 70% improvement in response time from our application.

We currently use SQL Sentry to monitor and alert on production SQL Server systems.

We use it all the time to find long running queries and index problems

SQL Sentry is one of my favorite tools. In a single dashboard I can see the state of most metrics I care about for daily operations and well being of the SQL instances. The most useful feature is having the ability to trace back performance issues, days and even weeks after they have occurred. You can establish a baseline and detect unusual activity in real-time.

Most times, the debate is usually between the DB people and the application people - who was responsible for the performance problems. E.g. was it a table being locked by SQL or was it an unresponsive application server that caused the session to hang and locks to appear. With SQL Sentry, this is easily solved.

SQL Sentry is being used to monitor performance and support troubleshooting issues in our SQL Server infrastructure. It provides thorough and more complete information than the native tools. We use it across the main SQL Server Farm by a team of 5 DBAs

We were having a great deal of memory and CPU pressure on a critical business SQL Server and we were able to quickly trace the root cause to a poorly written SQL Server ad-hoc query. By showing the performance impact to the developer we were able to assist in having this functionality rewritten as a stored procedure and dramatically reduce resource consumption.

Monitors five servers, many with production issues. The old environment had been very neglected until a DBA was hired. I am the DBA's backup.

see prior answer.

We use it to monitor our critical SQL server cluster and it is currently just used by the DBAs. It allows us to monitor in real time but also allows us to better understand why problems had happened so we can prevent them from reoccurring.

IO waits were high and we didn't know why but using SentryOne we established IO performance on the storage was reduced which then helped us identify a problem with one of our storage controllers. Without SentryOne it would have been impossible to show the storage team evidence of the issue.

We use SQL Sentry to provide an agreeable set of monitoring metrics and results which we use as part of our consulting toolset for MS SQL server.
It also forms the basis of our alerting and monitoring framework that we deploy for our clients.

When troubleshooting performance issues on a SQL server we exhausted our normal tuning methods. We turned to SQL Sentry and found from monitoring data that this server was seeing a very high amount of Context Switches.
This information pointed us to SQL server MAXDOP settings and VM CPU configuration issues.
We would not have been able to find this information easily without using SQL Sentry to find the root cause.

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.

During load testing we were able to quickly find the specific stored procedure that was causing the highest cumulative execution time in a specific time range using SQL Sentry.

I work as a consultant and this tool is used by my clients to monitor production (dev/test in some cases) servers. Monitoring and alerting (PA and EM) is used. Fragmentation manager etc., is handled via other scripts.

Slow system reported, review history of that time period and pick out the top SQL

As a Managed Service provider, SentryOne provides us with a key platform to monitor, diagnose issues and optimize performance for our customers. The platform provides the capability for services to be monitored 24/7 with in-depth, relevant information to be captured and reviewed for proactive and reactive cases, improving service delivery significantly.

A business intelligence application would intermittently take two to three times its normal duration to complete its processing run, causing significant business disruption. The workload was spread across multiple SQL instances and was a black box from a code perspective. SQL Sentry identified that the application was running multiple processing runs in parallel, but this wasn't visible from a customer perspective, as they only scheduled the run once.

We specifically purchased SQL Sentry Performance Advisor out of the need to resolve performance issues on one of our SQL clusters. It was difficult to troubleshoot the issues after they had occurred and SQL Sentry allowed us to review the performance over a period of time and specifically go back to when an issue occurred to troubleshoot. We now use this for the majority of our SQL estate and specifically for IT Department only.

Fairly recently we had a performance issue with a SQL Server consuming 100% CPU, with the performance advisor we was able to pin point the specific queries that were a problem and advise the vendor. Which lead the vendor to make recommendations and changes to their tables and jobs. This resolved the performance issue.

Performance Advisory allows you to quickly know what the overall performance of the servers looks like. From the dashboard you can deep dive right away to any specific area that may require attention. It contains the KPIS and data of almost all aspects of the SQL Server.

Correlating performance metrics is the key to resolving complex issues, and doing that without a resource that displays them in an organized manner is very hard. This tool has enabled us to identify and remove all kinds of issues, such as sources of blocking, deadlocks, storage bottlenecks, etc.

We use SentryOne in our production (over 120 Instance worldwide and growing). It gives us an easy way to navigate the dashboard to quickly identify a performance problem and the ability to drill into the issue quickly and come up with a game plan to address the performance problem.

One time we deployed a new feature to our product, and it was causing over 88,000 plus long running queries over 2 seconds (in a one-day period) and we found the root cause to the issue in minutes. It turns out it was a missing indexing. So, to have a tool like SentryOne to help us identify this issue was great, and resolving the client’s issue within minutes of the performance problem was amazing.

We use SQL Sentry to monitor our production ERP databases. It allows easy tuning checkup, configurable emails to alert you to conditions that require attention, and offers insights into SQL that are difficult and time consuming to duplicate with SQL Management Studio.

We've had a few cases with unexpected blocking, but due to our ability to quickly narrow it to a specific time and specific SQL objects involved, we were able to determine the cause was not something developed inhouse, but a vendor customization. It was easy to duplicate with the info we had, so we were able to prove it to the vendor quickly and get them to warranty it rather than play the "he said, she said, ...." game.

SQL Sentry is being used to monitor 260 SQL instances across or enterprise. We are in the process of integrating the alerting capabilities with SCOM via SNMP. Along with alerting SS greatly increase our efficiency in resolving ongoing and past performance issues. SS also provides a central repository for reporting at the enterprise and client level. We previously used a competitors tool for 7 years but moved to SQL Sentry due to the products inability to function in our environment and more so a lack of response to the issues we were experiencing by the vendor. Our experience with SQL Sentry support has been excellent to date.

A common experience is the SQL optimizer choosing to use a loop join on a large join. We see this even after stats update with full-scan on the associated tables. We have tried the optimizer trace flag.

Process.
Find the SQL statement in Top SQL
Look at the historical run times/plans grid. Notice run time and color of dot. High run-time and different color, you have a bad plan.
Open the plan to review operators
Add hash join query option or join hints. I know this is not best practices according to MS, but the trade-offs in our OLAP environment make it the best choice.

We have been using SQL Sentry exclusively in our database department. Occasionally our technical leads join our analysis and troubleshooting sessions. We run screen shares in those sessions to solve application performance related issues. We have used SQL Sentry analyzing and researching long running SQL queries and deadlock issues, which have become major bottlenecks in our application development processes. The software has helped us address missing index issues and optimize query performances. In the past, we were also able to make a few important design decisions based on the analysis and statistics that were provided by SQL Sentry monitoring service. Decisions that include when and where to use application or database caching mechanism, as well as the benefit of implementing ad-hoc queries versus stored procedures. It has also helped our QA department to identify most key issues in our load tests.

One time during the application launch, we have discovered a site not responding due to heavy load on the web server. In New Relic we saw the application process that took a long time to respond but couldn't figure out the root cause. By looking into SQL sentry Top SQL tab, we immediately identified that a stored procedure that was designed to lookup information across database that had been timing out. We were able to address it immediately and prevented the site from shutting down.

SQL Sentry is used currently on our live platform to mange SQL performance which makes debugging issues much easier. We are looking to also implement this into our test environments so we can see the effect caused by releases at a more granular level.

We were getting performance issues after a release which turned out to be indexes not covering new columns. We were able to see which procs caused the issues and the plans associated to them. We were able to quickly amend some indexes to cover the procs.

We were testing it as a possible replacement for the current monitoring tool but unfortunately some members of the team were too stuck on their old monitoring tool.

As stated earlier, it showed us that the multiple SQL Server instances on NUMA architecture weren't using all available memory so we affinitized the processors and the instances were able to use all the memory on the machine and performance was improved.

Currently, we use SQL Sentry to monitor database performance and debug issues as they arise. I open up the dashboard for our production environment at the start of each day. We also use it to run our complicated weekly job that spans four servers. This job calls one server and then calls back to the originating server.

We were seeing regular spikes in CPU on our production environment. SQL Sentry identified these are coming from a Java process. The queries looked like a report without any criteria set. By sending the graphs and the sources of the queries, our report writers found that a test report was running against our production environment.

We use Performance Advisor to monitor our database servers. We use this tool within the IT department to pinpoint pressure points, search for expensive queries, and for capacity planning of our databases. From a business perspective, this tool helps us to address performance problems introduced by new code and plan for new infrastructure.

We have a problem with our version of SQL Server where parameters declared as unicode (nvarchar) that are used to compare against columns that are of type Latin1 will have the database engine choose to cast the entire column to unicode instead of downgrading the parameter to a Latin1 type column. When we noticed a lot of simple single record queries using a lot of cpu and performing table scans, we were able to determine which queries needed to be rewritten.

Our company provides web site hosting. We use SQL Sentry Performance Advisor to monitor the production SQL Server instances supporting our hosting environment. Our hosting SQL Servers support between 10-40 different application databases. The primary driver for the workload on our application databases is the amount of traffic our hosted web sites receive. At any given time the traffic can be spiking on a specific hosted web site which will cause its corresponding database to spike and cause issues for the entire SQL Server.

We had an application database that would occasionally spike to 100% CPU. SQL Sentry helped us identify which database was consuming the CPU. That was pretty straightfoward. What was not straightforward was figuring out why the database was consuming 100% CPU. Every indicator we could see on the surface was that the workload had remained consistent. The volume of requests and type of requests going to the web application were consistent. The volume of SQL transactions was consistent. Where SQL Sentry provided it's worth was in Top Queries. It showed us that one specific query was consuming all of the CPU. When we looked at the execution plan that was captured by SQL Sentry we could see that a sub-optimal plan had been cached. We were then able to flush the cached plan and a new more optimal plan was cached. This returned the database CPU consumption to normal. We then worked through updating the SPROC so that a sub-optimal plan would not be cached. SQL Sentry Top Queries and execution plan capture were critical to handling this incident.

SQL Sentry was purchased to monitor our new Business Intelligence Infrastructure. The tool allows us to see at a glance if we have any performance issues; we also utilise the alerting feature heavily to make sure that even when we are not in the office or connected we can still see how the server is performing.

We had a long running query that locked a lot of the schema out of hours, with SQL Sentry not only could I identify what was blocking everything else but also view the specific part of the code and it's execution plan, look at what else was running at the time and then tune the SQL as well as reschedule some activity.

SQL Sentry Performance Advisor has been used as a primary monitoring tool for our production environment, it has helped us a lot with troubleshooting bottlenecks, finding performance problems, resolving blocking etc. We're using this tool across the whole organization and monitoring around fifteen large production SQL Servers.

We had performance issue with one of the drive which was housing files for tempDB of one of our critical SQL Server and we always had performance issues with that server. After the implementation of SQL Sentry Performance Advisor, we were able to identify that problematic disk and resolve that issue. This is one of the best example I would like to share here.

We use SQL Sentry to monitor our production database servers. We use it mainly for performance tuning for our environments. We also use it to analyse expensive queries, blockages, deadlock and so on. Then from the analysis, we apply optimizations accordingly.

We had a lot of situations where SQL Sentry came to rescue us. One of these situations was when we had a query running slow some times, and the majority of the it worked fast. SQL Sentry caught the execution statement and execution plan for us. After analysing the execution plan and parameter values, we found that the cached plan was not optimsed for a certain parameter values set. With this info, we deployed a plan guide to recompile this query, and then now it runs fast all the time.