Microsoft SQL Server 2008 R2 Unleashed- P133 pdf

ptg
1264
CHAPTER 35 Understanding Query Optimization
Query Text Query Hash Query Plan Hash

select * from titles where ytd_sales = 0 0x9AB21AC5889FE2D0 0x8D6DE6D258BABB2B
select * from titles where ytd_sales = 0 0x9AB21AC5889FE2D0 0x8D6DE6D258BABB2B
select * from titles where ytd_sales = 99 0x9AB21AC5889FE2D0 0xE889B5D23D917DFD
select * from titles where ytd_sales = 10 0x9AB21AC5889FE2D0 0xE889B5D23D917DFD
select * from titles where ytd_sales = 0 0x9AB21AC5889FE2D0 0x8D6DE6D258BABB2B
select * from titles where ytd_sales = 0 0x9AB21AC5889FE2D0 0xE889B5D23D917DFD
This query hash or query plan hash value can be used in a query to aggregate performance
statistics for like queries. For example, the following query returns the average processing
time and logical reads for the same queries that were returned in Listing 35.2:
SELECT
SUM(total_worker_time) / SUM(execution_count)/1000. AS “Avg CPU Time(ms)”,
SUM(total_logical_reads) / SUM(execution_count) AS “Avg Reads”
FROM
sys.dm_exec_query_stats
where query_hash = 0x9AB21AC5889FE2D0
go
Avg CPU Time(ms) Avg Reads

164.092000 7
Listing 35.5 provides a sample query using the query hash value to return information
about the top 25 queries ranked by average processing time.
LISTING 35.5 Returning Top 25 Queries Using Query Hash
SELECT TOP 25 query_stats.query_hash AS “Query Hash”,
SUM(query_stats.total_worker_time) / SUM(query_stats.execution_count) AS
“Avg CPU Time”,
MIN(query_stats.statement_text) AS “Statement Text”

FROM
(SELECT QS.*,
SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(ST.text)
ELSE QS.statement_end_offset END
- QS.statement_start_offset)/2) + 1) AS statement_text
FROM sys.dm_exec_query_stats AS QS
CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST) as query_stats
GROUP BY query_stats.query_hash
Download from www.wowebook.com
ptg
1265
Query Plan Caching
35
ORDER BY 2 DESC;
GO
sys.dm_exec_plan_attributes
If you want to get information about specific attributes of a specific query plan, you use
sys.dm_exec_plan_attributes. This DMV takes a plan_handle as an input parameter (see
Listing 35.1 for an example of a query that you can use to retrieve a query’s plan handle)
and returns one row for each attribute associated with the query plan. These attributes
include information such as the ID of the database context the query plan was generated
in, the ID of the user who generated the query plan, session SET options in effect at the
time the plan was generated, and so on. Many of these attributes are used as part of the
cache lookup key for the plan (indicated by the value 1 in the is_cache_key_column).
Following is an example of the output for sys.dm_exec_plan_attributes:
select convert(varchar(30), attribute) as attribute,
convert(varchar(12), value) as value,
is_cache_key

FROM
sys.dm_exec_plan_attributes (0x06000400EBC44D2AB880A006000000000000000000000000)
where is_cache_key = 1
go
attribute value is_cache_key

set_options 187 1
objectid 709739755 1
dbid 4 1
dbid_execute 0 1
user_id -2 1
language_id 0 1
date_format 1 1
date_first 7 1
compat_level 100 1
status 0 1
required_cursor_options 0 1
acceptable_cursor_options 0 1
merge_action_type 0 1
is_replication_specific 0 1
optional_spid 0 1
optional_clr_trigger_dbid 0 1
optional_clr_trigger_objid 0 1
Download from www.wowebook.com
ptg
1266
CHAPTER 35 Understanding Query Optimization
Note the attributes flagged as cache keys for the plan. If one of these properties does not
match the state of the current user session, the plan cannot be reused for that session, and
a new plan must be compiled and stored in the plan cache. If you see multiple plans in

