SolarWinds SQL Sentry Finance and Insurance Reviews & Insights

To alert us of any issues with our SQL Server estate and to identify bottlenecks such as slow running queries so we can tune them for improved performance.

Production SQL Server implementations

We use SQL Sentry in my department to monitor patterns and fluctuations in performance for our SQL Servers. It's helped us address monthly spikes and unusual performance dips, so we know when we have a bug in just-released code and we know when to prepare for slightly-slower systems and address that accordingly.

SQL Sentry is a great monitoring tool for performance in environments that are transaction-heavy. It gives a complex overall view of performance on a daily/hourly/etc. basis so you know where spikes are happening (and when, more importantly). It also provides insight into blocking processes, so if you have a long-running query/job, you can see what's happening more clearly.

We use SQL Sentry to help us identify performance issues and remediate them quickly. In addition, we use it to alert on blocking and deadlocks.

SQL Sentry is very useful in production and performance testing environments for identifying and fixing slow performing applications. It is difficult on very high volume instances with a lot of history.

SQL Sentry is being utilized to monitor our current SQL environment. The product has provided insight and a new form of analytics to help push maintenance in a positive direction. The department is the only current user for this monitoring software. It helps prevent failure across the whole organization. Some business problems that are addressed is the new form of communication. Having a solid reporting platform has pushed the standard for other monitoring software in our environment.

SQL Sentry is great for shops that are implementing more than one SQL box, but monitoring just one server that isn't traffic-intensive can be very underwhelming for new DBA's.

My team uses SentryOne to monitor our production SQL environment. They will use it as a first tool to verify system health when pulled into production issues. If SQL is determined to be the bottleneck in process, we'll use the information SentryOne provides to pinpoint the problem code and pass the information onto developers for fine tuning. In our development environment, our developers also have the client tools to monitor their processes. If we had licenses available for the Dev/Test servers, then we could fine tune them before releasing code to production. This is limited because we only have a few licenses to spare for Dev/Test.

It has great out-of-the-box features that make it easy to install and get it up and running right away. However, fine tuning and customization of the solution, like setting up custom alerts and notifications, needs to be someones dedicated responsibility. Because of this, we don't necessarily have the time allocated to become true subject matter experts on the tool. What we get out of the box is usually going to be the norm.

We use the product to identify performance issues as they occur, with the goal of improving our processes and software to eliminate these issues going forward. We also use the product to monitor the health of our servers and to identify developing issues well before they actually make an impact on the environment.

It's great for making sure your environment is performing well. I love the fact that I can monitor my entire SQL Server estate from 1 screen. However, the setup and customization to ensure your inbox doesn't get inundated with warning messages are tedious and time-consuming.

Currently, the DBA team is the primary user of SQL Sentry. We use it for monitoring and performance tuning as well as mining the data for our own internal reporting. We have recently been rolling it out to other teams within Data Services (Data Engineers, Data Warehouse, etc.) and developers as well. The other groups use it for performance tuning and SQL Agent job reporting/history.

As a DBA, SQL Sentry has been extremely suited for most scenarios where I would need a monitoring tool. The primary thing I use it for is alerting. The default alerts are beneficial, and you can make custom alerts for seemingly anything you can think of.

The only downfall I could think of is how it aggregates historical data, and you cannot get as granular with older data. However, I completely understand the need for this, and it may even be something that can be done, we just haven't asked them about it yet.

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

SQL Sentry is well suited for a SQL Server shop. We also use DB2 and the DB2 guys are very jealous over the SQL Server monitoring tools.

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.

When we are getting techincal live issues on the website SQL Sentry is the first tool I use and the majority of times its the only thing I need to look at.

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.

I know virtualisation monitoring is available with future work in the pipeline but at present this is an area that I would like to see improved.