SQL SERVER – Identifying Query Generating Malicious Wait Type

Just another day in my life when I got involved in the SQL Server Performance Comprehensive Database Performance Health Check, where I ended up with a server with a high amount of malicious Wait Type. In this blog post, we will learn about how to fix the performance issue with the malicious Wait Type.

While I was out at the festival celebration, I received an urgent email from the client that they are seeing overall performance slowdown in their system and they need my immediate help. As they were already my previous client, they had a link to make the payment as well. Without checking with me about my availability they made the payment and wrote an email for the help.  In normal cases, I first like to discuss my availability before I accept the payment. However, as I have worked with the client, I knew their server very well and I also got friends with some of the DBAs there.

SQL SERVER - Identifying Query Generating Malicious Wait Type malicious-Wait-Type-800x182

Malicious Wait Type

We started investigating their system for the slow performance and while running my SQL Server Wait Statistics Script, we figured out that the biggest wait type is THREADPOOL Wait Type and it is about 85% of the overall wait type. As I have worked many times before on the server which had similar problems, I was able to help them to resolve the issue very quickly.

The biggest issue which we were facing was to identify queries that were doing the malicious wait type. There is no DMV in SQL Server which will directly generate the wait type. We finally used the following trick to identify the queries which were generating the wait type.

I know that many SQL Server Experts would not like to use this method and they have their own methods to do the task. I am totally fine with any method you use to identify the bad wait type and query associated with it.

Identify the Session Creating Wait

Here is the first query which we ran to identify the session which was generating the bad wait and all the associated the wait with the query.

WHERE session_id in 
SELECT session_id
FROM sys.dm_exec_session_wait_stats

Identifying the Query From Session

Once we got the desired session_id which was generating the malicious wait type, we ran the following query to get the query from the session_id.

SELECT es.session_id, ib.event_info, status,
cpu_time, memory_usage, logical_reads, writes, row_count
total_elapsed_time, login_time, last_request_start_time, last_request_end_time
host_name, program_name, login_name, open_transaction_count
FROM sys.dm_exec_sessions AS es
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) AS ib
WHERE es.session_id in (
SELECT session_id
FROM sys.dm_exec_session_wait_stats
WHERE wait_type LIKE '%THREADPOOL%') -- replace threadpool with other wait

I guess you can replace the wait type to any other wait type and get necessary query. Every time, I learn something new when I see new SQL Server and new problems.

Reference: Pinal Dave (https://blog.sqlauthority.com)

SQL Scripts, SQL Server, SQL Sub Query, SQL Wait Stats
Previous Post
SQL SERVER – Turning Off Priority Boost Server Configuration Option on SSMS 18 Onwards
Next Post

Related Posts

2 Comments. Leave new

  • Wilfred van Dijk
    October 26, 2019 7:12 pm

    Curious to know what was causing this wait, was it a config issue?

  • Wilfred van Dijk
    October 26, 2019 7:22 pm

    Got this error: Msg 116, Level 16, State 1, Line 10
    Only one expression can be specified in the select list when the subquery is not introduced with EXISTS.

    Changing the subquery to a JOIN will fix this.
    (used with waitttype “%MEMORY_ALLOCATION_EXT%” which gave 2 waittypes, SQL2019 RC1)


Leave a ReplyCancel reply

Exit mobile version