SQL-Ex blog

В этой статье рассматриваются атрибуты, хранящиеся в кэше планов, и их структурирование в легко воспринимаемый формат. Это может помочь для исследования поведения необычных запросов, например, обладающих плохой производительностью, частой перекомпиляции или аномальных результатов.

Что такое кэш планов выполнения?

Для понимания и использования информации из кэша планов выполнения будет полезен (очень) краткий обзор кэша планов, его назначения и использования.

Обработка запроса в SQL Server требует создания и использования плана выполнения. План обеспечивает инструкции, которые детализируют то, как извлекать, соединять, сортировать и читать/записывать данные, чтобы результаты соответствовали запросам. Если запрос плохо выполняется, план выполнения может предоставить детали выполнения, и почему оптимизатор запросов выбрал именно этот план. План можно просмотреть непосредственно в SQL Server Management Studio, включив его в GUI, например, так:



После включения можем выполнить, например, такой запрос:

SELECT

	Product.ProductID

FROM Production.Product

WHERE Product.Name = 'External Lock Washer 3';

Здесь появляется новая вкладка, содержащая план выполнения:



Щелкнув на вкладке, видим подробный план выполнения:



Здесь может быть найдена информация о числе строк, вводе-выводе, использовании ЦП. Каждый элемент данных, который можно здесь увидеть (и много больше), также доступен в системных представлениях, которые можно проанализировать, используя T-SQL.

В то время как графический план полезен для ручного исследования проблем, использование представлений позволяет выполнить массовый анализ и дает возможность автоматизировать некоторые направления мониторинга и настройки производительности.

Microsoft предоставляет обширную документацию по планам выполнения. Это хорошее место для старта. Также написано много полезных статей на эту тему, например блестящее введение от Grant Fritchey.

Использование динамических административных представлений для анализа планов выполнения

Вот небольшая часть системных представлений и функций, которые предоставляют ценные данные о планах выполнения и связанных с ними метриках:

Sys.dm_exec_query_plan: Эта функция выводит план выполнения в XML для заданного plan_handle.
Sys.dm_exec_sql_text: Функция, которая возвращает текст оператора SQL для заданного plan_handle.
Sys.dm_exec_query_stats: Содержит море статистики для кэшированных планов выполнения, например, время, ЦП, ввод/вывод, число строк и многое другое.
Sys.dm_exec_cached_plans: Содержит базовую информацию об использовании для недавно кэшированных планах выполнения, включая тип объекта, размер и число использований плана.
Sys.dm_exec_plan_attributes: Подробная информация о том, как генерировался план, включая уровень совместимости и опции SET.

Каждое из этих представлений дает полезную информацию о запросах, которые выполнялись SQL Server, и некоторые или все могут потребоваться для ответа на конкретный вопрос об этих запросах.

Заметим, что эти представления могут дать информацию только о планах выполнения, которые в настоящее время находятся в кэше. История отсутствует. Как только план удаляется из куша, эти представления не смогут больше вернуть информацию о нем.

Аналогично, если служба SQL Server перезапускается или кэш планов очищается, то эти представления также становятся пустыми (пока не будут выполнены запросы, чтобы наполнить их снова). Таким образом, рассматривайте эти представления как временное окно в работу SQL Server, и может потребоваться их повторный запуск, чтобы полностью понять стоящую перед вами проблему оптимизации.

Пример подробного плана выполнения

Для иллюстрации того, как смотреть эти данные, возьмем следующий пример:

SELECT

	Product.ProductID,

	Product.Name,

	Product.Color, 

	SalesOrderDetail.SalesOrderID,

	SalesOrderDetail.OrderQty,

	SalesOrderDetail.UnitPrice

FROM Production.Product 

INNER JOIN Sales.SalesOrderDetail

ON SalesOrderDetail.ProductID = Product.ProductID

WHERE Product.Name = 'External Lock Washer 3';

Этот запрос возвращает ID для единственного товара в этой таблице:



