Что такое горячая точка в контексте добавления файлов в tempdb?

12

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

И один ответ гласит:

ДОБАВИТЬ - отключение не требуется. Хотя, как указал Шон из Microsoft, SQL предпочтет использовать файлы с более низким заполнением. Если вы переходите от 1 файла данных и добавляете больше, SQL некоторое время будет использовать новые, но ваша производительность будет не хуже, чем при наличии только одного файла. Однако, если у вас уже есть 2+ и вы добавите еще один, это приведет к появлению новой точки доступа и уменьшит производительность.

Тем не менее, комментарий предупреждает следующее:

Я бы добавил в раздел «Добавить» добавление: «Добавить: Нет, но вы, скорее всего, будете разбалансированы, поэтому вы будете в горячем положении, что может ухудшить ситуацию».

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

В частности:

  1. Что такое горячие точки? (Я получил некоторую информацию через Google, но не подробно, что происходит с горячей точкой на tempdb после добавления файлов)
  2. А как насчет горячих точек в tempdb?
  3. Какие конкретные вещи в БД будут намного хуже?
sql-server tempdb troubleshooting jrdevdba
источник

Ответы:

16

  1. Что такое горячие точки?

    «Горячая точка» в этом контексте означает, что, хотя база данных tempdb имеет несколько файлов, все операции ввода-вывода выполняются в одном файле. Если tempdb достаточно загружен, чтобы оправдать добавление файлов, дисбаланс, который приводит к горячей точке (из-за пропорционального заполнения ), будет недолгим, поэтому я думаю, что предупреждения могут быть немного Chicken Little. По моему опыту, так или иначе.

  2. А как насчет горячих точек в tempdb?

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

  3. Какие конкретные вещи в БД будут намного хуже?

    Пишите раз, в основном. Представьте, что все пытаются использовать один и тот же банкомат, даже если поблизости есть еще 7 банкоматов. Только так много можно написать в любой момент времени; все остальное должно ждать. С большим количеством файлов (и достаточным количеством ядер для планирования работы) ввод / вывод может быть распределен более равномерно.

    Просто убедитесь:

Аарон Бертран
источник
10
  1. Что такое горячие точки?

Аарон прав, и я не собираюсь перефразировать то, что он сказал выше, однако это не только дисковый ввод-вывод. Основная часть, с которой у большинства людей возникают проблемы в TempDB, связана с конфликтом в определенных структурах отслеживания.

Поскольку наличие нескольких файлов tempdb позволяет эффективно использовать алгоритмы пропорционального заполнения и циклического перебора для обеспечения "справедливости" при распределении ресурсов, добавление нового файла без выделений отбрасывает это немного. Я не согласен с тем, что это «маленькое куриное» предупреждение (см. Обновления продукта ниже), если вы начинаете видеть PAGELATCH_*ожидания в указанном новом файле, а не многие или какие-либо другие в других файлах. Это обычно происходит в системах , которые имеют высокую TempDB активность и уже имеют более чем один файл.

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

Еще одно изменение было внесено в SQL Server 2019, чтобы помочь с одновременными изменениями PFS, что, как правило, является причиной конфликтов для структуры в памяти при выделении PAGELATCH_*.

  1. А как насчет горячих точек в tempdb?

Ничего, ИМХО. Да, в TempDB есть больше элементов, которые могут вызывать запись без непосредственного использования, что может помешать некоторым элементам. Тем не менее, очень загруженная база данных пользователей с точки зрения скорости изменения данных так же плоха. Это не ограничивается только TempDB.

  1. Какие конкретные вещи в БД будут намного хуже?

Мне очень нравится аналогия Аарона! В этом суть происходящего. Что действительно ухудшается, так это распределение и отслеживание пространства для объектов в базе данных. Если ваша пользовательская база данных в основном статическая (низкая скорость изменения) или ваша база данных TempDB на самом деле не используется, вы ничего не заметите. Однако, если это довольно загруженный сервер, вы можете запустить или усугубить ожидание подкачки страницы, что может привести к блокировке составов.

Аарон уже отметил, что в более старой версии есть флаги трассировки, чтобы убедиться, что используются одинаковые экстенты и что все файлы в файловой группе срастаются (Аарон указывает на 1117 и 1118, которые являются NOP в 2016+). Еще одна вещь, на которую я хотел бы обратить внимание, это то, что это не только для TempDB, но и для любой базы данных, и физическая структура должна быть продумана в зависимости от потребностей.

Это не только для проблем с горячими точками, но и для других частей системы, таких как резервное копирование / восстановление, управление файлами, фрагментация метаданных файловой системы и т. Д., Которым все может помочь наличие нескольких файлов.

Вы можете увидеть конкуренцию в структуре размещения путем поиска waitresourceна странице PFS (которая является страницей 1, а затем каждые 8088 страниц). Если вы видите, что все в одном файле (2: файл: страница), то вы знаете, что это происходит.

Шон Галларди
источник