cache for what appears to be the same query, you can determine the key differences
between them by comparing the columns associated with the plan’s cache keys to see
where the differences lie.
TIP
If SQL Server has been running for a while, with a lot of activity, the number of plans in
the plan cache can become quite large, resulting in a large number of rows being
returned by the plan cache DMVs. To run your own tests to determine which query
plans get cached and when specific query plans are reused, you should clear out the
cache occasionally. You can use the DBCC FREEPROCCACHE command to clear all
cached plans from memory. If you want to clear only the cached plans for objects or
queries in a specific database, you execute the following command:
DBCC FLUSHPROCINDB (dbid)
Keep in mind that you should run these commands only in a test environment. Running
these commands in production servers could impact the performance of the currently
running applications.
Other Query Processing Strategies
In addition to the optimization strategies covered so far, SQL Server also has some addi-
tional strategies it can apply for special types of queries. These strategies are used to help
further reduce the cost of executing various types of queries.
Predicate Transitivity
You might be familiar with the transitive property from algebra. The transitive property
simply states that if A=B and B=C, then A=C. SQL Server supports the transitive property
in its query predicates. Predicate transitivity enables SQL Server to infer a join equality
from two given equalities. Consider the following example:
SELECT *
FROM table1 t1
join table2 t2 on t1.column1 = t2.column1
join table3 t3 on t2.column1 = t3.column1
Using the principle of predicate transitivity, SQL Server is able to infer that t1.column1 is
equal to t3.column1. This capability provides the Query Optimizer with another join

Download from www.wowebook.com
ptg
1267
Other Query Processing Strategies
35
strategy to consider when optimizing this query. This might result in a much cheaper
execution plan.
The transitive property can also be applied to SARGs used on join columns. Consider the
following query:
select *
from sales s
join stores st on s.stor_id = st.stor_id
and s.stor_id = ‘B199’
Again, using transitive closure, it follows that st.stor_id is also equal to ’B199’. SQL
Server recognizes this and can compare the search value against the statistics on both
tables to more accurately estimate the number of matching rows from each table.
Group by Optimization
One way SQL Server can process GROUP BY results is to retrieve the matching detailed data
rows into a worktable and then sort the rows and calculate the aggregates on the groups
formed. In SQL Server 2008, the Query Optimizer also may choose to use hashing to orga-
nize the data into groups and then compute the aggregates.
The hash aggregation strategy uses the same basic method for grouping and calculating
aggregates as for a hash join. At the point where the probe input row is checked to deter-
mine whether it already exists in the hash bucket, the aggregate is computed if a hash
match is found. The following pseudocode summarizes the hash aggregation strategy:
create a hash table
for each row in the input table
read the row
hash the key value
search the hash table for matches

if match found
aggregate the value into the old record
else
insert the hashed key into the hash bucket
scan and output the hash table contents
drop the hash table
For some join queries that contain GROUP BY clauses, SQL Server might perform the group-
ing operation before processing the join. This could reduce the size of the input table to
the join and lower the overall cost of executing the query.
Download from www.wowebook.com
ptg
1268
CHAPTER 35 Understanding Query Optimization
NOTE
One important point to keep in mind is that regardless of the GROUP BY strategy
employed, the rows are not guaranteed to be returned in sorted order by the grouping
column(s) as they were in earlier releases. If the results must be returned in a specific
sort order, you need to use the ORDER BY clause with GROUP BY to ensure ordered
results. You might want to get into the habit of doing this regularly.
Queries with DISTINCT
When the DISTINCT clause is specified in a query, SQL Server can eliminate duplicate rows
by the sorting the result set in a worktable to identify and remove the duplicates, similar
to how a worktable is used for GROUP BY queries. In SQL Server 2008, the Query Optimizer
can also employ a hashing strategy similar to that used for GROUP BY to return only the
distinct rows before the final result set is determined.
In addition, if the Query Optimizer can determine at compile time that there will be no
possibility of duplicate rows in the result set (for example, each row contains the table’s
primary key), the strategies for removing duplicate rows are skipped altogether.
Queries with UNION
When you specify UNION in a query, SQL Server merges the result sets, applying one of the

