Tải bản đầy đủ (.pdf) (10 trang)

Hướng dẫn học Microsoft SQL Server 2008 part 150 pptx

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.83 MB, 10 trang )

Nielsen c68.tex V4 - 07/21/2009 4:18pm Page 1452
www.getcoolebook.com
Nielsen c69.tex V4 - 07/21/2009 4:20pm Page 1453
Resource Governor
IN THIS CHAPTER
Determining whether Resource
Governor is the right tool for
the job
Configuring Resource
Governor
Resource Governor
performance monitoring
W
henever I think of the Resource Governor, I get a picture of an old
southern gentleman in a white suit with a white bow tie.
‘‘Excuse me, Gov’nor, but I’d be much obliged but you could please restrict the
CPU traffic so my job could run smooth Many thanks to you, sir. Why sure,
I’d love a cold lemonade. Thank you kindly.’’
Fitting right in with Microsoft’s theme of SQL Server for the large enterprise,
Resource Governor is designed to limit CPU and proc cache memory for specific
queries, which improves SQL Server’s ability to handle conflicting loads. For
example, a few reports pulling data from a parallelized query can tie up a
normally fast order processing database. But limit those reports to 10% of the
CPU, the reports will take longer to run but the call center doesn’t swamp
the help desk with complaints.
Although Resource Governor sounds like a panacea for all sorts of server perfor-
mance ills, it does have its limitations:
■ Sessions must be assigned to the workload group at the beginning
of the session. As the DBA, you can’t alter the workload group of a
runaway query to corral it into submission. If it’s an assigned runaway
session, it stays a runaway session.


■ Resource Governor requires Enterprise Edition, so it can’t help the
organization with a single dual-core server running Standard Edition
that desperately needs to control reporting queries.
■ A poorly indexed query that is scanning a few million rows will still
scan a few million rows even after its CPU has been limited by the
Resource Governor. The poorly indexed query will take even longer to
run — its poor performance has simply been spread around so that
others don’t feel its pain quite so badly. The root source of the poor
performance still needs to be addressed.
1453
www.getcoolebook.com
Nielsen c69.tex V4 - 07/21/2009 4:20pm Page 1454
Part IX Performance Tuning and Optimization
■ It’s been criticized for not including the ability to limit I/O; however, I prefer limiting I/O by
limiting the CPU that makes the I/O requests. I’d rather not have to balance CPU limits and
I/O limits, or have the two limits waiting for one another, so I don’t agree with this perceived
limitation.
On the bright side, assuming the queries are well written and supported by the right indexes, Resource
Governor is the right tool to smooth the conflicts between competing tasks.
Configuring Resource Governor
The Resource Governor is designed around the concepts of resource pools (named units that allocate CPU
and memory) and workload groups (named units that include user sessions). As a user session is initiated
it is assigned to a workload group. Workload groups are connected to a resource pool.
Resource Governor is not on by default. It can be enabled in Object Explorer using the [server name] ➪
Management ➪ Resource Governor enable or disable command context menu.
Using T-SQL, the Resource Governor can be enabled or disabled using
ALTER commands:
ALTER RESOURCE GOVERNOR Reconfigure;
GO
ALTER RESOURCE GOVERNOR Enable;

Resource pools
A resource pool is a defined limit of CPU and memory resources. There are two predefined resource
pools (internal and default):
■ Internal pool: The resources used by SQL Server to run SQL Server. This pool is never
restricted in any way. Any dedicated administrator connection (DAC) sessions run in the
internal pool.
■ Default pool: This is a mandatory pool (can’t be dropped) for any session that falls into the
default workload group. The default pool is unrestricted.
■ User-defined resource pools: Additional resource pools can be created for more granular
configuration of resources.
For each resource pool, the
min% and max% CPU and memory can be configured. The total of all the
resource pools’
min% settings must be equal to or less than 100%.
The granularity of the
min% and max% setting is 5%, which fits perfectly with 20 as the maximum
number of resource pools (including the internal and default pool, leaving 18 possible user-defined
resource pools).
The memory pool controlled by the Resource Governor is the procedure cache used to
compile and store query execution plans, not the memory u sed to buffer data. Any data
page might be accessed by any session, so there’s no good reason or method to limit the data buffer
by resource pool. SQL Server normally does a good job of managing the procedure cache, but if you
1454
www.getcoolebook.com
Nielsen c69.tex V4 - 07/21/2009 4:20pm Page 1455
Resource Governor 69
do decide to limit it, be sure to use the CPU to limit the data workload, and use memory to limit the
number of cached query execution plans.
Best Practice
B

