Microsoft SQL Server 2008 R2 Unleashed- P158 ppt

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 t

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 Managementnode in Object Explorer and expand the Resource Governor

node to display the Resource Poolsfolder

2 Expand the node of the resource pool where the workload group is defined to

display the Workload Groupsfolder

FIGURE 40.6 Moving a workload group in SSMS

Modifying Your Resource Governor Configuration

3 Expand the Workload Groupsfolder 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 GROUPcommand:

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 workwork-load group or moving it to a

differ-ent resource pool will fail when the ALTER RESOURCE GOVERNOR RECONFIGUREstatement 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

theALTER RESOURCE GOVERNOR RECONFIGUREstatement

Explicitly stop sessions in the affected group by using the KILL command and then

rerun the ALTER RESOURCE GOVERNOR RECONFIGUREstatement

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 GROUPcommand for that

workgroup After re-creating the workload group, run the ALTER RESOURCE GROUP

RECONFIGUREcommand again, and the workload group is restored

Deleting Resource Pools

To drop a resource pool in SSMS, follow these steps:

1 Expand the Managementnode in Object Explorer and expand the Resource Governor

node to display the Resource Poolsfolder

2 Expand the Resource Poolsfolder 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

To drop a workload group using T-SQL, use theDROP RESOURCE POOLcommand:

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 GOVERNORcommand and passing it a

differentCLASSIFIER_FUNCTIONname 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

Summary

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

This page intentionally left blank

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 bleedbleed-ing, 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;

Data Structures (DB, TBL, IDX)

Files

Application Layer Client/Browser Layer

File Systems Volumes

Operating Systems

External Communication Layer (Internet, EDI, FTP, WS)

Services Layer (WS, DS)

Architecture Layers

Web Tier

Memory/RAM

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

Primary Performance and Tuning Handles

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

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)

Cache

SQLOS

Devices/Files Partitions

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 tempdbis

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 transacopera-tions 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

A Performance and Tuning Methodology

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