• High Performance
• Balanced
• Power Saver

While it’s hard to perform a “real-world” CPU benchmark test, Glenn suggested I try using the Geekbench CPU benchmark software. The software runs a series of CPU and memory tests and produces a Geekbench Score which provides a standardized way to compare CPU performance.

To find out how much the three OS Power Plan options affected the performance of my T610, I first set the system BIOS in the Dell Setup program to “OS Control.” Dell not only allows you to set the BIOS to “OS Control,” which means the OS controls the power savings, it also includes other power savings options that are not controlled by the OS. I only tested the “OS Control” option.

Test Hardware: Dell T610 Tower, with a single, 6-core CPU (Intel Xeon X5670, 2.93 Ghz, 12M Cache, HT, 1333MHz FSB); 32GB 1333MHz RAM; a PERC H700 RAID controller; two 146GB 15K SAS Drives; one dual-port HBA (to connect to the DAS); and dual network connections.

Test Operating System: 64-bit Windows 2008 R2 (with current patches).

Next, I went to the Control Panel and changed the Power Plan setting to “High Performance”.

When I ran the test using the “High Performance” option, the Geekbench Score was 10,562.

Next, I changed the Power Plan to the “Balanced” setting, and the Geekbench Score was 7,991, a drop of about 24% in performance from the “High Performance” setting.

And last, I changed the Power Plan to the “Power Saver” setting, and the Geekbench Score was 7,075, about drop of about 33% in performance from the “High Performance” setting.

While the OS Power Plan settings affect more than just CPU, it becomes obvious from this simple test that changing the Power Plan can significantly affect a CPU’s performance, which in turn could significantly impact the performance of a SQL Server instance.

Of course, these three power options are available because they allow you to make a tradeoff between performance and power savings. As the DBA, you have to determine if the power saved by running the CPU more slowly is worth the performance tradeoff. The only way to really check this out would be to use a wattmeter to determine how much electricity is saved for each different settings. I don’t have a wattmeter to try this out, but Glenn has reported in some of his testing that the power savings appears to be insignificant, especially when compared to the significant drop in CPU performance between each “Power Saver” plan.

The point of this post is that when your configure your SQL Server’s hardware, you need to investigate what the appropriate “Power Saver” plan your server should be running. Based on this simple, initial testing, I think I’ll leave mine on “High Performance”.

–Because I have limited space, the test box will need to be a tower. I will also be limited to one physical test box because of a lack of room (and budget).

–CPU: 2 sockets with a total of at least 8 cores. Haven’t decided on the specific chips yet.

–RAM: At least 36GB. I want to have the ability to set up multiple virtual servers in the test box.

–RAID Controller: Must support RAID 1, 5, & 10, and any mixture of these RAID levels.

–Drives: I am looking at getting 8-16, 15K SAS drives, with a minimum capacity of 450GB each. The number of  drives will depend on what I can fit into my budget, and how many can fit in a tower.

I am still very much in the research stage, so my question to you is, if you could spec out your own SQL Server home test system, and you had $10,000 to spend, what you buy, and why?

PS: If you are a hardware vendor and would be interesting in letting me borrow such a test box from you for the next year or so, I would be very interested in talking with you. 

Blogs are a great way to learn new things about SQL Server, and just in case you have missed them, I want to recommend the following two blog series that I feel every DBA should read.

The first blog series is from Glen Berry, and is called the April 2010 DMV a Day Series. It covers 30 of the most commonly used SQL Server DMVs. Not only do the blog posts explain what each DMV is used for, each post includes sample code to make it easier to extract the useful information. When you go to the web page above, you will need to select the link to the left of the DMV’s name (e.g. A DMV a Day – Day 1) to read the blog post. If you select the DMV name itself, it will just bring you to the Microsoft MSDN site where each of the columns in the DMVs are described.

The second blog series I recommend is from Paul Randal, and is called A SQL Server DBA Myth a Day. This 30 part series dispels many common (and uncommon) DBA myths. The myths cover a wide range of topics, and you need to take the time to read each one carefully. When you visit the web page above, you will find the myth blog posts are located on the page in reverse order. So you will need to read the first myth, then scroll up to read the second, and so on, until you read them all. There are also some additional blog posts on this page that have to deal with DBA misconceptions, which you will probably want to read as well.

This is an excerpt from my free eBook, Brad’s Sure Guide to SQL Server 2008.

There is one thing every DBA knows with certainty, and that is that databases grow with time. MDFs grow, backups grow, and it never stops. The more data we have, the more work SQL Server has to perform in order to deal with it all; whether it’s executing a query on a table with 10 million rows, or backing up a 5 TB database. Whether we like it or not, we are fighting a losing battle, and DBA’s can’t reverse the information explosion. Or can we?

While we can’t stop growth, SQL Server 2008 (Enterprise Edition only), gives us some new tools to help us better deal with all this data, and that is the promise of compression. Given the right circumstances, DBAs can use data compression to reduce the size of our MDFS, and backup compression can help us reduce the amount of space our backups take. Not only does compression reduce physical file sizes, it reduces disk I/O, which can greatly enhance the performance of many database applications, along with database backups.

When we discuss SQL Server compression, we need to think of it two different ways. First, there is data compression, which includes row-level and page-level compression that occurs within the MDF files of our databases. Second, there is backup compression, which occurs only when data is backed up. While both of these are forms of compression, they are architected differently. Because of this, it is important to treat them separately.

