Когда вы запускаете запрос, SQL Server угадывает, сколько памяти вам понадобится для таких вещей, как сортировки и объединения. По мере запуска вашего запроса он получает выделение памяти рабочего пространства, а затем начинает работу.

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

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

В Microsoft знали об этой проблеме, и они продвигаются к исправлению:

• В SQL 2012 SP3 мы получили инструменты для диагностики грантов памяти
• В SQL 2016 пользователи столбцов-хранилищ получили адаптивную память
• В SQL 2017 CU3 мы получили инструменты для диагностики разливов TempDB

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

Посмотрим, как они работают

Мы начнем с базы данных StackOverflow2010, небольшой версии 10 ГБ, чтобы вы могли работать с ей дома. Мы собираемся установить уровень совместимости базы данных на 150:

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

Transact-SQL

В первый раз, когда мы запускаем запрос, в плане выполнения появляется предупреждение о слишком высоком гранте памяти:

Щелкните правой кнопкой мыши на SELECT, перейдите в свойства и проверьте информацию о гранте:

Желаемая память составляет 1,8 ГБ, а обратная связь еще не настроена, поскольку это первое выполнение.

Запустите его снова, и предупреждение плана исчезло!

И в свойствах выделения памяти, грант памяти является путем вниз. Желаемая память составляет всего 111 МБ, и мы видим, что обратная связь с поддержкой памяти корректируется:

Положите свой палец на F5 и нажмите еще раз, а затем:

Грант памяти стабилизировался на уровне 111 МБ!

Это потрясающе, но есть недостатки.

Если грант колеблется слишком часто, например, если ваш запрос чувствителен к проблемам с параметрами sniffing и имеет совершенно разные цифры использования памяти, SQL Server попытается скорректировать грант, но затем, в конце концов, сдастся после 32 исполнений.

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

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

Здесь мы просматриваем план запроса из кеша (используя sp_BlitzCache), и мы вообще не получаем никаких данных обратной связи. Есть небольшая подсказка: если мы проанализируем широкие различия в минимальных и максимальных грантах от sp_BlitzCache, который поступает из sys.dm_exec_query_stats:

Но это все. Нет счетчиков Perfmon, чтобы показать, что это происходит. Чтобы диагностировать проблемы с ним, вам нужно будет выкинуть Books Online и настроить сеанс расширенных событий, наблюдая за memory_grant_updated_by_feedback и memory_grant_feedback_loop_disabled.

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

Что нового в SQL Server 2019: более быстрые переменные таблицы

Что нового в SQL Server 2019 CTP 2.1: более быстрые функции

No Comments