SQL Monitor’s dev team has made huge improvements to the product over the last year. In the first half of 2017 alone, they released reporting capabilities, support for collecting metrics from VMWare hosts, significant improvements to performance and scalability, improved configurability of alerts, as well as dozens of smaller enhancements.
Since we’re about half way through 2017, it’s time to talk about our plans for the rest of the year. I should give the usual caveat that we do change plans in response to user feedback, so it’s possible that some of this will change. There’s also other functionality we’re very likely to work on, but need more investigation before talking about here.
Firstly though, I’m excited to announce that we’ve just doubled the development team size on SQL Monitor. I’m really proud of the progress the team has made over the last year, but we can always do more and faster. New team members have already joined, with more coming on board over the next month or so. With that in mind, here’s what we’re planning to work on.
1) Support for complex networks and geographies
Monitoring servers in different datacentres or on different networks can be tricky. In these environments, you have two choices. One approach is to monitor every network’s machines from a single place by opening firewall ports. This can be awkward to set up and is guaranteed to cause you grief with your network admins. The alternative is separate monitoring installations inside each network, which means checking different SQL Monitor installations for each environment.
We’re planning to solve this by allowing multiple SQL Monitor installations, one on each network, to consolidate information up to a single UI. This provides the best of both worlds, allowing easy configuration and eliminating performance issues relating to bandwidth and latency over the internet, while providing a single centralised place to understand your entire SQL Server estate.
If you think this could benefit you, we have a private technical preview available – please email firstname.lastname@example.org if you’d like to take part.
2) Improving the configurability of alerting
This one’s composed of a huge array of small improvements, but the underlying goal is to allow you to receive just the alerts that are important to you. Improvements will include:
- Better customisation of what notifications go to different groups of people, and at what times.
- A selection of filtering improvements for different alerts, like filtering deadlocks against specific databases.
- Suppressing alerts raised against machines while those machines are acting as passive nodes.
- Grouping of similar alerts, to make them easier to consume.
- Better visualisation of alert configuration to make it faster and simpler to identify and tune out alert noise.
3) Make it easy to get to the root of specific performance issues
We aim to improve several aspects of performance diagnosis. Ultimately the goal is that when a problem occurs, you have the information you need at your fingertips to understand the true root cause of that issue.
Integration with DLM Automation
Many things impact performance, but one common culprit is deployments having unexpected side-effects.
Part of why customers use Redgate’s Database DevOps solution to automate deployments is to provide traceability of changes, and we’ll be surfacing this data from our deployment automation tooling inside SQL Monitor. You’ll see when a deployment occurred, and how it impacted SQL Server, providing you with valuable context about recent changes when investigating an issue. Next time a bad deployment kills performance, you’ll know who to blame ?.
Query performance history
We’ll be exploring ways to show how query performance changes over time, and identifying the causes of poor performance.
Automatic code inspection
Using SQL Code Guard’s analysis engine, SQL Monitor will inspect your SQL code, using intelligent rules to highlight improvements that can be made to queries.
Blocking process information
We’ll make it easy to explore how processes blocked each other in the past, so you can take preventative action for the future. Tools like sp_who2 or sp_WhoIsActive show powerful information about blocking, but only at the point in time that you run them, which is often too late.
4) Help proactively improve management of the whole estate
While the diagnostic capabilities described in the section above make it easy to understand the cause of specific problems, the capabilities in this section help you be more proactive in identifying opportunities for improvement across your entire estate.
Sub-optimal indexing strategies (including indexes which are missing, overlapping, unnecessary, unused, or fragmented) are a major contributor to poor performance. We’ll tell you about where the greatest gains could be made across the entire environment.
We’ll help you with planning future resource needs by identifying trends, and helping you predict the need for additional resources before they ever become a problem. The focus will be on the storage layer, but may include other information too.
Versions and patches
We’ll give visibility into what versions / editions of SQL Server and Windows are deployed in your environment, along with service pack information, helping you identify machines which aren’t up-to-date.
Richer estate-wide reporting
SQL Monitor’s reporting lets you see the big picture of trends across your whole SQL Server estate. We’ll provide more types of report, along with greater configurability, aimed at helping you make sensible decisions about which areas most need your attention, and where your time can best be spent making improvements.
Tell us what you think!
We’re really excited about what’s coming up for SQL Monitor, and what a new bigger team will allow us to deliver. The details of many of these improvements aren’t finalised, so as always please let us know your thoughts by emailing email@example.com.
Was this article helpful?