merge or concatenation operators with sorting strategies to remove any duplicate rows.
Figure 35.25 shows an example similar to the OR strategy where the rows are concatenated
and then sorted to remove any duplicates.
If you specify UNION ALL in a query, SQL Server simply appends the result sets together. No
intermediate sorting or merge step is needed to remove duplicates. Figure 35.26 shows the
same query as in Figure 35.25, except that a UNION ALL is specified.
When you know that you do not need to worry about duplicate rows in a UNION result set,
always specify UNION ALL to eliminate the extra overhead required for sorting.
When a UNION is used to merge large result sets together, SQL Server 2008 may opt to use a
merge join or hash match operation to remove any duplicate rows. Figure 35.27 shows an
example of a UNION query where the rows are concatenated, and then a hash match opera-
tion is used to remove any duplicates.
Parallel Query Processing
The query processor in SQL Server 2008 includes parallel query processing—an execution
strategy that can improve the performance of complex queries on computers with more
than one processor.
SQL Server inserts exchange operators into each parallel query to build and manage the
query execution plan. The exchange operator is responsible for providing process manage-
ment, data redistribution, and flow control. The exchange operators are displayed in the
Download from www.wowebook.com
ptg
1269
Parallel Query Processing
35
FIGURE 35.25 An execution plan for a UNION query.
FIGURE 35.26 An execution plan for a UNION ALL query.
Download from www.wowebook.com
ptg
1270
CHAPTER 35 Understanding Query Optimization

FIGURE 35.27 An execution plan for a UNION query, using a hash match to eliminate
duplicate rows.
query plans as the Distribute Streams, Repartition Streams, and Gather Streams
logical operators. One or more of these operators can appear in the execution plan output
of a query plan for a parallel query.
Whereas a parallel query execution plan can use more than one thread, a serial execution
plan, used by a nonparallel query, uses only a single thread for its execution. Prior to
query execution time, SQL Server determines whether the current system state and config-
uration allow for parallel query execution. If parallel query execution is justified, SQL
Server determines the optimal number of threads, called the degree of parallelism, and
distributes the query workload execution across those threads. The parallel query uses the
same number of threads until the query completes. SQL Server reexamines the optimal
degree of parallelism each time a query execution plan is retrieved from the procedure
cache. Individual instances of the same query could be assigned a different degree of
parallelism.
SQL Server calculates the degree of parallelism for each instance of a parallel query execu-
tion by using the following criteria:
. How many processors does the computer running SQL Server have, and how many
are allocated to SQL Server?
If two or more processors are allocated to SQL Server, it can use parallel queries.
. What is the number of concurrent active users?
Download from www.wowebook.com
ptg
1271
Parallel Query Processing
35
The degree of parallelism is inversely related to CPU usage. The Query Optimizer
assigns a lower degree of parallelism if the CPUs are already busy.
. Is sufficient memory available for parallel query execution?
Queries, like other processes, require resources to execute, particularly memory.