e careful when setting min% above 0 because it can lead to some strange results. To simplify the formula:
The total min% setting of the other pools reduces any user-defined pool’s effective max% settings. For
example, if pool A has a min% of 20 and pool B has a min% of 30, then pool C’s effective max% is reduced
to only 50%. I recommend leaving the min% setting to 0 and only restricting the max%.
To create a resource pool using Object Explorer, use the Management ➪ Resource Governor ➪ Resource
Pools context menu and select the New Resource Pool menu item. The Resource Governor Properties
page, shown in Figure 69-1, is used to create, alter, and drop resource pools and workload groups.
FIGURE 69-1
A user-defined resource pool, Reporting, is limited to 20% of CPU and is connected to the Reports
workload group.
1455
www.getcoolebook.com
Nielsen c69.tex V4 - 07/21/2009 4:20pm Page 1456
Part IX Performance Tuning and Optimization
Resource pools can also be scripted using standard CREATE, ALTER,andDROP DDL commands.
The Resource Governor Properties page is pretty buggy (using SP1). If you prefer it to
T-SQL, here’s how I got it to work: It only enables the OK button, which allows you to
save changes if you’ve added a new resource pool. Therefore, no matter what you need to change,
be sure to add a new resource pool so you can save changes. It is hoped that this will be fixed in a
subsequent service pack.
Workload groups
Workload groups are the named item that ties a session to resource pools. Multiple workgroups can be
connected to a single resource group.
Workload groups can optionally provide additional resource limits. The critical ones are as follows:
■ Importance (low|medium|high): The relative importance within the resource pool (this is
relevant only when multiple workload groups are assigned to the resource pool).
■ Max_Dop: The maximum degree of parallelism setting for any session assigned to this
workload group.
■ Group_Max_Request: This limits the number of sessions for a workload group.
Workload groups can be created, altered, and dropped in the same Management Studio property page as

resource pools. They can also be managed using the
CREATE, ALTER,andDROP DDL commands. The
following DDL query creates the SSMS workload group, sets
MAX_DOP to 1, and assigns the workload
group to the default resource pool:
CREATE WORKLOAD GROUP SSMS
WITH (MAX_DOP = 1)
USING "default"
That’s right, the syntax requires double quotes around the resource group name in the USING clause.
Weird.
Best Practice
C
ontrolling MAX_DOP using query hints is a real pain, but this actually becomes another great reason to
use the Resource Governor. Use workload groups to control MAX_DOP. MAX_DOP query hints override
workload group settings, which override the server configuration.
This enables you to leave the server MAX_DOP setting to 0 so DBCC can parallelize. OLTP transactional
queries should avoid parallelizing, so set the default workload group MAX_DOP to 1. Reporting queries
benefit from parallelism, so set MAX_DOP to 0.
1456
www.getcoolebook.com
Nielsen c69.tex V4 - 07/21/2009 4:20pm Page 1457
Resource Governor 69
Classifier functions
The whole point of the Resource Governor is to control individual queries. The classifier function
includes specific sessions into workload groups so they can be limited by the resource pool.
The classifier function is executed with every new session, assigning the session to a workload group.
Below is a sample classifier function:
CREATE
alter
FUNCTION ResourceGovClassifer()

RETURNS SYSNAME
WITH SCHEMABINDING
BEGIN
DECLARE @WorkLoad sysname
workload based on login names
IF SUSER_SNAME()= ‘Maui\Pn’
SET @WorkLoad=’PowerUsers’;
workload based on application
IF APP_NAME() = ‘Microsoft SQL Server Management Studio’
SET @WorkLoad= ‘SSMS’;
IF APP_NAME() LIKE ‘%REPORT SERVER%’
SET @WorkLoad= ‘Reports’;
RETURN @WorkLoad;
END
Once the function has been created it must be selected in the Resource Governor Properties page to be
the current classifier function. To change the current classifier function using T-SQL, use the
ALTER
command:
ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION=dbo. ResourceGovClassifer);
GO
ALTER RESOURCE GOVERNOR RECONFIGURE;
To view information about the classifier function and logons, check the sys.dm_exec_sessions and
sys.dm_exec_requests DMVs.
Monitoring Resource Governor
Of course, with Resource Governor enabled, you’ll want to watch the CPU usage by watching SQL
Server: Resource Pool Stats
and SQL Server: Workload Stats in Performance Monitor.
1457
www.getcoolebook.com
Nielsen c69.tex V4 - 07/21/2009 4:20pm Page 1458

Part IX Performance Tuning and Optimization
Best Practice
V
arious loads can be first collected into workload groups and attached to the default resource pool to
track them for CPU usage before assigning them to other resource pools.
I strongly recommend keeping the resource pools simple. Keep the primary workload using the default
resource pool and group the workloads that you want to restrict into one or more user-defined resource
pools.
To check on the Resource Governor configuration, there are four catalog views/DVMs:

sys.resource_governor_configuration
■ sys.resource_governor_resource_pools
■ sys.resource_governor_workload_groups
■ sys.dm_resource_governor_workload_groups
To monitor usage and limits, use these DMVs:

sys.dm_resource_governor_configuration
■ sys.dm_resource_governor_resource_pools
Summary
Resource Governor won’t be used by most DBAs, and without careful planning the Resource Governor
could royally mess up a heavy transaction system. But if you’re one of the few for whom the Resource
Governor is the solution, in the hands of a skilled DBA, it’s the perfect tool to fine-tune a conflicting
workload.
A few highlights about the Resource Governor:
■ Resource pools define a set of
min% and max% restrictions for CPU and memory.
■ Workload groups are used to assign sessions to resource pools.
■ Besides CPU and memory, the workload groups can control
MAXDOP.
■ The classifier function runs as part of the logon sequence to assign incoming session to a

workload group.
■ Performance Monitor can be used to watch stats about the individual resource pools and
workload groups.
This concludes part IX, ‘‘Performance Tuning and Optimization,’’ as well as the majority of this book
that deals with SQL Server’s Relational Database Engine. The next part moves into the BI world and
explains topics such as star schemas, cubes, and data warehouse designs.
1458
www.getcoolebook.com
Nielsen p10.tex V4 - 07/21/2009 4:22pm Page 1459
Business Intelligence
IN THIS PART
Chapter 70
BI Design
Chapter 71
Building Multidimensional Cubes
with Analysis Services
Chapter 72
Programming MDX Queries
Chapter 73
Authoring Reports with Reporting
Services
Chapter 74
Administrating Reporting Services
Chapter 75
Analyzing Data with Excel
Chapter 76
Data Mining with Analysis
Services
I
f the Information Architecture Principle stated in Chapter 2 is true,

then information is useful not only for daily operations, but also for
current and future analysis. Hence, extract, transform, and load (ETL)
processes collect data from the daily operations and store it in data
warehouses using patterns organized for analysis, rather than daily
operations. Cubes, MDX queries, and Reporting Services pull from the data
warehouse and present the data for analysis.
This whole process of analyzing historical and current data, both today and
in the future, is the proactive side of IT and is collectively called business
intelligence (BI).
In the past four releases of SQL Server, Microsoft has been steadily growing
SQL Server’s BI services, and SQL Server 2008 brings to fruition years of
planning and development. From the enterprise-grade ETL tool and the rich
and easy-to-build cubes to the slick reporting interface, SQL Server 2008 is
more than ready to help you conquer your BI requirements.
BI, by definition, does not exist in a vacuum. Not only is the data
warehouse dependent on numerous operational databases, but the BI toolset
frequently includes multiple tools from multiple vendors. While non-SQL
Server tools are beyond the scope of this book, this part covers using Excel,
the most popular data analysis tool on the planet, as a front end for SQL
Server’s BI suite.
If you’re an old hand at BI, then welcome to SQL Server 2008’s sweet BI
suite. If you’ve been around operational data for a while but never had the
chance to work on the analysis side, welcome.
If SQL Server is the box, Part X is about getting the box to talk.
www.getcoolebook.com
Nielsen p10.tex V4 - 07/21/2009 4:22pm Page 1460
www.getcoolebook.com
Nielsen c70.tex V4 - 07/21/2009 4:21pm Page 1461
BI Design
IN THIS CHAPTER

Differences between OLTP and
OLAP
Data warehousing concepts
Warehouse structures and
relationships
Loading dimensions and fact
tables
Managing changing dimension
data
H
aving worked with various organizations and data systems, over time I’ve
noticed a progression of reporting and analysis solutions. First queries
are run directly against the online transactional processing (OLTP)
database, but this approach conflicts with production use of the database and
generally limits access to a very few staff due to security concerns.
Often the next step is to make a copy of the OLTP database for the express pur-
pose of running analytical or reporting queries. These attempts at using an OLTP
database for online analytical processing (OLAP) are problematic on a number of
fronts:
■ OLTP data structures are optimized for single, atomic transactions,
whereas OLAP queries summarize large volumes of data. Thus, queries
are painfully slow.
■ OLTP data may reflect limited history, whereas OLAP tends to be
interested in historical trends.
■ OLTP data structures are understood by a relatively small population
of experts in the organization, whereas OLAP is most effective when
exposed to the widest possible audience.
A common refinement on querying the OLTP database is to create a new database
that contains tables of summary data. When done carefully, this approach can
address some speed and history issues, but it is still understood by a relatively

small population. Consistent interpretation tends to be a problem as well, because
summary tables are often created at different times for different purposes.
These two concepts of consistent interpretation and availability to a wide audience
are key strategies for successful OLAP in particular and for business intelligence
(BI) in general. An organization needs to have widely understood data on which
to base its business decisions — the only alternatives are rumor and intuition.
1461
www.getcoolebook.com

×