Теперь, когда этот запрос был выполнен, некоторые из представленных выше представлений могут продемонстрировать, что план этого запроса действительно находится в кэше планов и, соответственно, может быть просмотрен:

SELECT dm_exec_cached_plans.plan_handle,

       dm_exec_sql_text.text,

	   dm_exec_query_plan.query_plan,

	   database_name = databases.name,

	   dm_exec_query_stats.creation_time,

	   dm_exec_query_stats.last_execution_time

FROM sys.dm_exec_cached_plans

    CROSS APPLY sys.dm_exec_sql_text(plan_handle)

    CROSS APPLY sys.dm_exec_query_plan(plan_handle)

    INNER JOIN sys.dm_exec_query_stats

	ON dm_exec_query_stats.plan_handle = 

         dm_exec_cached_plans.plan_handle

	LEFT JOIN sys.databases

	ON databases.database_id = dm_exec_query_plan.dbid

WHERE dm_exec_sql_text.text LIKE '%External Lock Washer 3%'

Фильтр гарантирует, что только самый последний запрос, который тестировался, включается в результаты. Этот запрос начинает с dm_exec_cached_plans и соединяется с другими представлениями, чтобы получить текст запроса, план выполнения, время создания/последнего выполнения и имя базы данных:



Plan_handle дает уникальный идентификатор, который может быть использован в других системных представлениях/функциях для расширения возвращаемых данных. План запроса представлен в XML, по нему можно щелкнуть в SQL Server Management Studio, чтобы получить его в графическом виде.

Начиная отсюда, с помощью этих представлений могут быть собраны различные метрики, свойства и подробности относительно группировки, фильтрации и получения дополнительных столбцов, описывающих процесс выполнение запроса.

Замечание. Если на сервере включена опция Optimize for ad-hoc workloads, то может потребоваться выполнить несколько раз запросы в этой статье, чтобы создать полный план (не заглушку) в кэше. Кроме того, если тестовый сервер испытывает давление на кэш планов, планы могут не сохраняться в кэше длительное время до вытеснения. Поэтому, если результаты не отображаются, как ожидалось при работе с этой статьей, перезапустите этот (или другой) тестовый запрос для генерации большего количества данных в кэше, чтобы было с чем работать.

Углубляемся в атрибуты плана

Среди различных системных представлений и функций, которые обсуждались до сих пор, sys.dm_exec_plan_attributes наиболее плохо документирована и реже всего используется. Следовательно, имеется прекрасная возможность узнать о ее содержимом и как лучше просматривать данные, выводимые этим представлением!

Чтобы ваши ожидания оправдались, обратитесь к документации Microsoft на это представление. Имеет смысл, правда? Для начала все столбцы, возвращаемые этой функцией, можно посмотреть так:

DECLARE @plan_handle UNIQUEIDENTIFIER;

SELECT

	@plan_handle = dm_exec_cached_plans.plan_handle

FROM sys.dm_exec_cached_plans

CROSS APPLY sys.dm_exec_sql_text(plan_handle)

WHERE dm_exec_sql_text.text LIKE '%External Lock Washer 3%'

SELECT

	dm_exec_cached_plans.plan_handle,

	dm_exec_plan_attributes.*

FROM sys.dm_exec_cached_plans

OUTER APPLY sys.dm_exec_plan_attributes(plan_handle)

WHERE cacheobjtype = 'Compiled Plan'

AND dm_exec_cached_plans.plan_handle = @plan_handle

ORDER BY dm_exec_plan_attributes.attribute;

Этот запрос извлекает дескриптор плана для единственного интересующего нас запроса и возвращает все атрибуты этого плана:



Чтобы использовать эти атрибуты, требуется декодировать, чтобы лучше понять их содержание. Остальная часть статьи будет посвящена некоторым атрибутам в sys.dm_exec_plan_attributes и тому, как использовать их с максимальной пользой.

