This post has been updated to include a link to our Strategies and Best Practices for Virtualizing SQL Server guide.
I'm proud to present the next major release for SQL Sentry’s performance and event monitoring platform, and it is loaded with new products and features that will appeal to a very wide audience. [Download a trial] Perhaps the largest addition is our support for the Analytics Platform System (APS) and Azure SQL Data Warehouse (Azure SQL DW). SQL Sentry now provides performance monitoring for these platforms at a level previously unavailable. David Benoit provided details about this new product in his blog post yesterday, so I encourage you to stop by and read that.
Beyond the new platform support, we've done some work to provide some of the most requested features from the SQL Sentry community.
Virtualization is probably one of the most impactful technologies on our industry in the last decade. Today, it is all but trivial to virtualize everything, from shared desktops to database servers.
A problem facing many SQL Server admins today is the fact that the classic picture of system performance does not provide a window into how the virtualization layer might be affecting performance. In SQL Sentry v9.0 we wanted to begin to address this problem, but we wanted to do it in a way that provides clear insight to the SQL Server admin without requiring that they have a deep understanding of the virtualization platform.
ENABLING VIRTUALIZATION SUPPORT
Think of this process as a sort of "switch" that enables virtualization support for guest VMs. We support VMware vSphere 5.5 or higher, as well as Microsoft Hyper-V on Windows Server 2012 or higher. It is important to understand which platform you are on, as they are enabled differently. I've broken this support up into separate blog posts to serve as better, self-enclosed reference points:
VIRTUALIZATION FOR EVENT MANAGER
We talked to a lot of people in the community, and we found that a common frustration among DBAs was when a server was migrated to another host for one reason or another, and they weren't made aware of it until they were experiencing performance problems because the new host was under stress.
To help with this, we've added a new built-in Event Manager condition that can be used to alert you when the host for a VM changes. You'll be informed of the details surrounding the event including the VM name and both the previous and current host names.
IT'S NOT OVER!
This new support for virtualization is only a small part of what we have planned. I apologize for just adding a teaser here, but very soon we'll be taking this support to a whole new level.
Performance baselines were a big hit with our user community. People use them for all sorts of reasons from testing new releases to ongoing proactive performance management, but there was one case that wasn't covered in the initial release of the feature. There wasn't a great way to build a baseline that you could compare across different servers. In v9.0, we've addressed that need with global baselines.
Simply create a baseline from a server the same way you do today, and choose to make the baseline global when you save it.
Now that baseline will be available on any other server for both the Performance Advisor dashboard and custom conditions.
In addition, you can override the global values on a server by server basis, just in case you want the baseline to view some servers a bit differently.
Using these baselines in global custom conditions is also an option now, and baseline metrics will be resolved to the overridden values for any server that uses a customized version of the global baseline.
Access this simply by choosing to edit the baseline from the Performance Advisor dashboard for the server you want to override the global values for.
This is a bit of a prerequisite information byte before covering the next major set of enhancements.
As I mentioned at the beginning of the article, we've added support for both APS and Azure SQL DW. This created a need to change some terminology. The change is very intuitive, but if you have gotten used to registering "Computers" and "Connections" you'll want to look for "Targets" and "Instances" now. You'll still see that computers and connections are displayed at a lower level for things that fall into those categories.
A Target is basically the endpoint for the thing you want to monitor. An Instance is an application such as SQL Server, SSAS, or SharePoint.
In most cases, the Target will be a Windows system, but it could also be a service endpoint, such as Azure SQL DW.
We've combined registration of Targets and Instances into a single experience. Previously, you could register either of them separately, but there truly is an unbreakable relationship between them, and we found that a lot of new users could become confused trying to understand which one they needed to register.
Adding a Target is now designed to help ensure we will be able to successfully monitor the new target. The system now requires a quick connection test as a step to add a target. This will let you know if you will be able to monitor with Full Access, Limited Access, or No Access.
Note that this step is designed to help you get the most out of SQL Sentry monitoring. Large environments generally have more than one Site, and we'll test against all of the monitoring services in each Site to help you choose the best option. You can select which one you want to add the Target to before moving forward in case our suggestion is not really where you want it to go.
In a future release, we'll have the same type of connection tests for instances. In this release though, you'll be able to add an Instance after you click next.
(You can also directly add an Instance to an existing Target without having to step through the Target connection tests again.)
Full Access means that you'll be able to view OS-level performance metrics, including our patented Disk Activity view. Limited Access means that you will be able to monitor an Instance on the target such as SQL Server, but you won't be able to see the OS-level information. This is usually due to security, firewall, or similar situations. It will be very clear if all you have is limited access to a Target.
We also provide links to troubleshooting steps that are kept updated by our support engineers.
A very good reason to continue registering the target with Limited Access would be if you're adding a Target that resides in the cloud. This means that, using limited access mode, you can now fully monitor SQL Server instances in both Azure IaaS and Amazon EC2, or anywhere you have a supported SQL Server version running, along with the ability to connect. This was difficult to do previously without working through several errors related to collecting OS-level schema information and performance data.
Finally, if you add a Target with Limited Access, and you discover later that SQL Sentry will now have Full Access, you can change the Access Level using the monitoring service connection properties.
For those using the SQL Sentry PowerShell module to manage Target and Instance registrations, these connection tests are bypassed, allowing you to specify the Access Level at the time you add the Target. (We don't want to slow you down while you're running a script to add 500 servers.)
The new registration experience and Access Levels are part of an ongoing effort to make sure we provide the best performance monitoring possible anywhere you might need it.
Version 9.0 also contains many new and updated features that may not be quite as visible, as well as general performance improvements and bug fixes. I suggest taking the time to review the full change list to get an idea of just how large this release is.
For me, this release is a real milestone. Between core features, virtualization, and new support for APS and Azure SQL DW v9.0 is one of the largest single releases we've ever had! It is also the first major release since I became Product Manager. We really hope you love it!
Until next time,