Data Compression comes in two different forms:

• Row-level Data Compression: Row-level data compression is essentially turning fixed length data types into variable length data types, freeing up empty space. It also has the ability to ignore zero and null values, saving additional space. In turn, more rows can fit into a single data page.
• Page-level Data Compression: Page-level data compression starts with row-level data compression, then adds two additional compression features: prefix and dictionary compression. We will take a look at what this means a little later in this chapter. As you can imagine, page-level compression offers increased data compression over row-level compression alone.

Backup Compression comes in a single form:

• Backup Compression: Backup compression does not use row-level or page-level data compression. Instead, backup compression occurs only at the time of a backup, and it uses its own proprietary compression technique. Backup compression can be used when using, or not using, data compression, although using backup compression on a database that is already compressed using data compression may not offer additional benefits.

In the next section, we will take a high-level overview of data compression, and then we will drill down into the detail of the different types of compression available with SQL Server 2008.

Data Compression Overview

Data compression has been around for years. For example, who hasn’t zipped a file at some point in their career? While compression isn’t a new technology, it’s new to SQL Server. Unlike zip compression, SQL Server’s data compression does not automatically compress an entire database; instead, data compression can only be used for these database objects:

• A table stored as a heap
• A table stored as a clustered index
• A non-clustered index
• An indexed view
• Partitioned tables and indexes

In other words, as the DBA, you must evaluate each of the above objects in your database, decide if you want to compress it, then decide whether you want to compress it using either row-level or page level compression. Once you have completed this evaluation, then you must turn on compression for that object. There is no single switch you can flip that will turn compression on or off for all the objects listed above, although you could write a Transact-SQL script to accomplish this task.

Fortunately, other than turning compression on or off for the above objects, you don’t have to do anything else to enable compression. You don’t have to re-architect your database or your application, as data compression is entirely handled under the covers by the SQL Server Storage Engine. When data is passed to the Storage Engine, it is compressed and stored in the designated compressed format (on disk and in the Buffer Cache). When the Storage Engine passes the information to another component of SQL Server, then the Storage Engine has to uncompress it. In
other words, every time data has to be passed to or from the Storage Engine, it has to be compressed or uncompressed. While this does take extra CPU overhead to accomplish, in many cases, the amount of disk I/O saved by compression more than makes up for the CPU costs, boosting the overall performance of SQL Server.

Here’s a simplified example. Let’s say that we want to update a row in a table, and that the row we want to update is currently stored on disk in a table that is using row-level data compression. When we execute the UPDATE statement, the Relational Engine (Query Processor) parses, compiles, and optimizes the UPDATE statement, ready to execute it. Before the statement can be executed, the Relational Engine needs the row of data that is currently stored on disk in the compressed format, so the Relational Engine requests the data by asking the Storage Engine to go get it. The Storage Engine (with the help of the SQLOS) goes and gets the compressed data from disk and brings it into the Buffer Cache, where the data continues to remain in its compressed format.

Once the data is in the Buffer Cache, the row is handed off to the Relational Engine from the Storage Engine. During this pass off, the compressed row is uncompressed and given to the Relational Engine to UPDATE. Once the row has been updated, it is then passed back to the Storage Engine, where is it again compressed and stored in the Buffer Cache. At some point, the row will be flushed to disk, where it is stored on disk in its compressed format.

Data compression offers many benefits. Besides the obvious one of reducing the amount of physical disk space required to store data—and the disk I/O needed to write and read it—it also reduces the amount of Buffer Cache memory needed to store data in the Buffer Cache. This in turn allows more data to be stored in the Buffer Cache, reducing the need for SQL Server to access the disk to get data, as the data is now more likely to be in memory than disk, further reducing disk I/O.

Just as data compression offers benefits, so it has some disadvantages. Using compression uses up additional CPU cycles. If your server has plenty to spare, then you have no problem. But if your server is already experiencing a CPU bottleneck, then perhaps compression is better left turned off.

Row‐Level Data Compression

The simplest method of data compression, row-level compression, works by:

• Reducing the amount of metadata used to store a row.
• Storing fixed length numeric data types as if they were variable-length data types. For example, if you store the value 1 in a bigint data type, storage will only take 1 byte, not 8 bytes, which the bigint data types normally takes.
• Storing CHAR data types as variable-length data types. For example, if you have a CHAR (100) data type, and only store 10 characters in it, blank characters are not stored, thus reducing the space needed to the store data.
• Not storing NULL or 0 values

Row-level data compression offers less compression than page-level data compression, but it also incurs less overhead, reducing the amount of CPU resources required to implement it.

Page Level Data Compression

Page-level data compression offers greater compression, but at the expense of greater CPU utilization. It works using these techniques:

• It starts out by using row-level data compression to get as many rows as it can on a single page.
• Next, prefix compression is run. Essentially, repeating patterns of data at the beginning of the values of a given column are removed and substituted with an abbreviated reference that is stored in the compression information (CI) structure that immediately follows the page header of a data page.
• And last, dictionary compression is used. Dictionary compression searches for repeated values anywhere on a page and stores them in the CI. One of the major differences between prefix and dictionary compression is that prefix compression is restricted to one column, while dictionary compression works anywhere on a data page.

