Microsoft SQL Server 2008 R2 Unleashed- P158 ppt

ptg
1514
CHAPTER 40 Managing Workloads with the Resource Governor
ALTER RESOURCE GOVERNOR RECONFIGURE
GO
You can also move a workload group to another resource pool in SSMS using the Resource
Governor Properties page. Click the Resource Pool name in the Resource Pools grid; then
right-click on Workload Group in the Workload Groups grid and select Move To (see Figure
40.6). This brings up the Move Workload Group dialog, which lists the available resource
pools the workload group can be moved to. Select the desired resource pool and click OK.
Why move a workload group to a different resource pool? You might decide that a work-
load group should be in a resource pool that has different configuration settings, or you
might want to move workload groups out of a resource pool so that you can drop the
resource pool.
Deleting Workload Groups
You can delete a workload group or resource pool by using SQL Server Management Studio
or T-SQL. To drop a workload group in SSMS, follow these steps:
1. Expand the
Management node in Object Explorer and expand the Resource Governor
node to display the Resource Pools folder.
2. Expand the node of the resource pool where the workload group is defined to
display the Workload Groups folder.
FIGURE 40.6 Moving a workload group in SSMS.
ptg
1515
Modifying Your Resource Governor Configuration
40
3. Expand the Workload Groups folder to list the workload groups.
4. Right-click the workload group you want to drop and select Delete.
5. In the Delete Object window, the Workload Group is listed in the Object to Be
Deleted list. Click OK to confirm the deletion.

To drop a workload group using T-SQL, use the
DROP WORKLOAD GROUP command:
DROP WORKLOAD GROUP OLTPWG1
ALTER RESOURCE GOVERNOR RECONFIGURE
go
You cannot drop a workload group if there are any active sessions assigned to it. If a work-
load group contains active sessions, deleting the workload group or moving it to a differ-
ent resource pool will fail when the
ALTER RESOURCE GOVERNOR RECONFIGURE statement is
called to apply the change. The following options provide a way to work around this
problem:
. Wait until all the sessions from the affected group have disconnected and then rerun
the
ALTER RESOURCE GOVERNOR RECONFIGURE statement.
. Explicitly stop sessions in the affected group by using the KILL command and then
rerun the
ALTER RESOURCE GOVERNOR RECONFIGURE statement.
. Restart SQL Server. When the restart process is complete, the deleted group will
not be created, and a moved group will automatically use the new resource pool
assignment.
NOTE
If an attempt to reconfigure Resource Governor fails after dropping a workload group
because of active sessions and you change your mind about dropping the workload
group, you can restore it by rerunning the
CREATE WORKLOAD GROUP command for that
workgroup. After re-creating the workload group, run the
ALTER RESOURCE GROUP
RECONFIGURE command again, and the workload group is restored.
Deleting Resource Pools
To drop a resource pool in SSMS, follow these steps:

1. Expand the Management node in Object Explorer and expand the Resource Governor
node to display the Resource Pools folder.
2. Expand the
Resource Pools folder to list the resource pools defined.
3. Right-click the resource pool you want to drop and select Delete.
4. In the Delete Object window, the resource pool is listed in the Object to Be Deleted
list. Click OK to confirm the deletion.
ptg
1516
CHAPTER 40 Managing Workloads with the Resource Governor
To drop a workload group using T-SQL, use the
DROP RESOURCE POOL command:
DROP RESOURCE POOL OLTPPOOL
ALTER RESOURCE GOVERNOR RECONFIGURE
go
You cannot drop a resource pool if any workload groups are still assigned to the resource
pool. You need to drop the workload group or move it to another resource pool first.
Modifying a Classification Function
If you need to make a change to the classification function, it’s important to note that the
function cannot be dropped or altered while it is marked as the classification function for
the Resource Governor. Before you can modify or drop the classification function, you first
need to disable Resource Governor. Alternatively, you can replace the classification func-
tion with another by running the
ALTER RESOURCE GOVERNOR command and passing it a
different
CLASSIFIER_FUNCTION name. You can also simply disable the current classifier
function by executing the following command:
ALTER RESOURCE GOVERNOR
WITH (CLASSIFIER_FUNCTION = NULL);
ALTER RESOURCE GOVERNOR RECONFIGURE;

