Ошибка в sys.dm_exec_query_plan_stats

Автор: Brent Ozar, There’s a Bug in sys.dm_exec_query_plan_stats.

Когда вы включаете последние актуальные планы в SQL Server 2019 и новее:

ALTER DATABASE SCOPED CONFIGURATION SET LAST_QUERY_PLAN_STATS = ON;

Системная функция sys.dm_exec_query_plan_stats должна показывать последний актуальный план запроса. Мне эта штука то попадалась, то нет, но моя последняя проблема с ней заключается в том, что два числа откровенно неверны. Она путает время CPU и прошедшее время.

Вот простой запрос, чтобы это доказать:

SET STATISTICS TIME ON;
 
SELECT TOP 101 value
FROM GENERATE_SERIES(-10000000, 10000000)
ORDER BY 1 DESC;
 
SET STATISTICS TIME OFF;

Этот запрос выполняется параллельно, потребляет много CPU и завершается за несколько секунд:

 SQL Server Execution Times:
   CPU time = 7467 ms,  elapsed time = 3106 ms.

Время CPU больше прошедшего времени, что указывает на то, что запрос выполнялся параллельно на нескольких ядрах. Числа из SET STATISTICS TIME верны, как и временные показатели в актуальном плане запроса.

Но если вы проверите последний «актуальный» план запроса в sys.dm_exec_query_plan_stats:

WITH XMLNAMESPACES (DEFAULT 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
SELECT  stmt_text             = SUBSTRING(st.text,
                                          (qs.statement_start_offset/2) + 1,
                                          ((CASE qs.statement_end_offset
                                                WHEN -1 THEN DATALENGTH(st.text)
                                                ELSE qs.statement_end_offset
                                            END - qs.statement_start_offset)/2) + 1),
        truth_cpu_ms          = qs.last_worker_time  / 1000,
        truth_elapsed_ms      = qs.last_elapsed_time / 1000,
        plan_xml_CpuTime      = qps.query_plan.value('(//QueryTimeStats/@CpuTime)[1]',     'bigint'),
        plan_xml_ElapsedTime  = qps.query_plan.value('(//QueryTimeStats/@ElapsedTime)[1]', 'bigint'),
        plan_xml              = qps.query_plan
FROM    sys.dm_exec_query_stats                            qs
        CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle)    st
        CROSS APPLY sys.dm_exec_query_plan_stats(qs.plan_handle) qps
WHERE   st.text LIKE '%GENERATE_SERIES(-10000000, 10000000)%'
  AND   st.text NOT LIKE '%dm_exec_query_plan_stats%';

Числа оказываются ровно переставленными:

Последний «актуальный» план показывает, что запрос занял 8 секунд (хотя это не так) и что он потребил меньше времени CPU, чем прошедшего времени. Числа просто переставлены местами.

Я сообщил об этой ошибке, но здесь начинается сложность как для автора сценариев. Конечно, сейчас я могу просто переставить числа в своих сценариях First Responder Kit, исправляя ошибку Microsoft, но… теперь мне нужно следить за каждым предстоящим выпуском накопительных обновлений, читать, исправили ли они ошибку, затем возвращаться ко всем соответствующим сценариям, добавлять проверку номера сборки и менять математику для исправленных сборок.