The amount of compression provided by page-level data compression is highly dependent on the data stored in a table or index. If a lot of the data repeats itself, then compression is more efficient. If the data is more random, then little benefits can be gained using page-level compression.

Data Compression Demo

Data compression can be performed using either SQL Server Management Studio (SSMS) or by using Transact-SQL. For this demo, we will take a look at how you can compress a table that uses a clustered index, using SSMS.

Let’s say that we want to compress the Sales.Customer table (which has a clustered index) in the AdventureWorks database. The first step is to right-click on the table in SSMS, select “Storage,” and then select “Manage Compression.”

 
Figure 1: SSMS can be used to manage compression.

This brings up the Data Compression Wizard, displayed below.

Figure 2: The Data Compression Wizard, or Transact-SQL commands, can be used to manage data compression.

After clicking “Next,” the wizard displays the following screen, which allows you not only to select the compression type, but it also allows you to calculate how much space you will save once compression has been turned on.

Figure 3: Use this screen to select the compression type, and to calculate how much space will be saved.

First, let’s see how much space we will save if we use row-level compression on this table. To find out, click on the drop-down box below “Compression Type,” select “Row,” and then click “Calculate.”

Figure 4: For this table, row-level compression doesn’t offer much compression.

After clicking “Calculate,” the wizard runs and calculates how much space is currently being used, and how much space would be used after row-level compression. As we can see, very little space will be saved, about 1.6%.

Now, let’s see how much compression savings page-level compression offers us for this particular table. Again, I go to the drop-down menu under “Compression Type,” select “Page,” then press “Calculate.”

 
Figure 5: Page-level compression is higher than row-level compression.

After pressing “Calculate,” we see that compression has improved greatly, now saving about 20% space. At this point, if you should decide to turn on page-level compression for this table, click on the “Next” button.

Figure 6: The wizard allows you several options in which to turn on compression.

At the above screen, you can choose to perform the compression now (not a good idea during busy production times because the initial compression process can be very CPU and disk I/O intensive), schedule it to run later, or just to script the Transact-SQL code so you can run it at your convenience.

Once you have compressed this table (a clustered index), keep in mind that any non-clustered indexes that this table may have are not automatically compressed for you. Remember, compression is based on a per object basis. If you want to compress the non-clustered indexes for this table, you will have to compress each one, one at a time.

While this wizard helps you to see how much compression either method offers, it does not suggest which compression method should be used, nor does it recommend whether compression should be used at all for this object. As the DBA, it will be your job to evaluate each compressible object to determine if it should have compression enabled or not. In other words, you must decide if the benefits of compression outweigh the negatives.

Backup Compression

For years, there have been third-party programs that allow you to compress and speed up SQL Server backups. In most regards, the backup compression included with the Enterprise Edition of SQL Server is very plain vanilla. In fact, if you already are using a third-party backup program, I would suggest you continue using it, because SQL Server 2008 backup compression offers fewer features. In fact, the only option SQL Server 2008 backup compression offers you is to turn it off or on. That’s it.

SQL Server 2008 backup compression, like the third-party add-ons, compresses backups, which not only saves backup space, but it can substantially reduce backup times. Unlike data compression, there is very little downside to using backup compression, other than the additional CPU resources required to perform the compression (or decompression during a restore). Assuming that you perform backups during slower times of the day, the additional CPU resources used will not be noticeable.

The time and space savings offered by backup compression depends on the data in your database. If you are heavily using data compression in your databases, or are using Transparent Data Encryption, then using backup compression probably won’t offer you many benefits, as already compressed data, or encrypted data, is not very compressible.

Let’s take a brief look at how you turn on SQL Server 2008 backup compression. While our example will use SSMS, you can use Transact-SQL to perform the same task. To backup AdventureWorks, right-click on the database in SSMS, select “Tasks,” and then select “Back Up,” and the backup dialog box appears.

Figure 7: As with any backup, you can use the backup dialog box to make your selections.

Once you have selected your backup options, next click on “Options,” and the following screen appears.

Figure 8: Backup compression options are limited.

At the top of figure 8 are the standard backup options, while at the bottom of the screen you see the options for backup compression. Notice that you only have three choices.

The first option, “Use the default server settings” tells the backup to use the server’s default backup compression setting. In SQL Server 2008, there is a new sp_configure option called “backup compression default.” By default, it is set to have backup compression off. If you want, you can set this option so that backup compression is turned on by default. So if you choose the “Use the default server settings” option above, then whatever option is set for the “backup compression default” will be used for the backup.

The “Compress Backup” option turns backup compression on, and the “Do not compress backup” option turns it off. Both of these options override the “backup compress default” server setting, whatever it happens to be.

Once you have chosen your backup compression method, you proceed with the backup just like any other SQL Server backup.

If you need to restore a compressed backup, you don’t have to do anything special, it will uncompress itself automatically. Although you can only compress backups using the Enterprise Edition of SQL Server 2008, you can restore a compressed backup to any edition of SQL Server 2008. On the other hand, you cannot restore a compressed SQL Server 2008 backup to any previous version of SQL Server.

Summary

In this article, we have learned about the two forms of data compression, and about backup compression. While data compression might seem like a seductive new feature of SQL Server, I highly recommend that it is only used by experienced DBAs. While it offers lots of promise for increased performance, it can just as easily cause performance problems if misused. Backup compression, on the other hand, can be used by DBAs of all skill levels.

