Microsoft SQL Server 2008 R2 Unleashed- P149 pptx

These tools include SQL Server Management Studio SSMS Activity Monitor, Data Collector, Extended Events, Windows Performance Monitor and its various counters, a few SQL Server DBCC optio

CHAPTER 38 Database Design and Performance

Cache Performance

One of the reasons SANs can offer superior performance to locally attached storage is they

typically are configured with a significant amount of cache space This is normally a good

thing However, because the SAN provides storage services to multiple servers, the

avail-able cache space is shared as well If there is significant activity against the SAN, there can

be extensive cache turnover This means that the large cache space may not always be

available to SQL Server, so some of the performance gains provided by the large cache are

not realized

NOTE

Cache turnover in a SAN can lead to widely varying physical I/O response times When

SQL Server performs I/O against the SAN, it’s considered a physical I/O whether or not

the data resides in the SAN cache When the physical I/O performance for SQL Server

is measured, the performance can be orders of magnitude faster when the data is

residing in the SAN cache than when the data has to be physically read from the disks

in the SAN It is important that you perform benchmarking with your SAN vendor to

ensure that your SAN cache will be adequate to provide optimal database performance

Avoid Disk Drive Contention

SAN storage is divided into LUNs Servers attached to the SAN recognize one or more of

these units as a disk partition or drive However, these LUNs may share the same disk

drives For example, consider six 100GB drives in the SAN Theoretically, this could be

divided into two LUNs of 300GB each Although each LUN may be allocated to different

SQL Servers, some of the drives shared between the two LUNs could experience twice the

I/O from both servers than if the drives were dedicated to a single server To avoid this

situation, most SANs support zoning, which allows the SAN administrator to dedicate

entire disks in the SAN to your LUN to isolate the I/O on the drives in the LUN to your

SQL Server

In addition, you should try to ensure that your database log files are on a LUN consisting

of dedicated drives separate from the LUN (or LUNs) used for your SQL Server data files

Log files typically are written sequentially, unlike data files where data access tends to

consist more of random reads and writes Sharing a LUN between data files and log files

generally does not provide optimal IO performance Unfortunately, your SAN administrator

may not permit you to dedicate a separate disk or set of disks to your log files An

alterna-tive may be to place your log files on a local RAID 1 or RAID 10 array However, you might

want to benchmark to determine which solution provides better performance because the

caching capabilities of the SAN may offset the potential drive contention in the SAN

Additional SAN Performance Considerations

Some SAN administrators may attempt to convince you to use RAID 5 for all data and log

files Before following their advice, you should benchmark the system using a

representa-tive load to ensure that RAID 5 will offer the best performance for your log files, tempdb,

and any write-intensive filegroups

ptg Summary

You should also ensure that the hardware your SQL Server system uses to connect to the

SAN provides optimal performance Make sure that you have the correct and most

up-to-date drivers for your SAN components If you can, consider using multiple high-speed

host bus adapters (HBAs) to connect your servers to your SAN to avoid the I/O contention

that can occur with a single HBA If you do use multiple HBAs, try to ensure they are on

different buses to prevent bus saturation and that the HBAs are plugged into the PCI slots

offering the highest speed

SANs are complex, and delivering optimal performance for a SQL Server solution using a

SAN is challenging Benchmark your SQL Server to determine if bottlenecks exist with

your SAN Be willing to work with your SAN administrator or vendor to fine-tune your

SAN configuration and carefully consider and benchmark any recommendations they may

make to ensure optimal performance

Summary

A good database design is the best place to start to ensure that your database application

runs smoothly This chapter outlined some of the fundamental aspects a database design

that you should consider If you have the luxury of designing the database system from the

ground up, be sure to use what you learned in this chapter in the early stages of

develop-ing your database system If you inherit a database with an inadequate design, the design

principles described in this chapter still apply, but they may be a bit harder to implement

The next chapter, “Monitoring SQL Server Performance,” delves into the tools and

tech-niques you can use to evaluate the performance of your SQL Server instance Monitoring is

tightly linked to database design and is essential in achieving optimal database performance

This page intentionally left blank

CHAPTER 39 Monitoring SQL Server

