Когда использовать sort_in_tempdb при перестроении индексов?

Мы обсуждаем, следует ли использовать параметр SORT_IN_TEMPDB для наших таблиц DW. Насколько я понимаю, при использовании этой опции больше записей, хотя они более последовательны. У нас есть SAN (который иногда был очень медленным), поэтому в нашем случае мы хотим максимально ограничить количество операций записи. Я считаю, что база данных tempdb находится на отдельном LUN (наборе дисков).

У нас достаточно места на диске в нашем файле данных и в нашем файле tempdb. В этом случае, выиграем ли мы от использования SORT_IN_TEMPDB?

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

При перестроении индекса вам понадобится вдвое больше места индекса + 20% для сортировки. Таким образом, в целом, чтобы перестроить каждый индекс в вашей БД, вам нужно всего лишь 120% вашего самого большого индекса в вашей БД. Если вы используете SORT_IN_TEMPDB, вы выигрываете только 20%, вам все еще нужны дополнительные 100% в вашем файле данных. Более того, использование sort в базе данных tempdb резко увеличивает нагрузку ввода-вывода, поскольку вместо однократной записи индекса в файл данных вы теперь записываете его один раз в базу данных tempdb, а затем записываете его в файл данных. Так что это не всегда идеально.

Мы определенно не хотим увеличивать нашу нагрузку ввода-вывода с нашей медленной / возможно неправильно настроенной SAN.

Каков будет лучший способ проверить это? Просто перестроить таблицу с опцией и без и записать время?

Изменить : у нас есть 8 файлов tempdb, каждый 15 ГБ. У нас есть флаги TF 1117/1118 и IFI включен. В настоящее время мы делаем смесь перестройки с опцией sort_in_tempdb и без нее.

Благодарность!

SQL Server 2012 Enterprise

SORT_IN_TEMPDBозначает, что сервер SQL будет использовать tempdbдля выделения временного пространства, а не для выделения пространства в пользовательской базе данных, индекс которой перестраивается. Это означает, что вам потребуется меньше свободного места в пользовательской базе данных во время операции перестроения индекса и больше свободного места в базе данных tempdb.

Это дает вам лучшее преимущество, когда база данных tempdb находится на другом наборе дисков (LUN) из пользовательской базы данных.

Из опции SORT_IN_TEMPDB - BOL :

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

Убедитесь, что вы прочитали требования к дисковому пространству, когда SORT_IN_TEMPDB включен .

медленный / возможно неправильно настроенный SAN

Ты знаешь болевую точку. Почему вы не работаете с администратором SAN, чтобы это исправить? Неправильно настроенная или медленная SAN вызовет всевозможные проблемы, такие как медлительность .

Некоторые важные моменты, на которые следует обратить внимание:

• Используйте MAXDOP = 1 при перестроении индекса онлайн, иначе это приведет к увеличению фрагментации.
• Интеллектуальная перестройка / перестройка ваших индексов на основе уровня фрагментации, а также фрагментов страницы.
• Ознакомьтесь с опытом SQLFool по созданию индекса 60 ГБ
• Убедитесь, что вы правильно настроили базу данных tempdb - TF 1117 (РАСТАЙТЕ ВСЕ ФАЙЛЫ В FILEGROUP РАВНО) и 1118 (ТОЛЬКО ПОЛНЫЙ ЭКСТЕНТ) и имеете больше файлов данных tempdb .

Каков будет лучший способ проверить это?

Да, вы должны проверить это, проанализировав waitstats при перестроении индекса с и без SORT_IN_TEMPDB. Также измеряйте время выполнения, а при работе в PROD убедитесь, что вы делаете это во время периода обслуживания или при меньшей активности сервера. Также проверьте ваши данные для чтения / записи и задержки в журнале .

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