This is an excerpt from my free eBook, Brad’s Sure Guide to SQL Server 2008.

I think most of us are familiar with this situation: a SQL Server database is the backend of an OLTP (Online Transaction Processing) application, but you are required to allow users to run any reports they want on the production data, any time they want. This often results in long-running reports that negatively affect OLTP performance. Haven’t you ever wished you could limit the amount of hardware resources allocated to reporting, so that normal production activity is not affected?

In SQL Server 2008, you can. The Resource Governor, available only in the Enterprise Edition of SQL Server 2008, is a technology that allows you to selectively control how much CPU and memory resources are assigned to a particular workload. For example, the Resource Governor allows you to specify that no more than 20% (or any figure you designate) of CPU and/or memory resources can be allocated to running reports. When this option is turned on, then no matter how many reports are run, they can never exceed their designated resource allocation. Of course, this will reduce the performance of reporting, but at least now production OLTP activity won’t be as negatively affected by reports.

Currently, Resource Governor only works within the database engine. It does not work with Integration Services, Reporting Services, or Analysis Services.

In this chapter you will learn how you can use the Resource Governor to better prioritize and manage a SQL Server’s workload, how Resource Governor works under the hood, and how to configure it for use.

Uses for Resource Governor

Resource Governor is designed to help DBAs four different ways:

Managing Unpredictable Workloads
As in my reporting example above, it is often difficult to know how your SQL Server resources are being used. While OLTP activity might follow a predictable pattern, there is no knowing when a junior marketing executive will start running reports against your server. Resource Governor allows you to classify different types of loads on your server, which in turn allows you to control how server resources are assigned to a given activity. In SQL Server 2005 and earlier, queries fought amongst themselves to decide which one would grab the necessary resources first, and it was hard to predict who would win out. By using Resource Governor, I can instruct SQL Server to limit the resources a particular activity can access. In this way, I can ensure that my predictable OLTP performance is not hurt by unpredictable activity.

Putting Limits on Run-Away Queries
Closely related to the problem of managing unpredictable workloads is the difficulty of dealing with “run-away queries”. If you have been a DBA for very long at all, you will have seen queries that seem to take forever to run, tying up valuable and limited physical resources, and hurting the performance of other activity on your server. By limiting user or applications that have the potential for executing run-away queries, then run-away queries become much less painful because they can never use more resources than have been assigned to them.

Establishing Workload Priority
Most SQL Server instances have different demands placed on them throughout the day or week. For example, an OLTP server may need to be up 24/7 and maintain a specific service level. On the other hand, this same server may need to run SSIS jobs and maintenance jobs in order to properly function. When these jobs kick in, there is the potential that they can interfere with production work. Resource Governor allows you to allocate resources in such a way as to ensure that priority OLTP activity runs without interference from necessary maintenance jobs.

Prioritizing Preferred Users
For better or worse, Resource Governor allows you to assign specific users, or groups, higher priority than others, on an arbitrary basis. One of the inevitable consequences of this is that, as soon as managers hear about it, you may be asked to give priority to certain users over other users. Hopefully you can avoid this political battle, but you may not be able to. As George Orwell puts it in his novel, Animal Farm: “All animals are equal, but some animals are more equal than others”.

How Resource Governor Works

The best way to explain how the Resource Governor works is to walk through an example. Let’s assume we have a SQL Server 2008 instance, with a single database, that is designed to store data from an ERP (Enterprise Resource Planning) application. This is essentially a 100% pure OLTP application that must provide a specified service level 24/7. Let’s also assume that the reporting for this ERP application is not done through the application, but via a third-party reporting tool, directly against the database. In addition to running standard reports, the reporting tool permits users to run ad-hoc reports anytime they want. Essentially, this reporting can be considered an OLAP (Online Analytical Processing) activity.

This is a classic example of OLTP and OLAP activities running on the same server, against the same database, at the same time. As most of you know, this is a terrible architecture because it can result in non-time sensitive OLAP reporting blocking time-sensitive OLTP activity, potentially preventing you from attaining your specified service level for the ERP application. Unfortunately, as most of you will also know, this architecture is all too common. As the DBA, you want to use Resource Governor to ensure that your ERP application attains its specified service level, while at the same time, allowing reports to be run, but at a lower priority so they don’t interfere with OLTP activity. To accomplish this goal, you have decided that you want to limit both the amount of SQL Server CPU and memory resources used by the Reporting application to a maximum of 20% of what the server has available. Based on your research, you have determined that, with this restriction in place, your ERP application can consistently attain its service levels.

The figure presents a somewhat-oversimplified picture of this scenario. In this figure we can see two applications connecting to SQL Server. The first is our ERP application, called “ERP”, and the second is our reporting application, called “Reporting”:

In order for the Resource Governor to be able to allocate CPU and memory resources as you require, it must be able to differentiate between different workloads. It does this using a user-defined classification function, created using Transact-SQL. When a connection is made to SQL Server, Resource Governor will use the classification function to evaluate each connection to determine which application it came from: either the ERP or the Reporting application. This is why it is important to be able to identify each application as it connects to SQL Server, because the classification function uses the APP_NAME()1 function to tell the Resource Governor which application is connecting to the database.