Замечание. Повсюду в статье к dm_exec_cached_plans добавлен фильтр для фильтрации только “Compiled Plan” (скомпилированный план). Имеются также атрибуты для заглушек плана, деревьев синтаксического разбора и других объектов, которые хранятся в кэше. Поэтому в целях сбора данных может иметь значение изменить или удалить этот фильтр для расширения области применимости данных скриптов.

Уровень совместимости

Простой атрибут для просмотра - уровень совместимости:

SELECT

	dm_exec_plan_attributes.attribute,

	dm_exec_plan_attributes.value,

	COUNT(*) AS execution_plan_count

FROM sys.dm_exec_cached_plans

OUTER APPLY sys.dm_exec_plan_attributes(plan_handle)

WHERE cacheobjtype = 'Compiled Plan'

AND dm_exec_plan_attributes.attribute = 'compat_level'

GROUP BY dm_exec_plan_attributes.attribute, 

     dm_exec_plan_attributes.value

ORDER BY dm_exec_plan_attributes.attribute, 

     dm_exec_plan_attributes.value;

Он возвращает по строке на уровень совместимости для всех планов, находящихся в кэше:



Это отличный пример того, как можно проверить атрибуты на высоком уровне, а затем, если обнаружится что-то необычное, может быть проведено дальнейшее исследование для определения источника неожиданных уровней совместимости. Например, некоторые детали для конкретного уровня совместимости можно вернуть таким образом:

SELECT

	dm_exec_cached_plans.plan_handle,

	dm_exec_cached_plans.usecounts,

	dm_exec_plan_attributes.attribute,

	dm_exec_plan_attributes.value,

	dm_exec_sql_text.text AS query_text,

	databases.name AS database_name

FROM sys.dm_exec_cached_plans

CROSS APPLY sys.dm_exec_query_plan(plan_handle)

LEFT JOIN sys.databases

ON databases.database_id = dm_exec_query_plan.dbid

OUTER APPLY sys.dm_exec_plan_attributes(plan_handle)

CROSS APPLY sys.dm_exec_sql_text(plan_handle)

WHERE cacheobjtype = 'Compiled Plan'

AND dm_exec_plan_attributes.attribute = 'compat_level'

AND dm_exec_plan_attributes.value = 150;

Результаты дают некоторую дополнительную информацию о любом плане выполнения, который генерировался при использовании уровня совместимости 150 (SQL Server 2019):



Из соответствующих представлений/функций могут быть добавлены дополнительные столбцы, чтобы узнать больше о запросе и его источнике, если вам потребуются детали.

Подобное исследование может быть особенно полезно во время или после апгрейда проекта SQL Server, чтобы гарантировать выполнение запросов с использованием ожидаемого уровня совместимости. Заметим, что показанный здесь режим совместимости является режимом базы данных, в которой был создан T-SQL (и, следовательно, план выполнения). Если источником плана является хранимая процедура или функция, возвращаемый уровень совместимости будет уровнем базы данных, содержащей процедуру/функцию.

Полный список режимов совместимости можно найти в обширной документации Microsoft.

Опции SET

Опции SET, используемые когда генерируется план выполнения, могут иметь широкий спектр последствий при выполнении запроса. Такие установки, как ANSI_NULLS, QUOTED_IDENTIFIER, ARITH_ABORT и другие фундаментально меняют правила, которым следует оптимизатор, и то, как обрабатываются данные в SQL Server. Это, в конечном итоге, означает, что результаты запроса могут варьироваться в зависимости от этих установок и неожиданные установки могут привести даже к ошибкам.

Настройки запроса устанавливаются, когда выполняется подключение к SQL Server, и значения по умолчанию определяются как на уровне сервера, так и базы данных. Приложение, выполняющее запрос, может специфицировать установки на время подключения, которые будут принудительно установлены вместо значений по умолчанию. Из-за этой сложности вполне можно получить выполнение запросов с неожиданными настройками. Бывает также сложно вычислить виновника.

