Внутренняя часть памяти рабочего пространства

За чтение книг по внутренним компонентам и поиску и устранению неисправностей в SQL Server 2008 (заимствовано из локальной библиотеки в Иллинойсе) Кристианом Болтоном, Брентом Озаром и т. Д. Я пытаюсь найти понимание и подтверждение на SQL-сервере и провести много поисков в Интернете, и я был бы признателен, если бы кто-то можете подтвердить или исправить мое понимание.

Каждый запрос или операция, которая требует предоставления памяти запроса, будет нуждаться в памяти рабочего пространства. В общем запросе, использующем Sort, Hash Match Join, Parallelism (не уверен в этом), Bulk Insert (не уверен), Rebuild Index и т. Д. Потребуется память рабочей области запроса.

Память рабочей области является частью буферного пула SQL Server (она выделяется как часть пула буферов), а максимальная память рабочей области составляет 75% памяти, выделяемой для пула буферов. По умолчанию один запрос не может получить более 25% памяти рабочей области (в SQL 2008 / SQL 2012 - контролируется группой рабочей нагрузки по умолчанию Resource Governor из коробки).

Ищу подтверждение моего понимания

1) Рассматривая систему с 48 ГБ ОЗУ и максимальной памятью сервера, настроенной на 40 ГБ, означает ли это, что максимальная память рабочей области ограничена 30 ГБ, и один запрос не может получить память рабочей области (память запросов) более 10 ГБ. Так что, если у вас неверный запрос, работающий с миллиардом строк, выполняющих массивное хеш-соединение, и вам требуется более 10 ГБ памяти (памяти рабочего пространства), будет ли вам все равно пройти через эту очередь предоставления памяти или сразу же пролить на диск?

2) Если запросу, выполняющему массивную операцию сортировки, было выделено 5 МБ памяти рабочей области, и во время выполнения запроса оптимизатор запросов осознает, что из-за неверной статистики или отсутствующих индексов этому запросу фактически потребуется 30 МБ памяти рабочей области, немедленно выльется в базу данных. Даже если во время выполнения в системе будет достаточно оперативной памяти, если запрос превысил выделенную рабочую память во время выполнения, он должен будет пролить ее на диск. Правильно ли мое понимание?

Будет ли это вообще проходить через очередь предоставления памяти или сразу на диск?

Это не работает таким образом. После того, как был выбран план, требующий предоставления памяти, запрос должен получить разрешение, чтобы он прошел через очередь. Разлив, если таковой имеется, происходит намного позже в цикле выполнения. Запрос не может решить пойти дальше без предоставления и "разлива" вместо этого. Он должен получить грант и, если это так, начать выполнение. Если грант окажется недостаточным (из-за неверной оценки или из-за получения гораздо меньшего гранта, чем запрошено), запрос будет вынужден выполнить запрос.

если оптимизатор запросов понимает, что из-за плохой статистики или отсутствующих индексов

Строго говоря, это не оптимизатор, это выполнение запроса. Query Optimizer имеет только право голоса при принятии решения о плане, но как только план выбран и запущен в исполнение, оптимизатор уже не в поле зрения. Кроме того, «отсутствующие индексы» здесь не играют роли. Отсутствующий индекс может вызвать плохой план, но он не может влиять на выполнение этого «плохого» плана, поскольку этот план был построен с учетом того, какие именно индексы существуют на самом деле, поэтому он точно знает, что он может и не может делать. Разливы происходят почти всегда из-за плохих оценок, т.е. плохая статистика или плохие алгоритмы оценки мощности в оптимизаторе и в исполнении (это становится действительно сложным, если вы копаетесь в деталях, поэтому я остановлюсь здесь).

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

К сожалению, да. Однако оптимизатор должен разработать план, который использует доступную оперативную память.

Я рекомендую прочитать Понимание предоставления памяти SQL-сервера - это лучшая информация по этому вопросу с большим отрывом.