Besides using the APP_NAME() function to differentiate one workload from another, Resource Governor can use other system functions, such as HOST_NAME(),SUSER_NAME(), SUSER_SNAME(), IS_SRVROLEMEMBER(), and IS_MEMBER().

Once an incoming connection has been classified, the connection is then routed to a particular workload group. Put simply, a workload group is a container that holds connection requests that match a set of SQL Server connections, as defined by the classification function. For example, the ERP application connections goes to a workload group named “ERP”, and the Reporting application connections go to a workload group named “Reporting.”

At this point, all we have done is to separate out the connections from each application. As yet, we still have not allocated any resources to these connections, and this is the next step.

Associated with every workload group is a resource pool. A resource pool represents the physical resources of a server. It is used to allocate the minimum and maximum amount of CPU and/or memory that is to be allocated to a specific type of SQL Server connection. For example, if you want to limit the connections from the Reporting application to no more than 20% of the available CPU and memory resources of the server, then you will configure a resource pool with this information.

In our example, there are two resource pools, one associated with the ERP workload group and the other with the Reporting workload group. The ERP resource pool permits connections in this group to use up to 100% of the available CPU and memory resources on the server. The Reporting resource pool limits connections in the Reporting workload group to no more than 20% of the server’s CPU and memory resources.

Once a connection has been classified and put into the correct workload group, then the connection is allocated the CPU and memory resources that have been assigned to it, and then the query is passed on to the query optimizer for execution. In our example, Reporting queries would be allocated resources in such a way that they would not use in excess of 20% of the CPU and memory resources when passed to the query optimizer for execution.

Given that we specified that the ERP application has the ability to use up to 100% of the available CPU and memory resources, you’re probably wondering what would happen if a request from the Reporting Application came through while the ERP application is using 100% of the resources. Under this condition, the Reporting connection would simply have to wait until resources become available for it. In this way, the ERP application get all the resources it needs to function properly, while allowing the Reporting application to continue to run, but at a lower priority.

Configuring Resource Governor

Unlike many other features in SQL Server, you cannot use SSMS to entirely configure and manage Resource Governor. You can either use a combination of Transact-SQL and SSMS, or you can use Transact-SQL only. To keep things as simple as possible, all of the following examples will be demonstrated using Transact-SQL only. Check out Books Online to see how SSMS can be used for some of the following steps.

Resource Governor only “kicks in” if there are resource contentions. For example, if the ERP workload happens to be small, and there are unused resources available, then the Reporting workload can use more than 20% of its allocated resources. But if the ERP workload is large, causing the ERP and Reporting workloads to fight for server resource, only then would the Resource Governor kick in and prevent the Reporting workload from using more than 20% of the available resources. For the rest of this chapter, we will be assuming that there is continuous resource contention and that the Reporting workload will be constrained by the Resource Governor.

Now, let’s go through an example of how to configure the Resource Governor, based on the Reporting example we’ve used throughout the chapter.

Creating Resource Pools

The first step is to create a resource pool, each for the ERP and the Reporting applications.

As you can see above, the CREATE RESOURCE POOL statement has a number of parameters.

They include:

• MIN_CPU_PERCENT: Allows you to specify the guaranteed average CPU bandwidth for all requests to the resource pool when there is CPU contention.
• MAX_CPU_PERCENT: Allows you to specify the maximum average CPU bandwidth that all requests for the resource pool when there is CPU contention.
• MIN_MEMORY_PERCENT: Allows you to specify the minimum amount of memory that is reserved for the resource pool that cannot be shared with other resource pools.
• MAX_MEMORY_PERCENT: Allows you to specify the total server memory that can be used by requests to the resource pool.

In the code above, I have created a resource pool named “poolERP” that will allow the ERP application to use up to 100% of the available server CPU and memory resources. In addition, I have specified that the “poolERP” be allocated a minimum of 80% of the total server CPU and memory resources available. This guarantees that “poolERP” will always have access to a minimum of 80% of the resources.

For “poolReporting”, I have specified that the maximum amount of resources that go to the Reporting application is 20%. Assuming there are resource contentions, the Reporting application’s resources will be constrained to this amount.

Creating Workload Groups

Next, I need to create the workload groups that will act as containers for the user connections that are defined in the classification user-defined function. During this same step, I also associate to each workload group one of the resource pools I just created.

I created a workload group called “wrkgroupERP” using the CREATE WORKLOAD GROUP statement, and I have associated it to the resource pool “poolERP”. In addition, I created a workload group called wrkgroupReporting that is associated to the resource pool “poolReporting”.

Creating the Classification Function

Next, I create the classification user-defined function that specifies which connections will be put inside each of the workload groups created in the previous step. Only one user-defined classification function can be created for each SQL Server instance, so when creating your own user-defined classification function, it is important to consider all the various connections that can be made to a SQL Server instance, and deal with them appropriately by assigning them to an appropriate workload group (and its associated resource pool). If a connection is not assigned to a specific workload group (and pool) by the classification function, then the connection goes to a default workload group (and pool). See Books Online to learn how to properly configure a default workload group and pool.

The user-defined classification function is created using the CREATE FUNCTION statement and is called “rgclassifier1()”. Inside this function, I specify the criteria on which SQL Server user connections are evaluated. For example, I have specified that if the APP_NAME() of a user connection equals “Reporting,” which is the application name of the Reporting application, then it should be added to the “wrkgroupReports” workload group. If the APP_NAME() of a user connection does not equal “Reporting,” then it should be added to the “wrkgroupERP” workload group.

