About the book
This is
a sample chapter of the book
SQL Server DMVs in Action. It has been published with
the exclusive
permission of Manning.
Written by: Ian W. stirk
Pages: 375
Publisher: Manning
ISBN: 9781935182733
Get 30% discount
DotNetSlacker readers can get 30% off the full print book or ebook at
www.manning.com using the promo code dns30 at checkout.
Introduction
Many SQL queries run fine in isolation; however, in the real world, SQL queries need to interact with other running queries. The queries compete for resources, often leading
to temporary blocking. This is to be expected. However, if you notice queries running slowly, it is possible to identify the queries involved and perhaps reschedule them so they
don't run concurrently or decode the resource for which the queries are competing, possibly removing the contention. For example, if an index is the cause of contention, it is
possible to create another index that could remove this contention, allowing both queries to progress.
The script we use to identify blocked queries is shown in listing
1.
Listing 1: What is blocked?
In the listing, you can see there are four Dynamic Management Views (DMVs) and one Dynamic Management Function (DMF) involved in identifying what queries are
being blocked. A brief description of each is shown in table 1.
Table 1: DMVs/DMFs for blocked queries
DMV/table | Description |
sys.dm_exec_connections | Contains details about connection established on SQL Server |
sys.dm_exec_requests | Contains details about each request executing on SQL Server |
sys.dm_os_waiting_tasks | Contains details about the wait queues of tasks that are waiting on some resource |
sys.dm_exec_sessions | Contains details about each authenticated session on SQL Server |
sys.dm_exec_sql_text | DMF that returns the sql text identified by a given sql_handle |
The joining of the DMVs and DMF provides enough information to determine which SQL queries are causing the blocking and which queries are being blocked across all
databases on the server. The DMVs sys.dm_exec_connections, sys.dm_exec_requests and sys.dm_os_waiting_tasks are joined on their common
key column session_id (blocking_session_id in the case of sys.dm_exec_requests).
These DMVs have a RIGHT OUTER JOIN to the DMV
sys.dm_exec_sessions. That is because the blocking queries are typically running and will be present in the sys.dm_dm_os_waiting_tasks DMV. The
blocking query's most_recent_sql_handle is passed to the DMF sys.dm_exec_sql_text to retrieve the text of the blocking SQL query. Similarly, the
blocked query's sql_handle is passed to DMF sys.dm_exec_sql_text to retrieve the text of the blocked SQL query.
An example of the type of
output for this query is given in figure 1.
Figure 1: Output showing what SQL queries are blocking and being blocked

In the output, you can see the SessionId 101 is blocking SessionId 75. The users causing the blocking and being
blocked are both identified. Similarly, the SQL queries involved in the blocking are identified. You can also see that SessionId 103 is also being blocked by SessionId 101, and
SessionId 85 is being blocked by SessionId 103.
Using cached plans for blocking queriesIt might be useful to mention here that when blocking occurs (or waiting for that matter), developers often examine the
cached plan for clues on how to speed up the query. While this often occurs, it should be noted that the cached plan doesn't take into effect interaction with other running
queries. So while you might improve the performance of the section of SQL in a batch that has the highest cost, it may have little impact on a piece of SQL that has little cost
but is involved in blocking. In this case, it makes more sense to run the batch of SQL inside a wrapper that records the duration of each SQL statement within the batch and
target these for improvement. In essence, this gives you instrumentation inside your SQL code.
Summary
When SQL queries interact, they compete for resources, which leads to temporary blocking. We discussed a script for identifying blocked queries. Queries can be rescheduled so
they don't run concurrently. Also, the resource for which the queries are competing can be decoded, possibly removing the contention.
Get 30% discount
DotNetSlacker readers can get 30% off the full print book or ebook at
www.manning.com using the promo code dns30 at checkout.
About Manning Publications
 |
Manning Publication publishes computer books for professionals--programmers, system administrators, designers, architects, managers and others. Our focus is on computing titles at professional levels. We care about the quality of our books. We work with our authors to coax out of them the best writi...
This author has published 33 articles on DotNetSlackers. View other articles or the complete profile here.
|
You might also be interested in the following related blog posts
SQLAuthority News Meeting SQL Friends SQLPASS 2011 Event Log
read more
SQLAuthority News SQLPASS Today FREE 100 SQL Wait Stats Book Print Copy Book Signing
read more
SQLAuthority News SQLPASS 100 SQL Wait Stats Book Print Copy Giveaway A Book Every Minute for an Hour Tomorrow
read more
SQLAuthority News Whitepaper Running SQL Server with Hyper-V Dynamic Memory Best Practices and Considerations Consolidating Databases Using Virtualization Planning Guide
read more
SQLAuthority News SQL Server Health Check Service Speed UP SQLServer
read more
Connecting to SQL Azure with Telerik OpenAccess
read more
Postgresql - Day 2
read more
Migrating to Postgresql with my friend NHibernate
read more
Migrated from Community Server to DasBlog
read more
RadScheduler for Silverlight learning series, part 3: Add, Edit, and Delete Appointments
read more
|
|
Please login to rate or to leave a comment.