Performance

IN THIS CHAPTER

What’s New in Monitoring SQL Server Performance

Performance Monitoring Tools A Performance Monitoring Approach

No SQL Server implementation is perfect out of the box

As you build and add SQL Server–based applications to your

server, you should take an active approach to monitoring

performance You also need to keep reevaluating as more

and more load is placed on your servers and data volumes

grow This chapter focuses on SQL Server monitoring and

leaves monitoring of the other types of servers (including

application servers, backup servers, domain controllers, file

and print servers, mail/messaging servers, and web servers)

for the specialists in those areas

You can monitor many things on your SQL Server platform,

ranging from physical and logical I/O to the network

packets passing between the server and your client

applica-tions To make this monitoring task a little cleaner, this

chapter classifies the key monitoring elements into

network, processors, memory/cache, and disk systems

Figure 39.1 shows how these key elements interrelate with

SQL Server 2008 and Windows The aspect of utilization—

whether CPU utilization, memory utilization, or something

else—is at the center of most of the discussions in this

chapter The important concept to remember is how to

monitor or measure utilization and how to make changes to

improve this utilization because you are still not in a perfect

world of infinite CPU power, infinite disk space, infinite

network load capability, and infinite memory

It is essential that you know which tools you can use to get

this valuable information These tools include SQL Server

Management Studio (SSMS) Activity Monitor, Data

Collector, Extended Events, Windows Performance Monitor

and its various counters, a few SQL Server DBCC options,

SQL Server Profiler, and a variety of SQL Server dynamic

CHAPTER 39 Monitoring SQL Server Performance

Windows Server

SQL Server 2008

Processors Memory/Cache Disk System

proces-sors, memory/cache, and disks

management views (DMVs) Although many other third-party products are available for

performance monitoring, some of which do a fantastic job of gathering and aggregating

performance data from a number of sources, there is just not enough space in this chapter

to cover all the various third-party tools and their features Instead, this chapter focuses

on the performance monitoring tools provided out of the box with SQL Server 2008

What’s New in Monitoring SQL Server Performance

Performance tuning and troubleshooting are time-consuming tasks for the administrator

To help provide insights quickly into performance issues, SQL Server 2008 provides a

number of new and enhanced features for monitoring SQL Server performance

In SQL Server 2005, the Activity Monitor in SSMS showed only the current running

processes and the locks currently being held in the system In SQL Server 2008, the

Activity Monitor has been enhanced and now provides a graphical overview of SQL Server

activity, as well as information on active user tasks, resource waits, data file I/O, and the

recent most expensive queries Unfortunately, the new information and fancier interface

come with the loss of the useful lock monitor that was available in SQL Server 2005

Activity Monitor

SQL Server 2008 also introduced a new performance monitoring tool called the Data

Collector The Data Collector gathers performance data from multiple sources and stores

the data in the management data warehouse (MDW) The MDW is simply a database

setup within a SQL Server instance where the data is collected for subsequent viewing

and reporting

SQL Server Extended Events is a general event-handling system for the server The

Extended Events infrastructure is a lightweight mechanism that supports capturing,

filter-ing, and acting on events generated by the server process Extended Events is designed to

be a foundation that users can configure to monitor and capture different types of data,

including performance data It’s a flexible and powerful way to provide a low granular

level of information about the server system Events can be used to diagnose runtime

ptg Performance Monitoring Tools

problems by adding contextual data, such as Transact-SQL (T-SQL) call stacks or query

plan handles, to any event Events can be captured into several different output types,

including Event Tracing for Windows (ETW), which enables you to correlate events with

operating system and application events and performance counters

SQL Server 2008 also introduces a number of new dynamic management views to simplify

retrieval of information that can be helpful with memory troubleshooting These new

DMVs are described in more detail later in this chapter

Performance Monitoring Tools

In prior versions of SQL Server, the tools available for monitoring SQL Server performance

were somewhat limited Yes, you had the Windows Performance Monitor, Activity

Monitor, SQL Server Profiler, and SQL Trace, but performing in-depth performance

moni-toring usually required the purchase of third-party tools to collect, monitor, and view