Enabling Resource Governor

We are almost done, but we have a couple of maintenance tasks to perform before our Resource Governor will work. First, we need to run the following code, which assigns the “rgclassifier1″ function to the Resource Governor.

Second, we need to run the following code, which enables the Resource Governor.

At this point, the Resource Governor is turned on, and any time a report is run from the Reporting application, it will be limited to a maximum of 20% CPU and memory resources, while the ERP application will be able to use up to 100% of the available CPU and memory resources.

Summary

As you can imagine, there is a lot more to the Resource Governor than what I have discussed in this chapter. I have left out a lot of details, including additional configuration options, how to make changes after the fact, how to monitor if the Resource Governor is running properly, and troubleshooting information. If you are interested in learning more about the Resource Governor, I suggest you dive into Books Online and begin experimenting with it on a test server.

While Resource Governor offers many potential benefits, it also offers some potential pitfalls. For example, a misconfigured Resource Governor can not only hurt a server’s overall performance, it can potentially lock your server up, requiring you to use the Dedicated Administrator Connection (DAC) to attach to the locked up SQL Server in order to troubleshoot and fix the problem. Because of this, I highly recommend that you only use this option if you are an experienced DBA, and that you first test your configuration on a test server before rolling it out into production.

When I was a novice DBA and needed to run a new trace, I would go to New Trace within Profiler and create a new trace that I customized to collect the data I needed to identify and troubleshoot a particular problem. Once I had gathered the data I needed and fixed the problem, I would exit Profiler without saving the trace definition or the data I had collected. I didn’t see any need to save it once the immediate problem was resolved.

After creating many traces over time, I noticed a pattern. More often than not, I would recreate the same trace over and over again, each time from scratch. Another thing I noticed was that when I created a trace definition from scratch, I couldn’t always remember exactly how I had created the trace definition in the past, and I ended up wasting time experimenting with various events and data columns until I got what I needed. I was wasting a lot of time creating the same trace definitions over and over again.

Then I discovered Profiler templates. A Profiler template is a reusable Profiler trace definition that you can use again and again. Profiler templates were not new to Profiler, but as a novice DBA, I had never taken the time to learn how to use them properly.

Some of the many benefits to using Profiler templates are that:

• You save time because you don’t have to re-create trace definitions every time you need them. This is especially helpful if your trace definition is complex and includes many different events and data columns, which can be time-consuming to set up.
• Once a template has been created, you don’t have to remember which events, data columns, or other settings you need. This way, once you have perfected a trace definition, you don’t have to remember how to recreate it every time you need it.
• You can share Profiler templates with others, and vice versa.
• You can export a template’s trace definition so that you can use it with SQL Trace. This can save a lot of hand coding of the stored procedures needed to create a trace using SQL Trace.
• In SQL Server 2008, you can export a trace definition to create your own SQL Trace Collection Set for the Performance Data Collector, which allows you to collect and store historical trace data in a Management Data Warehouse database.

If you have used Profiler, you know that it comes with some sample Profiler templates. While I think they are handy for novice DBAs who are learning how to use Profiler, I have never found that they exactly meet my needs. Because of this, I create all of my own trace templates. Since the focus of this article is on creating your own trace templates, we won’t discuss the sample templates here. Instead, we will show you how you can save a great deal of time by creating your own custom Profiler templates you can use in your day-to-day work.

Creating a Profiler Template

There are essentially three different ways to create a Profiler template:

• Use the New Template option from within Profiler
• Create a template based on a pre-existing trace definition
• Create a template based on a pre-existing trace file.

While the New Template option might seem the easiest way to create a template, I have found in actual practice that creating a template from a pre-existing trace definition or trace file is more the norm, as least for me. All these options work fine. Just pick the one that best fits your needs.

Creating a Profiler Template Using the New Template Option

To create a Profiler template using the New Template option, start Profiler, then select File|Templates|New Template, and the General tab of the Trace Template Properties screen will appear.

Figure 1: The General tab of the Trace Template Properties tab is where you begin creating a trace template.

The first step is to select the type of server you want to trace. When you click on the Select server type drop-down box, you have five choices in SQL Server 2008. Not only can you trace data from SQL Server 2008, you can also trace data from SQL Server 2005 and SQL Server 2000. As you might expect, the reason you are given these choices is because each of these different versions offer a different set of events that can be traced. So when you select a server type, what you are telling Profiler is that you only want to select events that are available for the version of SQL Server you want to trace.

Figure 2: To create a Profiler template, you must select which server type you will be tracing.

Next, assign the template a name. While you can choose any name you want, I suggest you make it as descriptive as you can so that you can easily remember what the trace does.

When creating a new template, it will usually be created from scratch. But in some cases, you may want to copy a pre-existing Profiler template, and then modify it. This can come in handy if you already have a template that is close to what you need, so you only need to make a few changes, and then save the new Profiler template. In this case, select the checkbox next to Base new template on existing one, then select a pre-existing template from the drop-down box. Later, when you go to the Events Selection tab, you will see the settings from the pre-existing template, which can be easily changed.

The last option, Use as a default template for selected server type, doesn’t offer much value. If you select this option, then the Profiler template you are creating now will become the default template that is displayed when you create a new trace using the New Trace option. In most cases, you will use the drop-down box to select the trace template you want, so the default trace is irrelevant.

