usp_who5

Over the years (and various versions of SQL Server), I have always had a need for different bits of information from the system tables to view activity on a SQL instance. The Microsoft "sp_who" procedures have always provided good information, but never really everything that I needed (and, more importantly, how I needed it... hence the reason for building my own version).

It can be run as is (example: EXECUTE [dbo].[usp_who5]) or with optional input filter parameters:

• @v_Filter: Limit result set by passing one or more values listed below (can be used individually or combined in any manner):

1. A - Active SPIDs Only
2. B - Blocked SPIDs Only
3. C - Exclude "SQL_Statement_Batch", "SQL_Statement_Current", and "Query_Plan_XML" fields from output (less resource-intensive on busy servers)
4. X - Exclude System Reserved SPIDs (1-50)

• @v_SPID: Limit result set to a specific SPID
• @v_Login: Limit result set to a specific Windows user name (if populated), otherwise by SQL Server login name
• @v_Database: Limit result set to a specific database
• @v_SQL_Text : Limit result set to SQL statement(s) containing specific text (ignored when "@v_Filter" parameter contains "C")

When using the procedure you will notice that query output contains a lot of handy information:

• SPECID: System Process ID with Execution Context ID
• Blocked: Blocking indicator (includes type of block and blocking SPID)
• Running: Indicates if SPID is currently executing (X), waiting (*), inactive (blank), has open transactions (•), or is a background task (--)
• Login_ID: Displays Windows user name (or login name if user name is unavailable)
• Login_Name: Full name of the user associated to the Login_ID (if available)
• Elapsed_Time: Total elapsed time since the request began (DAYS HH:MM:SS)
• CPU_Total: Cumulative CPU time since login (DAYS HH:MM:SS)
• CPU_Current: Cumulative CPU time for the current process (DAYS HH:MM:SS)
• Logical_Reads: Number of logical reads performed by the current process
• Physical_Reads: Number of physical reads performed by the current process
• Writes: Number of writes performed by the current process
• Pages_Used: Number of pages in the procedure cache currently allocated to the process
• Nesting_Level: Nesting level of the statement currently executing
• Open_Trans: Number of open transactions for the process
• Wait_Time: Current wait time (DAYS HH:MM:SS)
• Wait_Type: Current wait type
• Last_Wait_Type: Previous wait type
• Status: Status of the current process
• Command: Command currently being executed
• SQL_Statement_Batch: Batch SQL statement of the associated SPID
• SQL_Statement_Current: Current SQL statement of the associated SPID
• End_Of_Batch: Indicates if the current SQL statement is the last of the entire batch
• Query_Plan_XML: Execution plan of the associated SPID (in XML format)
• Plan_Cache_Object_Type: Displays which mechanism is being used for the cached plan (used in conjunction with Plan_Object_Type)
• Plan_Object_Type: Displays which mechanism is being used for the cached plan (used in conjunction with Plan_Cache_Object_Type)
• Plan_Times_Used: Number of times the plan has been utilized since its creation
• Plan_Size_MB: Size consumed by the plan in megabytes (MB)
• Since_SPID_Login: Total elapsed time since the client logged in (DAYS HH:MM:SS)
• Since_Last_Batch: Total elapsed time since the client last completed a remote stored procedure call or an EXECUTE statement (DAYS HH:MM:SS)
• Workstation_Name: Workstation name
• Database_Name: Database context of the SPID
• Application_Description: Application accessing SQL Server
• SPECID: System Process ID with Execution Context ID

If you ever need to remember what the input parameters / output columns are and what they mean, you can simply execute the following:

EXECUTE [dbo].[usp_who5] '?'

Best of all, if there is any blocking occurring on the server it will come right to the top of the result set and show you the details immediately (which SPID is blocked and by who, which SPIDs are blocking other processes, which are running in parallelism).

I typically map the procedure to keyboard combinations in SQL Server in order to run it on the fly with various input parameter combinations.

Any friendly feedback is always welcome. Enjoy!