Один и тот же запрос с разными опциями SET может генерировать различные планы выполнения, тем самым наполняя кэш повторяющимися копиями одного и того же запроса. Некоторые опции SET могут включить перекомпиляцию при изменении в середине пакета, таким образом тратя ресурсы на перекомпиляцию того, что должно было быть совершенно правильным планом выполнения. Это происходит потому, что планы выполнения генерируются с использованием установок, которые даются строкой подключения при первом создании сессии. Если позже эти настройки из строки подключения изменяются, любые планы выполнения, использующие старые настройки перестают быть действительными для последующих запросов в пакете.

Еще больше усложняет дело то, что эти данные хранятся в одной строке на каждый план выполнения в dm_exec_plan_attributes, и закодированы в числовой битовой карте. Опции SET для нашего предыдущего тестового запроса можно просмотреть с помощью следующего запроса:

SELECT

	dm_exec_plan_attributes.attribute,

	dm_exec_plan_attributes.value,

	dm_exec_sql_text.text AS query_text,

	databases.name AS database_name

FROM sys.dm_exec_cached_plans

CROSS APPLY sys.dm_exec_query_plan(plan_handle)

LEFT JOIN sys.databases

ON databases.database_id = dm_exec_query_plan.dbid

OUTER APPLY sys.dm_exec_plan_attributes(plan_handle)

CROSS APPLY sys.dm_exec_sql_text(plan_handle)

WHERE cacheobjtype = 'Compiled Plan'

AND dm_exec_plan_attributes.attribute = 'set_options'

AND dm_exec_sql_text.text LIKE '%External Lock Washer 3%';

Результат запроса:



Опции SET указываются единственным номером 4347. Это сумма предопределенных битов, где каждый бит указывает на конкретную опцию SET, при этом 1 означает "включена", а 0 - "выключена". Документация Microsoft, ссылка на которую приведена в начале этого раздела, дает полный список опций, и соответствующие им биты в карте. На момент написания этой статьи было идентифицировано 19 опций SET, поэтому они не будут скопированы сюда подробно. Некоторые опции имеют отношение к конкретной версии, и, следовательно, могут не применяться к более старым версиям SQL Server.

Используя список от Microsoft, можно определить, что 4347 отвечает следующим включенным опциям SET:
ARITH_ABORT (4096)
ANSI_NULL_DFLT_ON (128)
QUOTED_IDENTIFIER (64)
ANSI_NULLS (32)
ANSI_WARNINGS (16)
CONCAT_NULL_YIELDS_NULL (8)
ParallelPlan (2)
ANSI_PADDING (1)
4096 + 128 + 64 + 32 + 16 + 8 + 2 + 1 = 4347

Это неудобно! Без автоматизированного процесса, дающего легкочитаемый результат, нам суждено делать математические или канцелярские ошибки и неверно истолковывать эти данные.

Следующий запрос выбирает все кэшированные планы и преобразует их опции SET в список столбцов с именами опций SET и значениями 1 или 0 для указания их статуса для соответствующего плана:

WITH CTE_SET_OPTIONS_PIVOT AS (

	SELECT plan_handle, objtype, pvt.set_options 

           AS set_options_sql_variant, 

           CAST(pvt.set_options AS INT) AS set_options

	FROM (SELECT

			dm_exec_cached_plans.plan_handle,

			dm_exec_cached_plans.objtype,

			dm_exec_plan_attributes.attribute,

			dm_exec_plan_attributes.value

		  FROM sys.dm_exec_cached_plans

		  OUTER APPLY sys.dm_exec_plan_attributes(plan_handle)

		  WHERE cacheobjtype = 'Compiled Plan') PLAN_ATTRIBUTES

	PIVOT (MAX(PLAN_ATTRIBUTES.value) FOR PLAN_ATTRIBUTES.attribute 

             IN ([set_options])) AS pvt),