Now that we have completed the General tab of the Trace Template Properties screen, it’s now time to go to the Events Selection tab.

Figure 3: The Events Selection tab of the Trace Template Properties screen is where you create your trace definition.

Next, you create a trace definition, selecting the optimal combination of events, data columns, column filters and column organization that best meet the needs of your specific trace. Once you have made your selections, click on Save and the template is saved.

Figure 4: The word (user) appears after every Profiler template you create.

Now, when you use New Trace in Profiler to begin a new trace, the Profiler Templates you have created will be available in the drop-down box next to Use the template. See figure 4. Notice that all the Profiler templates you create will have (user) after their name. This is to differentiate them from the default templates that come with Profiler.

Creating a Profiler Template Using a Pre-Existing Trace Definition

As I mentioned earlier, I generally don’t use the New Template option to create templates. Instead, I prefer to go to New Trace in Profiler and create a new trace definition, just as if I were creating a temporary trace definition that I would discard after using it once. The reason I do this is because it allows me to experiment with various combinations of events, data columns, column filters, and column organizations; until I find the one single combination that works best for me. I experiment with my trace definition on a test or production server (carefully, of course, to prevent any unnecessary performance hit), which gives me real-time feedback on the kind of results the trace is producing. Using the New Template option does not give me the ability to test and experiment with my settings, so using the New Template option is best only if you know exactly what you want before you start.

Once I am satisfied with my trace definition, then I save the trace definition as a Profiler Template. Saving an existing trace definition as a Profiler template is fairly straight-forward, but there are a few quirks you need to be aware of.

If you have been experimenting with the trace, starting and stopping the trace, changing various settings, and starting and stopping the trace again, you must keep in mind that no trace can be running when you want to save the current trace definition as a Profiler template. So if your trace happens to be running when you are ready to save it as a Profiler template, you must stop the trace first.

At this point, you will probably have some captured Profiler events displayed on the screen. This is normal. But before you can save the trace definition as a Profiler template, you must first ensure that if you have used the Organize Columns option as part of your trace definition to group events, you must first turn this feature off. If you don’t, then you won’t be able to save the trace definition as a Profiler template, as the Save as|Trace Template option will be grayed out. So before you save the trace definition as a trace template, from within Profiler choose View and make sure that the Aggregated View option is deselected. Making this change won’t affect the grouping of future trace captures, as this change only affects how the results of the currently displayed trace results appear on the Profiler screen.

Figure 5: Before you can save a pre-existing trace definition as a Profiler template, you must ensure that Aggregated View is deselected.

Now you are ready to save the current trace definition as a Profiler template. To do this, select File|Save As|Trace Template from Profiler and the following screen appears.

Figure 6: Assign your Profiler template a name that accurately describes the template.

The Server type is filled in for you because Profiler already knows what server you have attached to. All you have to do is to give the Profiler template a descriptive name and click OK and the Profiler template is saved, ready for you to use.

Creating a Profiler template Using an Existing Trace File

In some cases, you may have created a trace definition and saved a trace file, but neglected to save the trace definition as a Profiler template before you exited Profiler. No problem. If you still want to turn the trace definition into a Profiler template, you can. All you have to do is to load the saved trace file into Profiler so that the results are displayed on the Profiler screen. Next, check to see that the Aggregated View option is not selected, then select File|Save As|Trace Template to save the Profiler template.

Modifying an Existing Profiler Template

On some occasions, you may want to change an existing Profiler template. To do so, start Profiler, and then select File|Templates|Edit Template. This displays the Trace Template Properties screen (see figure 1), which is the same screen that is used to create a new Profiler template. The only difference is that instead of entering a new name for the Profiler Template, you select an existing template from a drop-down box. Once you have selected the template to edit, make your changes, just as you did when creating the template in the first place, and click Save.

Exporting and Importing Profiler Templates

Lots of DBAs share their Transact-SQL scripts, but you rarely see DBAs share their Profiler templates. This is a shame, as sharing Profiler Templates is very easy to do, and like the sharing of Transact-SQL scripts, DBAs can save themselves a lot of time by not having to reinventing the wheel. In addition, the exporting and importing of Profiler templates makes it easy for you to move them from one computer to another.

Figure 7: You can export your Profiler Templates so that others can import them into their own copy of Profiler.

To export a Profiler template, start Profiler, and then select File|Templates|Export Template. At this point, the “Select Template Name” dialog box appears, where you select the template you want to export. Once it is selected, click on OK and a dialog box appears, allowing you to select where you want to export the Profiler Template to, along with the name you want to give it. Once you are done, click Save and the Profiler template is saved and can now be imported into another copy of Profiler.

To import a Profiler template, start Profiler, and then select File|Templates|Import Template. An Open File dialog box appears. Point to the Profiler template file you want to import, and select Open, and the Trace template is imported into this copy of Profiler.

While the Profiler import and export options are convenient ways to move Profiler templates from computer to computer, it is not your only option. If you like, you can just copy the physical Profiler template files themselves. Profiler Template files have an extension of .tdf, and for SQL Server 2008, are located in this folder: Drive_Letter:\Users\User_Name\AppData\Roaming\Microsoft\SQL Profiler\10.0\Templates\Microsoft SQL Server\100.