Obviously, a parallel query demands more memory than a serial query. More impor-
tantly, as the degree of parallelism increases, so does the amount of memory
required. The Query Optimizer carefully considers this in developing a query execu-
tion plan. The Query Optimizer could either adjust the degree of parallelism or use a
serial plan to complete the query.
. What is the type of query being executed?
Queries that use several CPU cycles justify using a parallel execution plan. Some
examples are joins of large tables, substantial aggregations, and sorting of large result
sets. The Query Optimizer determines whether to use a parallel or serial plan by
checking the value of the cost threshold for parallelism.
. Are a sufficient number of rows processed in the given stream?
If the Query Optimizer determines that the number of rows in a stream is too low, it
does not execute a parallel plan. This prevents scenarios where the parallel execution
costs exceed the benefits of executing a parallel plan.
Regardless of the answers to the previous questions, the Query Optimizer does not use a
parallel execution plan for a query if any one of the following conditions is true:
. The serial execution cost of the query is not high enough to consider an alternative
parallel execution plan.
. A serial execution plan exists that is estimated to be faster than any possible parallel
execution plan for the particular query.
. The query contains scalar or relational operators that cannot be run in parallel.
Parallel Query Configuration Options
Two server configuration options—maximum degree of parallelism and cost thresh-
old for parallelism—affect the consideration for a parallel query. Although doing so
is not recommended, you can change the default settings for each. For single processor
machines, these settings are ignored.
The maximum degree of parallelism option limits the number of threads to use in a
parallel plan execution. The range of possible values is 0 to 32. This value is configured to
0 by default, which allows the Query Optimizer to use up to the actual number of CPUs
allocated to SQL Server. If you want to suppress parallel processing completely, set the

value to 1.
Download from www.wowebook.com
ptg
1272
CHAPTER 35 Understanding Query Optimization
The cost threshold for parallelism option establishes a ceiling value the Query
Optimizer uses to consider parallel query execution plans. If the calculated value to
execute a serial plan is greater than the value set for the cost threshold for parallelism, a
parallel plan is generated. This value is defined by the estimated time, in seconds, to
execute the serial plan. The range of values for this setting is 0 to 32767. The default value
is 5. If the maximum degree of parallelism is set to 1, or if the computer has a single
processor, the cost threshold for parallelism value is ignored.
You can modify the settings for the maximum degree of parallelism and the cost
threshold for parallelism server configuration options either by using the
sp_configure system stored procedure or through SSMS. To set the values for these
options, use the sp_configure system stored procedure via SSMS or via SQLCMD, as
follows:
USE master
go
exec sp_configure ‘show advanced options’, 1
GO
RECONFIGURE
GO
exec sp_configure ‘max degree of parallelism’, 2
exec sp_configure ‘cost threshold for parallelism’, 15
RECONFIGURE
GO
To set these configuration options via SSMS, right-click the SQL Server instance in the
Object Explorer and then click Properties. In the Server Properties dialog, select the
Advanced page. The parallelism options are near the bottom, as shown in Figure 35.28.

Identifying Parallel Queries
You can identify when a parallel execution plan is being chosen by displaying the graphi-
cal execution plan in SSMS. The graphical execution plan uses icons to represent the
execution of specific statements and queries in SQL Server. The execution plan output for
every parallel query has at least one of these three logical operators:
. Distribute Streams—Receives a single input stream of records and distributes
multiple output streams. The contents and form of the record are unchanged. All
records enter through the same single input stream and appear in one of the output
streams, preserving the relative order.
. Gather Streams—Assembles multiple input streams of records and yields a single
output stream. The relative order of the records, contents, and form is maintained.
. Repartition Streams—Accepts multiple input streams and produces multiple
streams of records. The record contents and format are unchanged.
Download from www.wowebook.com
ptg
1273
Parallel Query Processing
35
FIGURE 35.28 Setting SQL Server parallelism options.
Figure 35.29 shows a portion of a sample query plan that uses parallel query techniques—
both repartition streams and gather streams.
Parallel Queries on Partitioned Objects
SQL Server 2008 provides improved query processing performance for partitioned objects
when running parallel plans including changes in the way parallel and serial plans are
represented, and enhancements to the partitioning information provided in both compile-
time and runtime execution plans. SQL Server 2008 also automates and improves the
thread partitioning strategy for parallel query execution plans on partitioned objects.
In addition to the performance improvements, query plan information has been improved
as well in SQL Server 2008, now providing the following information related to parti-
tioned objects:

. The partitions accessed by the query, available in runtime execution plans.
. An optional Partitioned attribute indicating that an operation, such as a seek,
scan, insert, update, merge, or delete, is performed on a partitioned table.
. Summary information that provides a total count of the partitions accessed. This
information is available only in runtime plans.
Download from www.wowebook.com