performance information in a useful way

SQL Server 2008 provide a number of tools you can use to collect, analyze, monitor, and

report performance-related data The usual old-timers such as SQL Server Profiler and

Database Engine Tuning Advisor still exist and are available to you, but SQL Server 2008

also includes a new Activity Monitor, the Data Collector and management data

ware-house, SQL Utility, and SQL Server Extended Events

NOTE

For a discussion on using SQL Server Profiler for monitoring and analyzing

perfor-mance, see Chapter 6, “SQL Server Profiler.” For more information on the Database

Engine Tuning Advisor, see Chapter 55, “Configuring, Tuning, and Optimizing SQL Server

Options.” In addition, the Activity Monitor is already covered in detail in Chapter 4,

“SQL Server Management Studio,” so detailed information on Activity Monitor is not

provided in this chapter

The Data Collector and the MDW

As mentioned previously, SQL Server 2008 introduces a new performance monitoring tool

called the Data Collector The Data Collector is designed to collect performance-related

data from multiple sources from one or more SQL Servers, store it in a central data

ware-house, and present the data through reports in SQL Server Management Studio The main

purpose of the Data Collector is to provide an easy way to automate the collection of

criti-cal performance data The Data Collector gathers information from Windows performance

counters, snapshots of data grabbed from dynamic management views, and details on disk

utilization

Data collection can be configured to run continuously or on a user-defined schedule You

can adjust the scope of data collection to suit the needs of your test and production

envi-ronments The Data Collector provides a single central point for data collection across

ptg CHAPTER 39 Monitoring SQL Server Performance

SQL Agent

SSIS

Data Collection

Sets and Items

MDW

SQL Server Mgmt Studio SSMS Reports msdb

Monitored SQL Server

Client Workstation

SSIS

Pack

Job

Definitions

Audit and

History

Temporary File Cache

Data Collector Runtime

your database servers and applications and, unlike SQL Trace, is not limited to collecting

performance data only

The Data Collector feature consists of the following components:

Data collection sets—These are the definitions and scheduled jobs for collecting

performance data They are stored in the msdbsystem database

The Data Collector runtime component—This standalone process, called

Dcexec.exe, is responsible for loading and executing the SSIS packages that are part

of a collection set

SQL Server Integration Services (SSIS) packages—These packages are used to

collect and upload the data

The management data warehouse database—This is a relational database where

the collected data is stored It also contains the views and stored procedures needed

for collection management

MDW Reports—These reports are built in to SSMS for viewing the collected

perfor-mance data

Figure 39.2 provides an overview of the Data Collector architecture and how the various

components interact

ptg Performance Monitoring Tools

NOTE

The Data Collector is not a zero-impact monitoring solution It incurs approximately a

2% to 5% performance hit on the servers where it’s collecting data This performance

hit is mainly on the CPU

Data Collection Sets

A data collection set is group of collection items A collection set is the unit of data collection

that a user can interact with through the user interface Data collection sets are defined

and deployed on a SQL Server 2008 instance and can be run independently of each other

Each collection set is run by a SQL Server Agent job or jobs, and data is uploaded to the

management data warehouse on a predefined schedule

Out of the box, SQL Server 2008 provides the following built-in system data collection sets

and reports:

Disk Usage—Collects local disk usage information for all the databases of the SQL

Server instance This information can help you determine current space utilization

and future disk space requirements for disk capacity planning

Server Activity—Collects SQL Server instance-level resource usage information like

CPU, memory, and I/O This information can help you monitor short-term to

long-term resource usage trends and identify potential resource bottlenecks on the

system It can also be used for resource capacity planning

Query Statistics—Collects individual statement-level query statistics, including

query text and query plans This information can help you identify the top

resource-consuming queries that may need performance tuning

The definition of the system collection sets cannot be modified However, you can define

your own collection sets or define your own custom reports for this data

Data Collector Runtime Component

The Data Collector runtime component is invoked by a standalone process called

Dcexec.exe This component manages data collection based on the definitions provided

in a collection set The Data Collector runtime component is responsible for loading and

executing the SSIS packages that are part of a collection set