CTE_SET_OPTIONS AS (

	SELECT

		set_options,

		objtype,

		COUNT(*) AS plan_count

	FROM CTE_SET_OPTIONS_PIVOT

	GROUP BY set_options, objtype),

CTE_RESULTS AS (

	SELECT

		set_options,

		objtype,

		plan_count,

		262144 AS divider,

		CAST('' AS VARCHAR(MAX)) AS bitwise_result,

		set_options AS set_options_intermediary

	FROM CTE_SET_OPTIONS

	UNION ALL

	SELECT

		set_options,

		objtype,

		plan_count,

		CAST(divider / 2 AS INT) AS divider,

		CASE WHEN set_options_intermediary >= divider

			THEN bitwise_result + '1'

			ELSE bitwise_result + '0'

		END AS bitwise_result,

		CASE WHEN set_options_intermediary >= divider

			THEN set_options_intermediary - divider

			ELSE set_options_intermediary

		END AS set_options_intermediary

	FROM CTE_RESULTS

	WHERE divider >= 1)

SELECT

	set_options,

	objtype,

	plan_count,

	bitwise_result,

	CASE WHEN SUBSTRING(bitwise_result, 1, 1) = '1' 

        -- Применяется к: SQL Server 2012 (11.x) to SQL Server 2019 (15.x)

        THEN 1 ELSE 0 END AS ROWCOUNT_262144, 

	CASE WHEN SUBSTRING(bitwise_result, 2, 1) = '1' 

        -- Указывает, что опция базы данных PARAMETERIZATION 

        -- была установлена в FORCED, когда компилировался план.

        THEN 1 ELSE 0 END AS UPON_131072, 

	CASE WHEN SUBSTRING(bitwise_result, 3, 1) = '1' 

        THEN 1 ELSE 0 END AS LanguageID_65536,

	CASE WHEN SUBSTRING(bitwise_result, 4, 1) = '1' 

        THEN 1 ELSE 0 END AS DATEFORMAT_32768,

	CASE WHEN SUBSTRING(bitwise_result, 5, 1) = '1' 

        THEN 1 ELSE 0 END AS DATEFIRST_16384,

	CASE WHEN SUBSTRING(bitwise_result, 6, 1) = '1' 

        THEN 1 ELSE 0 END AS NUMERIC_ROUNDABORT_8192,

	CASE WHEN SUBSTRING(bitwise_result, 7, 1) = '1' 

        THEN 1 ELSE 0 END AS ARITH_ABORT_4096,

        -- Указывает, что запрос был послан внутренней 

        --системной хранимой процедурой.

	CASE WHEN SUBSTRING(bitwise_result, 8, 1) = '1' 

        THEN 1 ELSE 0 END AS ResyncQuery_2048, 

	CASE WHEN SUBSTRING(bitwise_result, 9, 1) = '1' 

        -- Указывает, что план содержит оптимизацию единственной

        --строки для триггера AFTER дельта-таблиц.

        THEN 1 ELSE 0 END AS TriggerOneRow_1024,

        -- Указывает, что план не использует рабочую таблицу

        --для применения операции FOR BROWSE.

	CASE WHEN SUBSTRING(bitwise_result, 10, 1) = '1' 

        THEN 1 ELSE 0 END AS NoBrowseTable_512, 	

	CASE WHEN SUBSTRING(bitwise_result, 11, 1) = '1' 

        THEN 1 ELSE 0 END AS ANSI_NULL_DFLT_OFF_256,

	CASE WHEN SUBSTRING(bitwise_result, 12, 1) = '1' 

        THEN 1 ELSE 0 END AS ANSI_NULL_DFLT_ON_128,

	CASE WHEN SUBSTRING(bitwise_result, 13, 1) = '1' 

        THEN 1 ELSE 0 END AS QUOTED_IDENTIFIER_64,

	CASE WHEN SUBSTRING(bitwise_result, 14, 1) = '1' 

        THEN 1 ELSE 0 END AS ANSI_NULLS_32,

	CASE WHEN SUBSTRING(bitwise_result, 15, 1) = '1' 

        THEN 1 ELSE 0 END AS ANSI_WARNINGS_16,

	CASE WHEN SUBSTRING(bitwise_result, 16, 1) = '1' 

        THEN 1 ELSE 0 END AS CONCAT_NULL_YIELDS_NULL_8,

	CASE WHEN SUBSTRING(bitwise_result, 17, 1) = '1' 

        THEN 1 ELSE 0 END AS FORCEPLAN_4,

	CASE WHEN SUBSTRING(bitwise_result, 18, 1) = '1' 

        -- Указывает, что были изменены опции параллельного выполнения плана.

        THEN 1 ELSE 0 END AS ParallelPlan_2, 

	CASE WHEN SUBSTRING(bitwise_result, 19, 1) = '1' 

        THEN 1 ELSE 0 END AS ANSI_PADDING_1