The sample classification function shown in Listing 40.1 uses a simple case expression to
determine the workload group based on only two login IDs. If you have a more complex
set of rules to apply or want to be able to make changes more dynamically than having to
replace the classification function each time you need to make a change, you can define
your classifier function to look up the workload group names from a database table, rather
than hard-coding the workload group names and matching criteria into the function.
Performance should not be greatly affected when accessing the table to look up the work-
load group. The reason is that the table likely won’t be very large and should remain
cached in the buffer pool because it’s being accessed repeatedly every time a connection is
made to SQL Server.
ptg
1517
Summary
40
Summary
Resource Governor offers many potential benefits, primarily the capability to prioritize SQL
Server resources for critical applications and users and preventing “runaway” or unexpected
queries from adversely impacting SQL Server performance significantly. It fits in with
Microsoft’s goal of providing predictable performance for your SQL Server applications.
Resource Governor also offers some potential pitfalls, however. For example, a misconfig-
ured Resource Governor can not only hurt a server’s overall performance, but can poten-
tially lock up your server, requiring you to use the dedicated administrator connection to
attach to the locked-up SQL Server to troubleshoot and fix the problem. Therefore, it is
recommended that you implement Resource Governor only if you are an experienced DBA
and have a good understanding of, and familiarity with, the workloads executed against
your SQL Server databases. Even then, it’s imperative that you test your configuration on a
test server before rolling it out into production.
Also, after implementing a Resource Governor configuration, you should monitor your
SQL Server performance to make sure the configuration has the desired effect. The next
chapter, “A Performance and Tuning Methodology,” provides guidelines for monitoring

and tuning the performance of your SQL Server environment.
ptg
This page intentionally left blank
ptg
CHAPTER 41
A Performance and
Tuning Methodology
IN THIS CHAPTER
. The Full Architectural
Landscape
. Primary Performance and
Tuning Handles
. A Performance and Tuning
Methodology
. Performance and Tuning Design
Guidelines
. Tools of the Performance and
Tuning Trade
Yes, you can tune your SQL Server implementation to
perform optimally for you. However, random jabs at bleed-
ing arteries may stop immediate bleeding, but the patient
will die before too long. Forgive the graphic analogy, but all
too often, performance and tuning is crudely attempted
with extremely serious oversights and very often extremely
poor results. Usually, you can avoid this outcome if you
follow basic, orderly steps when tuning your SQL Server
platform and understand the complete SQL Server ecosys-
tem. This chapter describes a repeatable performance and
tuning methodology that has been refined over the past
decade during hundreds of performance and tuning

consulting engagements on SQL Server implementations
running at some of the largest companies on the planet.
Good performance really starts when you design it into
your implementation from the beginning. Even the best-
designed applications require fine-tuning over time.
Unfortunately, dealing with performance is very often put
off or not considered at all until it becomes a problem in
production!
As a part of introducing a formal performance and tuning
approach, we describe the overall architectural landscape of
most applications and how SQL Server sits within this envi-
ronment. You should keep in mind that addressing perfor-
mance and tuning of your SQL Server implementation is a
layered exercise and all layers must be considered; all layers
factor into your results. We also discuss an assortment of
design considerations (guidelines) that you should incorpo-
rate into your designs from the beginning. And lastly, we
outline several tools of the trade when focusing on perfor-
mance and tuning. Some are out-of-the-box from Microsoft;
ptg
1520
CHAPTER 41 A Performance and Tuning Methodology
Data Structures (DB, TBL, IDX)
Files
Application Layer
Client/Browser Layer
File Systems Volumes
Operating Systems
Encryption
Message/Data Buses

External Communication Layer
(Internet, EDI, FTP, WS)
Security
Services Layer (WS, DS)
Architecture Layers
Web Tier
Network
Memory/RAM
SQL Server
Physical Disk/Sectors
Partitions/Devices
Physical Machine
( or Virtual Machine)
FIGURE 41.1 The overall architectural landscape of a SQL Server implementation.
others are from third-party providers that allow you to visualize and rapidly isolate your
performance issues as they are happening. A number of other chapters in this book are
dedicated to the actual performance tuning of a SQL Server instance, SQL tables, and SQL
statements. This chapter provides you with a framework and ordered process to attack a
SQL Server–based environment from top to bottom that will yield thorough and complete
results. No more just stopping the bleeding artery. We want to cure the patient!
The Full Architectural Landscape
As mentioned previously, understanding all layers of your implementation is critical to
performance and tuning of your SQL Server application. Even the smallest aspect, such as
locking, could be at the heart of your poor performing system. You just don’t truly know
until you have evaluated all layers and all interactions that come into play in your SQL
Server application. Figure 41.1 provides an overall perspective of all the layers of the archi-
tecture that you need to better understand and potentially tune.
As you can see in Figure 41.1, your SQL Server environment sits at the heart of many
different layers. They include the hardware (either physical or virtual footprint), memory,
physical disks/devices, operating system, file systems, and database, to name a few. Quite

