THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Adam Machanic

Adam Machanic, Boston-based SQL Server developer, shares his experiences with programming, monitoring, and performance tuning SQL Server. And the occasional battle with the query optimizer.

Delta Force (A Month of Activity Monitoring, Part 26 of 30)

This post is part 26 of a 30-part series about the Who is Active stored procedure. A new post will run each day during the month of April, 2011. After April all of these posts will be edited and combined into a single document to become the basis of the Who is Active documentation.

The CPU is pegged. Your hard disks are fried. Memory consumption is through the roof. Who is to blame?!?

Well that’s easy. Blame the session with the most CPU consumption. Blame the session doing the most I/O operations. Ask Who is Active what’s going on—it’ll tell you...


Clearly session 52 is the problem here. It’s consumed over 2,000,000 milliseconds of CPU time. Session 53, on the other hand, has consumed a paltry five seconds. No brainer, right?

Except that it’s not.

Session 52? It’s in a wait state. (WAITFOR, to be exact.) Not consuming any CPU time at all at the time I ran Who is Active. Session 53? Using plenty. So why the discrepancy? Does Who is Active have a major bug?

The fact is—and this will be obvious to a lot of you, so forgive me—most of the metrics reported by Who is Active are cumulative. They’re totals from the entire session, or the entire lifetime of the request (depending on what’s going on). In the case of session 52 in the image above, that much CPU time was consumed over a five-minute period prior to the point in time when I ran Who is Active. Session 53, on the other hand, is currently consuming CPU time. But how do I figure that out?

The answer: delta mode. This feature is something for which you can thank Jimmy May, who kept telling me about his “SQL Deltoids” script that he’d written back in the bad old days of SQL Server 2000. “If only there were a way to apply that script to the SQL Server 2005 DMVs,” he lamented one day. So I added the functionality into Who is Active. It’s quite simple, and surprisingly effective.

To use delta mode, simply invoke Who is Active’s @delta_interval option. Setting an interval will cause the procedure to execute its main logic branch, then wait the specified amount of time—a number of seconds between 1 and 255—before running the same main logic branch again. All of the numeric values that changed during that period will be compared, and the changed numbers will be output in a series of columns named with _delta at the end.

For example, here are the same two sessions as above, viewed in delta mode:

EXEC sp_WhoIsActive
    @delta_interval = 5


During the five-second delta interval, session 52 consumed no CPU time. Session 53, on the other hand, consumed over 5,000 milliseconds of time. If the CPU is pegged, 52 is no longer contributing—53 is the session of interest.

Enabling delta mode will add some or all of the following columns to the output, depending on what other options have been set:

  • physical_io_delta
  • reads_delta
  • physical_reads_delta
  • writes_delta
  • tempdb_allocations_delta
  • tempdb_current_delta
  • CPU_delta
  • context_switches_delta
  • used_memory_delta

By leveraging these delta columns in conjunction with the @sort_order option, it’s easy to quickly see which sessions are currently consuming your valuable server resources—which is generally more interesting than seeing which sessions may have been consuming resources but are now waiting or sleeping.

Note: The various sessions and requests you'll see in delta mode pertain to the information captured after the wait interval. Information about requests that were running as of the first collection but are not running as of the second is discarded. New requests that started after the first collection will be shown, but with delta values of NULL. Locks, transactions, and other optional information, will also be captured only for the second collection, since no delta calculation is possible for those metrics (at least, not yet).



Delta mode, in its current form, is only really useful if you have requests that last longer than a second (at minimum—I usually do five or ten-second intervals). What kind of workload do you see on your servers? Is delta mode as it exists today something that you’re making use of (or that you’ll start making use of, now that I’ve written a post about it)?

Published Tuesday, April 26, 2011 11:00 AM by Adam Machanic

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Igor Marchenko said:


   First of all kudos for your series! I learned a lot about powerful functionality of sp_WhoISActive. I used to sample CPU, reads, writes per interval manually (I had a script for that). sp_WhoISActive will certainly be a replacement for homegrown script I used.

Thanks again,


April 28, 2011 5:23 PM

Adam Machanic said:

This post is part 28 of a 30-part series about the Who is Active stored procedure. A new post will run

April 28, 2011 9:03 PM

Adam Machanic said:

This post is part 30 of a 30-part series about the Who is Active stored procedure. A new post will run

April 30, 2011 11:45 AM

Ethan Murray said:

I've been looking for something like delta_mode for months.  I run big reporting-centric databases full of long-running ad hoc queries, and I often need to get in and see why CPU is running hot, and who wrote the bad query.  Nothing else I've tried has been so convenient and useful.

September 8, 2012 7:02 AM

Paulo said:

Delta mode & output to table.  Bingo!

November 2, 2015 11:33 PM

Praveen said:

Hi Adam,

What does it mean if CPU_Delta is NULL? I am getting records with CPU_Delta as NULL.


November 2, 2016 6:02 AM

Adam Machanic said:


Delta mode does two collections. First it does a base collection ("X"), then a delta collection ("Y"). All requests/sessions that exist as of "Y" will be output, but delta metrics can only be calculated for rows that are also in "X." So in your case, you had some new sessions/requests start after the base collection, and the proc doesn't have enough information to calculate a delta so it sends back NULL.

Make sense?


November 2, 2016 10:16 AM

Praveen said:

Thanks for the quick response.

November 2, 2016 11:28 AM

Leave a Comment


About Adam Machanic

Adam Machanic is a Boston-based SQL Server developer, writer, and speaker. He focuses on large-scale data warehouse performance and development, and is author of the award-winning SQL Server monitoring stored procedure, sp_WhoIsActive. Adam has written for numerous web sites and magazines, including SQLblog, Simple Talk, Search SQL Server, SQL Server Professional, CoDe, and VSJ. He has also contributed to several books on SQL Server, including "SQL Server 2008 Internals" (Microsoft Press, 2009) and "Expert SQL Server 2005 Development" (Apress, 2007). Adam regularly speaks at conferences and training events on a variety of SQL Server topics. He is a Microsoft Most Valuable Professional (MVP) for SQL Server, a Microsoft Certified IT Professional (MCITP), and an alumnus of the INETA North American Speakers Bureau.

This Blog


Privacy Statement