FROM CTE_RESULTS

WHERE divider = 0

ORDER BY plan_count DESC

Этот (большой) запрос решает следующие задачи:

1. Преобразует метку set_options в заголовок столбца с его значением в качестве данных ниже заголовка.


2. Группирует по опциям SET и типу объекта.


3. Использует рекурсивное CTE для обработки каждого бита в опциях SET и преобразует числовое представление в двоичную бинарную карту (нули и единицы).


4. Использует оператор CASE для оценки каждого BIT и возвращает заголовок столбца для каждого со значением ниже.

Результат выглядит следующим образом:



Это позволяет быстро и легко просмотреть результаты. Заголовки столбцов пишутся в точном соответствии с документацией Microsoft.

Подобный запрос выполняет похожую функцию для проверки уровня совместимости, приведенную выше, позволяя высокоуровневому запросу быстро увидеть все комбинации опций SET, которые присутствуют на сервере. Используя эти данные, можно определить наличие проблемы, и, если так, запросить более детальные данные для определения приложения, которое генерирует аномальные установки подключения.

DATEFORMAT и DATEFIRST

Эти установки влияют на обработку дат и будут непосредственно влиять на результаты любых математических операций с ними. Поэтому неожиданные значения могут привести к плохим данным и/или ошибкам при обработке неверных дат.

Просмотр этих данных в sys.dm_exec_cached_plans прост:

SELECT

	dm_exec_cached_plans.objtype,

	dm_exec_cached_plans.plan_handle,

	dm_exec_plan_attributes.attribute,

	dm_exec_plan_attributes.value

FROM sys.dm_exec_cached_plans

OUTER APPLY sys.dm_exec_plan_attributes(plan_handle)

WHERE cacheobjtype = 'Compiled Plan'

AND attribute = 'date_format'

ORDER BY dm_exec_plan_attributes.attribute;

Их интерпретация требует немного больше работы:



Что означает 1? Предположительно это означает, что даты упорядочены по Месяц/День/Год, т.к. это настройка по умолчанию для моего сервера. Другие значения можно проверить экспериментально:

SET DATEFORMAT 'dmy';

SELECT TOP 1 * from Production.Product;

Это меняет формат даты на другой употребимый формат - День/Месяц/Год. Результаты в DMV следующие:



Новый запрос (выполните несколько раз) коррелирует с форматом даты 2. Дальнейшее тестирование показало следующий диапазон значений:

Формат даты	значение атрибута DATEFORMAT 

MMDDYY	1

DDMMYY	2

YYMMDD	3

YYDDMM	4

MMYYDD	5

DDYYMM	6

В то время как приложение может предоставлять локализационные варианты для своих пользователей, позволяющие им вводить даты используя разные форматы, важно, чтобы эти данные вводились в SQL Server в корректном формате даты. Это задача, которую лучше обрабатывать в приложении, чем в базе данных. Это позволяет избежать подверженной ошибкам необходимости настраивать параметры формата даты на лету при изменении дат в базе данных.