A collection set can be run in one of the following collection and upload modes:

Noncached mode—Data collection and upload are executed on the same schedule.

The packages collect data as scheduled and then immediately upload data

Cached mode—Data collection and upload are performed on different schedules.

The collection package continues to collect and cache data until stopped Data is

uploaded from the local cache according to the schedule specified by the user

CHAPTER 39 Monitoring SQL Server Performance

NOTE

The Data Collector runtime component can perform only data collection or data upload

It cannot run these tasks concurrently

SSIS Packages

The Data Collector is implemented as SSIS packages that are invoked by the Data Collector

runtime component These packages can be configured to run manually, continuously, or

scheduled as SQL Server Agent jobs to periodically collect and upload data to the

manage-ment data warehouse

The two most important tasks for the SSIS packages are data collection and data upload

These tasks are carried out by separate packages A collection package gathers data from a

data provider and keeps it in temporary storage An upload package reads the data in

temporary storage, processes the data as required (for example, removing unnecessary data

points, normalizing the data, and data aggregation) and then uploads the data to the

management data warehouse The upload is done as a bulk insert to minimize the impact

on server performance.The separation of data collection and data upload into separate

packages provides more flexibility and efficiency This design supports scenarios in which

snapshots of the data are captured at frequent intervals (for example, every 15 seconds),

but the collected data needs to be uploaded only every hour Data collection and upload

frequency should be determined by the monitoring requirements of a particular SQL

Server installation

The Management Data Warehouse

The management data warehouse is a relational database where the Data Collector stores

its data A single MDW database can serve as the central repository for data collectors

running on one or more target SQL Server instances A data collector is configured on

each target server, and it collects and uploads data to the MDW database, which may be

on a remote server Between the time the data is captured and the time it is uploaded, the

Data Collector may write temporary data into cache files on the target server

NOTE

You can install the MDW on the same instance of SQL Server that is running the Data

Collector However, if server resources or performance are an issue on the server that

is being monitored, you might want to install the management data warehouse on a

dif-ferent computer to avoid additional CPU and I/O contention

The MDW can become quite large, growing at approximately 250–500MB per day This is

roughly around 2GB of database storage per server each week You need to decide how

long you want to retain the data based on on your performance monitoring needs and

your storage availability For the most part, you can probably stick with the default

reten-tion settings, which are 14 days for Query Statistics and Server Activity History data

collec-tions and two years for Disk Usage Summary colleccollec-tions

ptg Performance Monitoring Tools

The required schemas and the objects to support the predefined system collection sets are

created when you run the wizard to create the MDW Two schemas are created:coreand

snapshots Thecoreschema describes the tables, stored procedures, and views used to

organize and identify collected data These tables are shared among all the data tables

created for individual collector types Thesnapshotsschema describes the objects needed

to store and maintain the data collected by the collector types that are provided

A third schema, custom_snapshots, is created if you create your own user-defined

collec-tion sets that include colleccollec-tion items that use the Generic T-SQL Query collector type

CAUTION

You should not directly modify any data stored in the management data warehouse

Changing the data that you have collected invalidates the legitimacy of the collected

data Also, instead of directly accessing the MDW tables, you should always use the

documented stored procedures and functions provided with the Data Collector to

access instance and application data

MDW Reports

The MDW reports included in SSMS present the information gathered by the Data

Collector in the following areas:

Query performance statistics and use of indexes

Server activity information, including waiting processes, memory usage,

CPU/sched-uler usage, and disk I/O

Disk usage information

Each of the reports present a summary of the data at a high level, with the capability to

drill down into the details Sometimes the reports can provide information to help direct

you to a solution for a performance problem For example, if the query performance

statis-tics report shows an extremely slow-running query, you can drill down through the report

to expose more details on the query, right down to the query plan The query plan could

indicate that there is a missing index on that table, and creating that index could make a

major difference in the query performance

Installing and Configuring the Data Collector

Before you can use the Data Collector, you must complete the following tasks:

Create logins and map them to Data Collector roles

Configure the management data warehouse

NOTE

The management data warehouse can be installed only on a server running SQL Server

2008 or SQL Server 2008 R2