often, a combined effort is needed between the infrastructure, application, database, and
network teams to deliver the final, well-tuned SQL Server environment. If you can under-
ptg
1521
Primary Performance and Tuning Handles
41
stand that you have not just a database problem or just an application design problem,
you will likely be more successful at delivering “optimal” results when tuning your envi-
ronment. You can treat Figure41.1 as a checklist that you make sure you cover when doing
performance and tuning. Then, when you make a change in one layer, you can make sure
you test the full impact throughout all the other layers. Often, when you solve one issue
in one layer, other issues bubble up to the surface of another layer.
Primary Performance and Tuning Handles
Now, let’s peel the onion a little more into the core architecture of SQL Server itself. Figure
41.2 shows the primary components within a SQL Server instance. The major issues to
worry about at the instance level are the caches that comprise the memory pool and the
number of CPUs available for processing to SQL Server itself (shown as white boxes, not
dark ones). Of course, the disk I/O subsystem and files have to be carefully evaluated and
used effectively as well. All other darker boxed items such as the SQL Server kernel are not
within your control.
The rule of thumb here is to treat these instance-level resources as “scarce” resources and
monitor the CPU and disk I/O for their saturation levels (never exceeding 80%) and
memory for its hit ratio and capability to service the desired amount of concurrent work
SQL Server Architecture
Server Net-libs DLLs
SQL Server Kernel (code)
Open Data Services
Stack Space Variable code
BufferPool
User Connection Structures

System Data Structures
Plan Cache
Buffer
Cache
Other
Servers
Web-Based
Clients
Windows
Clients
Windows
Clients
Windows
Clients
CPU
CPU
.
.
.
Disk/Files
Log Cache
FIGURE 41.2 SQL Server instance architecture (memory, CPU, I/O).
ptg
1522
CHAPTER 41 A Performance and Tuning Methodology
Cache
Optimizer
SQLOS
Devices/Files
Partitions

Tables
Materialized Views
Indexes
SQL Statements
CPU (s)
FIGURE 41.3 SQL Server handles available for performance tuning.
at or better than the service-level requirements of your end users (even during peak
usage times).
Figure 41.3 shows a more readily recognizable combination of “handles” that are the
major areas a human can adjust to achieve optimal performance.
We’ve already mentioned CPU, cache/memory, and disk I/O; these and all the other
handles listed in Figure 41.3 work together and must be considered together when doing
performance and tuning. A change in a SQL statement affects what the optimizer (which
makes decisions regarding how data is accessed in SQL Server) will do to satisfy the query.
The correct index allows the query to get data the most effective way. The correct table
design drastically affects updates, deletes, inserts, and reads. The number of CPUs available
to SQL Server can invoke parallelism. What work is done in
tempdb (and where tempdb is
located) can improve performance by 1000%. The index and table level fill factor (free
space), number of page splits, and page allocations being done within your databases can
hurt you by 1000%. Hints to the optimizer can change the way execution is handled. And
other issues such as materialized views, partitions, and file placement (at the disk subsys-
tem level) directly contribute to the overall performance of every SQL execution. Even
something as simple as locking (or deadlocks) and the consistent order of update opera-
tions within transactions can make or break an entire SQL Server implementation.
We explain a bit more of what to look for with the primary handles in the guideline
section later. For most development or production support teams, tackling performance
and tuning for SQL Server can truly be overwhelming. The next section describes an
orderly performance and tuning methodology that most should be able to follow and use
to yield great results.

A Performance and Tuning Methodology
A methodology is a process or procedure, for example, designed for repeatability that has
been proven to work for a certain paradigm. In our case, it is a repeatable and thorough
SQL Server–focused performance and tuning process. We generalized this focused process
into a repeatable methodology and identified two possible paths that can be taken
through it: one for a new SQL Server implementation that will have performance and
tuning designed into it from the start and another for performance and tuning of an
ptg
1523
A Performance and Tuning Methodology
41
Performance & Tuning
Methodology
Code & Test
Implementation
Deploy
Development
Life Cycle
Phases
Close
Construct
Design
Initiate
Isolate &
Monitor
New
New
Existing
Existing
System Test &

Acceptance
Identify &
Design
Prototype
Assessment
FIGURE 41.4 Generalized performance and tuning methodology for SQL Server.
existing SQL Server implementation (one that needs to be scaled out or rescued—or in
other words, “optimized”).
Figure 41.4 illustrates this overall performance and tuning methodology within a tradi-
tional waterfall development methodology context. But, as you will see, it is very iterative
in nature and can be followed within any organization’s formal development methodology.
Notice the two distinct paths labeled “New” and “Existing” indicated by the dashed
arrowed lines. As mentioned earlier, one path is for new implementations, and the other is
for existing implementations. The following sections describe each of these distinct paths
through the methodology.
Designing In Performance and Tuning from the Start
If you are just starting to design and develop a new SQL Server–based implementation, it
would be great to factor in all possible performance and tuning considerations from the
beginning. In real life, this is rarely done primarily because much is unknown from a data
access, number of users, and table design point of view. However, you are not precluded
from designing in certain common performance and tuning considerations, nor are you
precluded from incorporating a performance and tuning “prototyping” step in your
methodology so that you have known and predictable results of what you are building “as
you go” and not “at the end.” As you have no doubt experienced (or heard many times),
changing something after it is built is more expensive than if you had considered it much