Если подозревается неверный формат даты, проверка кэша плана выполнения с целью убедиться, что все значения согласуются и соответствуют ожидаемому формату в схеме выше, может подтвердить наличие проблемы и позволить вытащить дополнительные данные из кэша для поиска ошибки и устранения несоответствия.

Атрибут date_first возвращает первый день недели, который играет важную роль при выполнении вычислений дней недели или при описании данных между различными локалями, которые могут считать воскресенье или понедельник первым днем недели.

Значения этого атрибута меняются в диапазоне от 1 (понедельник) до 7 (воскресенье). В SQL Server значением по умолчанию является 7 (воскресенье). Настройки сервера можно получить с помощью следующего оператора:

SELECT @@DATEFIRST;

Как и ранее, следующий запрос возвращает этот атрибут для всех кэшированных запросов:

SELECT

	dm_exec_cached_plans.objtype,

	dm_exec_cached_plans.plan_handle,

	dm_exec_plan_attributes.attribute,

	dm_exec_plan_attributes.value

FROM sys.dm_exec_cached_plans

OUTER APPLY sys.dm_exec_plan_attributes(plan_handle)

WHERE cacheobjtype = 'Compiled Plan'

AND attribute = 'date_first'

ORDER BY dm_exec_plan_attributes.attribute;

Результаты показывают, что все планы в моем локальном кэше имеют настройку по умолчанию - 7:



Эту установку можно изменить в локальном подключении с помощью оператора:

SET DATEFIRST 1;

При выполнении нескольких пробных запросов с последующим выполнением вышеприведенного запроса к кэшу планов в результате покажут смешанные значения для атрибута date_first:



Если приложение видит аномальные значения для вычислений, включающих день недели (DW), то проверка этого атрибута является отличным тестом для гарантии отсутствия неожиданных установок, передаваемых через строку подключения.

Другие атрибуты

На время написания имелось 30 документированных атрибутов, хранящихся в sys.dm_exec_plan_attributes. Список, вероятно, будет расти по мере реализации новых возможностей в SQL Server, которые повлияют на генерацию плана и должны быть задокументированы.

Хотя рассматривать все эти атрибуты непрактично, т.к. многие из них либо просты, либо нечасто используются, есть несколько таких, о которых стоит упомянуть вкратце:

dbid

Это база данных, на которую ссылается план и которая обычно будет базой данных, где возник пакет.

sql_handle

Этот GUID может использоваться для ссылки планов выполнения на надлежащий текст SQL, который можно обнаружить в sys.dm_exec_sql_text. Поскольку текст запроса может быть объемным, многие разработчики и администраторы хэшируют его, позволяя общим запросам быть сгруппированным вместе без необходимости поддерживать потенциально большое количество текста.

inuse_exec_context

Это один из самых интересных, т.к. он может дать число исполняемых в настоящее время пакетов, которые используют этот план выполнения. Это хороший способ измерить степень конкуренции за план и то, как часто он повторно используется, при более детализированной информации, чем посредством sys.dm_exec_query_stats.

Интеллектуальный анализ кэша планов SQL Server

SQL Server поддерживает обширную кладовую подробной информации о планах выполнения и связанных с ними метаданных. С помощью динамических административных представлений, на которые ссылается настоящая статья, возможно понять как выполнялся запрос и некоторые детали, которые могут оказать влияние на производительность, результаты и повторное использование плана.

Хотя функция dm_exec_plan_attributes является не самым простым объектом для употребления, сохранение и использование предварительно написанных запросов может сэкономить вам массу времени, особенно когда обнаружена проблема производительности, которая требует немедленной реакции.

Поскольку настройки соединения во время выполнения могут отличаться от системных или настроек базы данных по умолчанию, наличие возможности быстрой идентификации этих различий может помочь решить проблему с багами в приложении или обнаружить "кривые" запросы, которые ведут себя не так, как ожидалось.