Scripting a Profiler Template for Use with SQL trace

While SQL Trace offers many performance benefits over using Profiler, many DBAs don’t use SQL Trace because they think they will have to write a lot of Transact-SQL code to implement it. Fortunately, this is not the case. Here’s the trick. Instead of hand-writing Transact-SQL code to create and implement SQL Trace definitions, use Profiler to write the code for you. How? First load an existing Profiler template, or create a new Profiler Template, then export the trace definition for the template to a Transact-SQL file, which you can then use to create a SQL Trace definition.

Figure 8: You can export Transact-SQL versions of your Profiler template to use with SQL Trace.

To do this, start Profiler, then either load an existing Profiler template, or create a new one. To export the Profiler template as a Transact-SQL file, select File|Export|Script Trace Definition|For SQL Server 2005-2008. A Save As dialog box appears, allowing you to name the file and to save it in any folder you prefer.

Below is a short example of the output produced by this option. Keep in mind that this example is a short one. Most of these scripts are much longer than this sample.

Figure 9: An example of a Transact-SQL file that can be used to create trace definitions using SQL Trace.

This code can be run as it is, or modified as needed, to create a trace definition for use with SQL Trace. It is much faster to create your SQL Trace definitions this way, than by typing them by hand.

Using Traces with the Performance Data Collector

In SQL Server 2008, a new feature called the Performance Data Collector was added. It has the ability to collect SQL Server-related performance data, store it in a database called the Management Data Warehouse, and then produce various performance reports based on the collected data.

By default, the Performance Data Collector includes three different data collection sets (Disk Usage, Query Statistics, and Server Activities) that are used to collect a wide variety of SQL Server 2008 performance data. One of the features of the Performance Data Collector is that you can create your own data collection sets, which allow you to decide what kind of data you want to collect and store in the Performance Data Collector’s Management Data Warehouse. For example, if you want, you can create your own custom data collection set to collect and store Profiler trace data. Once the data has been collected and stored in the Management Data Warehouse, you can then create queries or Reporting Services reports to analyze the data you have collected.

There are two ways to create your own custom data collection set to collect and store Profiler trace data. You can either write a custom Transact-SQL script from scratch, or you can let Profiler write the script for you. Let’s see how Profiler can do this for us.

First, ensure that the Data Collector has been properly configured and is running properly. Next, start Profiler and load an existing Profiler template, or create a new Profiler Template. Keep in mind that the SQL Trace Data Collection Set will be based on your Profiler template, so choose an appropriate one.

Figure 10: Export a Profiler Trace to a Performance Data Collector SQL Trace Collection Set.

Our next step, as shown in Figure 10 is to convert the Profiler template into a Transact-SQL file that can be executed later to create the SQL Trace Collection Set. To do this, select File|Export|Script Trace Definition|For SQL Trace Collection Set, and a Save As dialog box appears, allowing you to name the file and to save it in any folder you prefer. Once the script has been saved, it can be opened in SSMS. For example, the Transact-SQL script that is created looks similar to this (it has been truncated because of its length).

Figure 11: Profiler can create a SQL Trace Collection Set for you automatically.

Before you can run this script and create the SQL Trace Collection Set for the Performance Data Collector, you need to make two changes in the code. If you look through the generated code, you will see these place holders:

‘SqlTrace Collection Set Name Here’

‘SqlTrace Collection Item Name Here’

You will need to replace these place holders with descriptive names. Once the code is changed and executed, you will see the new SQL Trace Collection Set in SSMS, along with the three default collection sets that come with SQL Server 2008. At this point, you can enable the new custom collection set, and it will begin collecting Profiler trace data based on the criteria you specified in the Profiler template you used as the basis for creating it. If you like, you can create as many different SQL Trace Collection Sets as you want, with each one based on a different Profiler template.

One warning about creating your own custom SQL Trace Collection Sets—they can use a lot of SQL Server resources and disk space when enabled. To minimize this impact, ensure that the Profiler templates that you use to create your SQL Trace Collection Sets only collect the minimum number of events and data columns you need. In addition, only enable SQL Trace Collection Sets as needed; don’t run them all the time.

Summary

In this chapter, we have taken a look at many different ways Profiler traces can be created and used. Whether you are creating templates for use with Profiler, for use with SQL Trace, or for use with the Performance Data Collector, taking advantage of Profiler traces can make you a much more productive DBA.

You can learn more about how to use Profiler by downloading my free e-book: Mastering SQL Server Profiler.

The advice I generally give to them is to not reinvent the wheel, but to see what others have done, and to emulate them, especially to those DBAs with lesser experience. For example, the following websites offer T-SQL database maintenance scripts that are freely available for others to use with little or no modification, or to use as a learning tool in order to see how other DBAs have tackled this issue.

ola.hallengren.com
sqlfool.com/2009/06/index-defrag-script-v30
www.grics.qc.ca/YourSqlDba/index_en.shtml

All of the scripts from the above websites are very good, and are highly recommended. Of course, I don’t recommend you run any free script on any of your production servers as they are. If you download any of the above T-SQL scripts, first take some time to understand how they work, and see if they are appropriate for your needs. Often, you may need to modify them for your specific circumstances. In addition, you will want to test any script on a test server before rolling them out into production.

If you know of other useful database maintenance scripts available free on the web, please feel free to share their URLs here.