Почему запросы вызывают разлив в базу данных tempdb?

Задний план

Я нахожусь в процессе миграции базы данных 160 ГБ из MSSQL 2008 (стандарт) на сервер Win 2008 с 48 ГБ ОЗУ на новый сервер под управлением MSSQL 2012 (64-разрядная веб-версия) на Win 2012 с 64 ГБ ОЗУ. Старый сервер работает и загружен; новый сервер не работает Новый сервер имеет 8 файлов tempdb (по 4 ГБ каждый).

проблема

При тестировании на новом сервере я вижу, что шаги в многочисленных запросах вызывают оповещения с упоминанием «оператор использовал базу данных tempdb для разлива данных во время выполнения». Мне удалось избежать сортировки, переписав некоторые запросы, но это не решает проблему. Те же самые запросы на старом сервере не вызывают разливов. Я читал, что разливы случаются, когда MSSQL не может завершить операцию в памяти и должен пролить / страницу в tempdb. Должен ли я беспокоиться о разливах?

Примеры

введите описание изображения здесь

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

Проблема памяти

Я установил максимальный параметр памяти для MSSQL 58 из 64 ГБ. В настоящее время MSSQL использует около 35 ГБ этой памяти, но имеет рабочий набор всего 682 МБ. На старом сервере (хотя и на производстве, для обработки нагрузки) выделено 44 ГБ памяти, выделенной для MSSQL, из которых 43,5 ГБ находятся в рабочем наборе.

введите описание изображения здесь

Я не знаю, могут ли разливы быть связаны с настройкой памяти - у кого-нибудь есть идеи? У MSSQL в настоящее время есть свободные места в ОЗУ, так почему же он переходит в базу данных tempdb для некоторых сортировок и хеш-совпадений?

sql-server sql-server-2012

— Энди У
источник

Предупреждение в плане выполнения нового в 2012 году. Вы проверяли, что оно не распространялось все время на старом сервере? Вы следили за этим?

— Мартин Смит

@MartinSmith ах, не понял, что оповещение было новым. Я не отслеживал разливы на старом сервере. Будем расследовать это.

Немного касательная точка, но я сижу перед объединением из 10 таблиц, которое по умолчанию в основном использует объединения слияния с очень хорошими оценками строк, что вызывает разливы уровня 0 базы данных tempdb и время выполнения 25 с. Принудительное соединение хешей (и порядок) удаляет разливы и запускается за 9 секунд. Мне остается задаться вопросом, является ли это слиянием или хэшем или разливом, вызывающим различие, и правильно ли оптимизатор взвешивает эффект, казалось бы, предстоящего разлива (потому что оценки строк очень хороши).

— crokusek

Новый сервер имеет аппаратное numa?

— stacylaray

Здесь есть несколько разных вопросов:

В: Почему раньше не было запросов?

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

В: Почему запросы выливаются на диск?

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

В: Как я могу уменьшить разливы?

Путем написания изящных операторов T-SQL, наличия современной статистики, размещения достаточного количества памяти на сервере, построения правильных индексов и интерпретации планов выполнения, когда все работает не так, как вы ожидали. Посмотрите книгу Гранта Фричи по настройке производительности SQL Server для подробных объяснений.

— Брент Озар
источник