- Что такое горячие точки?
Аарон прав, и я не собираюсь перефразировать то, что он сказал выше, однако это не только дисковый ввод-вывод. Основная часть, с которой у большинства людей возникают проблемы в TempDB, связана с конфликтом в определенных структурах отслеживания.
Поскольку наличие нескольких файлов tempdb позволяет эффективно использовать алгоритмы пропорционального заполнения и циклического перебора для обеспечения "справедливости" при распределении ресурсов, добавление нового файла без выделений отбрасывает это немного. Я не согласен с тем, что это «маленькое куриное» предупреждение (см. Обновления продукта ниже), если вы начинаете видеть PAGELATCH_*ожидания в указанном новом файле, а не многие или какие-либо другие в других файлах. Это обычно происходит в системах , которые имеют высокую TempDB активность и уже имеют более чем один файл.
Обратите внимание, что в SQL Server 2019 есть опции для изменения некоторых базовых системных таблиц на таблицы в памяти, которые могут быть улучшены, поскольку объекты в памяти размещаются не так, как таблицы, запеченные на диске. Таблицы на основе дисков - это традиционные таблицы, с которыми мы все работали на протяжении многих лет. SQL Server 2014 представил оптимизированные для памяти таблицы. SQL Server 2019 может обрабатывать некоторые метаданные выделения в оптимизированных для памяти таблицах.
Еще одно изменение было внесено в SQL Server 2019, чтобы помочь с одновременными изменениями PFS, что, как правило, является причиной конфликтов для структуры в памяти при выделении PAGELATCH_*.
- А как насчет горячих точек в tempdb?
Ничего, ИМХО. Да, в TempDB есть больше элементов, которые могут вызывать запись без непосредственного использования, что может помешать некоторым элементам. Тем не менее, очень загруженная база данных пользователей с точки зрения скорости изменения данных так же плоха. Это не ограничивается только TempDB.
- Какие конкретные вещи в БД будут намного хуже?
Мне очень нравится аналогия Аарона! В этом суть происходящего. Что действительно ухудшается, так это распределение и отслеживание пространства для объектов в базе данных. Если ваша пользовательская база данных в основном статическая (низкая скорость изменения) или ваша база данных TempDB на самом деле не используется, вы ничего не заметите. Однако, если это довольно загруженный сервер, вы можете запустить или усугубить ожидание подкачки страницы, что может привести к блокировке составов.
Аарон уже отметил, что в более старой версии есть флаги трассировки, чтобы убедиться, что используются одинаковые экстенты и что все файлы в файловой группе срастаются (Аарон указывает на 1117 и 1118, которые являются NOP в 2016+). Еще одна вещь, на которую я хотел бы обратить внимание, это то, что это не только для TempDB, но и для любой базы данных, и физическая структура должна быть продумана в зависимости от потребностей.
Это не только для проблем с горячими точками, но и для других частей системы, таких как резервное копирование / восстановление, управление файлами, фрагментация метаданных файловой системы и т. Д., Которым все может помочь наличие нескольких файлов.
Вы можете увидеть конкуренцию в структуре размещения путем поиска waitresourceна странице PFS (которая является страницей 1, а затем каждые 8088 страниц). Если вы видите, что все в одном файле (2: файл: страница), то вы знаете, что это происходит.