Home > Articles > Data > SQL Server

SQL Server Reference Guide

Hosted by

The Utility Control Point and Data Application Component, Part 1

Last updated Mar 28, 2003.

This tutorial is a two-part series where I’ll cover two new features introduced in SQL Server 2008 R2. I make a point of not covering features in a beta state, since that’s not as useful to “real world” data professionals. Things change during a beta or more accurately the “Community Technical Preview” (CTP) and you won’t run those in production anyway. So I normally wait until a feature is released before I talk about it here on InformIT.

I’m covering these two features together because they work more or less hand-in-hand, meaning one is not as useful without the other. They do, however serve different purposes.

The Utility Control Point

The Utility Control Point (or simply UCP) is a feature that is very similar to the Management Data Warehouse (MDW) that was introduced in SQL Server 2008 (which I’ve explained in more detail here). It is simply a single place where performance and activity data is collected and stored. In fact, it uses the same mechanisms to collect that data as the MDW – using yet another feature called the Data Collector (DC). The UCP does, however, have some interesting differences.

The first difference is the depth of data that the UCP collects as opposed to the data in the MDW. The MDW has very find-grained information about the queries running on an Instance of SQL Server. The UCP does not have this level of detail. The reason is that the UCP is designed for a “wider” breadth of data – dozens (and in some cases hundreds) of systems. In fact, you won’t see any detailed query data stored in the UCP, whereas in the MDW you can drill down all the way down to the Query Plan for an individual statement, if you wish. The UCP, by contrast stores information about CPU use at both the SQL Server Instance-level and the Windows Server-level, and storage information. As you’ll see in a moment, it also stores data about applications that you “package up” into a Data Access Component (DAC).

That brings up the other difference between the MDW and the UCP — the way the data is used. The MDW has a greater ability to find and tune badly performing queries, but only on a single Instance at a time. The UCP is used to show how heavily used an Instance of SQL Server is over a period of time, from a CPU and storage perspective. This allows you to quickly see and drill in on Instances that are showing pressure on those two components. As I’ll explain in a moment, you can do this by examining the Instance information or information about an application that you’ve “deployed” as a DAC.

Setting up the UCP

To begin, you’ll need a central server to store the Instances and DAC’s that you want to track. If you purchase the Enterprise Edition of SQL Server 2008 R2, you can track up to 25 Instances, and if you purchase the new DataCenter Edition you can track up to 200.

There are also quite a few requirements for setting up the UCP, which you can find in Books Online here. The more important ones are quoted from that page:

  • SQL Server must be version 10.50 or higher.
  • The SQL Server instance type must be Database Engine.
  • The SQL Server Utility must operate within a single Windows domain, or across domains with two-way trust relationships.
  • The SQL Server service accounts on the UCP and all managed instances of SQL Server must have read permission to Users in Active Directory.

An interesting side-note is that Books Online recommends a case-sensitive Instance for the UCP server. This may be due to the fact that the joins for the various tables within the msdb database (where it stores the information for the UCP and DACs) are based on server names, not a GUID or other artificial key, but in any case the documentation indicates that you can use a case-insensitive UCP if the managed Instances are case-insensitive. This is how I have mine set up.

The documentation also mentions about 20MB per managed Instance of storage that is required, which may change if you alter some of the settings. I haven’t found this to be a problem with the 25 Instances I’m monitoring with this feature.

After you’ve checked to ensure that you meet all of the requirements for a UCP setup, it’s a VERY simple process – and in fact when you click on the new tab for The Utility Control Point you’re shown a series of (English only) links to videos that walk through the whole process. Even if you don’t speak English, the steps are all shown in the video.

When you’re done, you can connect to the Utility with the top left-hand icon in the icon bar of the Utility Explorer panel.

You can see here that I have already set mine up, and I’m collecting information on about 25 Instances. To monitor an instance, you simply right-click the “Managed Instances” Node in the Utility Explorer panel and another Wizard appears:

Once again, those same restrictions from above apply. It’s also important to note that as of the writing of this tutorial, only SQL Server 2008 R2 is supported to be a managed Instance – although the word on the street is that a soon-to-be-released Service Pack for SQL Server 2008 will allow those to be enrolled as well.

I mentioned earlier that the UCP system uses the Data Collector feature from SQL Server version 2008. This has a few important considerations. First, it’s the reason for all these requirements. In other words, if you can run the Data Collector (DC) on an Instance, you can’t manage the Instance with the UCP. That means no SQL Server 2005, no SQL Server 2000, and – perhaps most important of all – you can only talk to one DC target at a time. This means if you’ve implemented the Management Data Warehouse feature in SQL Server 2008, you’ll either have to break that relationship and start pointing that data to your UCP instance, or you won’t be able to monitor it with this utility.

With the feature installed and a few Instances enrolled, you can see the results of your labor in that screen I displayed earlier. I’ll take a moment now and explain what you’re looking at, and how you can use that data. Just there at the top and on the left is a pie chart with three values: Instances that are well-used, over-used and under-used.

This is the key to the feature – it helps you understand where you can place Instances on various hardware or Virtualized Machines. In my case I have 20 Instances that are doing well, none that are under-utilized and 4 that are over utilized. I’ll explain where these numbers come from in a moment – and yes, you can change the values.

Just below the pie chart on the left you can see two bar charts, one for over-utilized and the other under-utilized Instance information.

You can see the two components the UCP tracks – CPU (for both the System and the Instances) and the storage space. I’ll come back to that in a moment. The line graph just below shows the storage space component of the Instances:

Pay close attention to this – it’s a combined number. That means on ALL of the Instances I’ve registered with the UCP, and in my case that’s about 378GB of data. That’s a great piece of information to have for Disaster Recovery and Business Continuity planning, as well as storage growth trends and so on.

Now I’ll return to the graph that showed me that I had four Instances that were over-utilized during this monitoring period. Just there at the bottom you can see that the reason these systems are shown as over-utilized is that the server – not the Instance – is CPU-bound. I’ll click the words “Overutilized Computer CPU” and the display changes to this screen:

Notice that all four Instances that meet this criteria are shown — the yellow info bar at the top shows “filtered”. I see two Machines (I’ve changed the names here to protect the innocent) and each has two Instances. While the Instances are fine, the Machines that house them are not. In fact, this is a Virtualized system that I apparently have over-committed the CPU on.

In the bottom-half (you may have to use the separator bar to re-size this on your screen) you can see that for the last one-week period I have good use on the CPU for the Instance but not for the Server. So now I know what I need to do.

While I’m on this panel, let me show you the rest of the tabs. The first tab to the right on the bottom of the screen shows the storage utilization, which you can filter not only by Database, but by I/O volume (drive letter) as well:

To the right of this tab is the Policy settings where you can dictate the conditions that show the system as over, under or well utilized:

Keep in mind this is per the Instance – if you want to change the settings for all Instances you monitor, you click on “Utility Administration” in the Utility Explorer. You can see in the top part of the screen that I’m using the “Global Settings” for this Instance, which means I haven’t changed any of the default settings. For my Testing systems I normally alter the settings since I’m not as concerned about their performance.

Finally, there is the “Property Details” tab that explains the properties on the system I’m evaluating:

In the next installment in this series, I’ll explain how some of this information can be used to monitor not only an Instance of SQL Server, but the databases it contains.

InformIT Articles and Sample Chapters

I mentioned the Windows Management Interface in this tutorial, and you can get a wealth of information about this technology in the article Programming with Windows Management Instrumentation.

Books and eBooks

You’ll need WMI access for some of this information. And there’s tons of info on WMI in this book by Matthew Lavy, Developing WMI Solutions: A Guide to Windows Management Instrumentation.

Online Resources

The official Microsoft documentation on WMI is here.