I've had a lot of great feedback since my last "official" Who is Active? release--v8.40, back in March--and since then I've made 42 distinct changes, bringing us all the way to v8.82. My versioning scheme is quite simple: one change, one increment, with occasional numbers skipped or major version incrementation if I do a really major change.
If you've been watching the SQLblog closely you may have noticed that I've spun up a "beta" program where I've been posting intermediate "builds" of the stored procedure. These builds represent the latest updates and are published pretty much immediately, which means I haven't tested them enough to declare them stable. Builds posted here on my main blog--such as this one--have been tested fairly heavily and I believe them to be in very good shape.
In the case of v8.82 I've made only one minor change in the past month and a half, and in the meantime I've been heavily using the code and have not encountered any issues. Nor have I received any change requests. So I am declaring v8.82 stable and ready to roll. You can get it from the following link, or at the bottom of this post.
Click here to download Who is Active? v8.82
So What Has Changed?
If you've been watching the beta builds you will have noticed the change log I've been keeping since v8.67. But that leaves around 20 changes unaccounted for. Between 8.40 and 8.67 I did a number of things: I implemented a number of minor bug fixes and several workarounds for strange ways that data is exposed by the various DMVs.
One change you'll quickly notice is that all of the numbers have been right-aligned. This is something that was originally requested by Aaron Bertrand, who later was unable to use the feature as-is because, as it turns out, his font choice in SSMS is not compatible with the way I made the feature work. I did a poll here on SQLblog and discovered that Aaron is fairly unique with regard to fonts, so I'm keeping the feature as-is. Personally, after the 10 minutes it took me to get used to seeing the data a new way, I found it to be a really great enhancement. I'm quite interested in hearing your feedback on how you like the change.
From 8.67 on I have a comprehensive change log, and next I'll go over some of the more important enhancements, in chronological order based on when I implemented them. There is a central theme here: each of these changes directly resulted from someone giving me feedback. But more on that below.
At the request of Joe Sack I added a parameter called @help which, when set to 1, returns information about all of the available options. Online help, in other words. This is much easier than pulling up the definition for the stored procedure and I've found it to be quite helpful on a number of occasions since making the change.
Jimmy May asked for an option to help find "block leaders", SPIDs that are at the front of the blocking chain. From this the @find_block_leaders parameter was born. It causes the stored procedure to add a new column, blocked_session_count, which is an integer representing the number of SPIDs blocked downstream. Sort by this descending (@sort_column='[blocked_session_count]', @sort_direction='DESC') and the block leader(s) will all sort to the top. I've already been able to use this one to debug a production blocking problem in a matter of around 30 seconds, which may have otherwise taken me minutes. Thanks, Jimmy!
After an e-mail thread with Michelle Ufford I decided to support simple wildcards in the @output_column_list parameter. Interested primarily in information about tempdb? No problem: @output_column_list='[temp%][%]'. Now everything about tempdb will show up in the leftmost columns, and every other column will show up afterward. No need to mess around and try to re-construct the complete column list.
Around this time I received a few requests for better filtering capabilities. I removed the @spid parameter and replaced it with @filter and @filter_type. The default filter type is "session" in order to support some form of backward-compatibility. Other valid filter types are "program", "database", "login", and "host". Wildcards are supported, so if you're interested in everyone logging in with hosts that start with the letter "C", I've got you covered: @filter='C%', @filter_type='host'.
An e-mail exchange including both Jimmy May and Joe Sack got me really interested in the Runnable Queue, and yet another enhancement was created. I added a wait type called "RUNNABLE" to the wait_info column. This wait type doesn't actually exist, but is rather an indication of how long tasks have been sitting on the queue. It's a way to quickly see when you're experiencing scheduler pressure.
Next Steps
At some point I'm going to fully document this thing. Really. But to be honest I'm much more interested in continuing to enhance it. If you've found it to be useful, please let me know. If you have feature requests, definitely let me know what they are. And if you find a bug, drop everything and e-mail me right away (well, within reason). My e-mail address is in the stored procedure on purpose; most of the enhancements to this stored procedure have come about thanks to users, and I really do want to hear from you. Don't be shy.
So without further ado, enjoy. And thank you to everyone--both those listed and not listed in this post--who helped make this version what it is. I really appreciate your help.