Що таке гаряча пляма в контексті додавання файлів у tempdb?

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

• Tempdb Додати файли потребує перезавантаження

І одна відповідь говорить:

ДОДАТИ - відключення не потрібно. Хоча, як зазначав Шон від Microsoft, SQL вважає за краще використовувати файли, заповнені нижче. Якщо ви збираєтесь з одного файлу даних і додаєте більше, то SQL деякий час буде використовувати нові, але продуктивність не буде гіршою, ніж лише один файл. Однак якщо у вас вже є 2+ і додасте ще одне, то це дозволить отримати точку доступу на новій та знизити продуктивність.

Однак коментар застерігає наступне:

Я б поставив доповнення до частини "Додати": "Додати: Ні, але, швидше за все, ви будете врівноваженими, тому ви будете гарячими плямами, які можуть зробити набагато гірше".

У мене є такі запитання щодо цього коментаря, але мені було доручено задавати ці питання в новому моєму власному питанні (цьому), а не питати коментатора через коментар у відповідях на це запитання.

Конкретно:

1. Що таке гарячі плями? (Я отримав деяку інформацію через Google, але не докладно, що відбувається з гарячою точкою на tempdb після додавання файлів)
2. Що з гарячими плямами робить темпдб набагато гіршими?
3. Які конкретні речі в БД стануть набагато гіршими?

1. Що таке гарячі плями?

   "Гаряча плямистість" в цьому контексті означає, що, хоча tempdb має декілька файлів, усі роботи вводу-виводу виконуються в одному файлі. Якщо tempdb достатньо зайнятий для виправдання додавання файлів, дисбаланс, який призводить до гарячого спостереження (через пропорційне заповнення ), буде нетривалим, тому я думаю, що попередження можуть бути маленькими курчатами. З мого досвіду, все одно.

2. Що з гарячими плямами робить темпдб набагато гіршими?

   Я думаю, що це вважається гіршим у tempdb, оскільки він займає велику частину активності запису в більшості навантажень. Ви, звичайно, можете зазнати подібних проблем у базі даних користувачів, але оскільки ви вже намагаєтеся вирішити проблему в tempdb ...

3. Які конкретні речі в БД стануть набагато гіршими?

   Часи пишіть, переважно. Уявіть, що всі намагаються використовувати той самий банкомат, навіть якщо поруч є 7 інших банкоматів. Тільки стільки можна написати в будь-який момент часу; все інше треба чекати. Якщо більше файлів (і достатньо ядер для планування роботи), введення / виведення можна розподілити більш рівномірно.

   Просто переконайтесь:

   • у вас є парне число файлів
   • всі файли однакового розміру
   • всі файли мають однакові налаштування автоматичного зростання
   • кількість файлів якимось чином визначається кількістю ядер
   • залежно від версії (вони включені за замовчуванням у більш сучасних версіях SQL Server ), ви використовуєте флаги слідів 1117 (вирощувати всі файли даних одразу) та 1118 (не використовуйте змішані розширення розподілу).

1. Що таке гарячі плями?

Аарон правильний, і я не збираюся переробляти те, що він говорив вище, проте справа не тільки в дисковому введенні. Основна частина, з якою у більшості людей виникають проблеми в TempDB, пов’язана із суперечками у певних структурах відстеження.

Оскільки наявність декількох файлів tempdb дозволяє алгоритмам пропорційного заповнення та круглої роботи ефективно проходити, будучи "справедливими" для розподілу, додаючи новий файл без виділень, це скидає трохи. Я не погоджуюся з тим, що це "куряче маленьке" попередження (див. Оновлення продукту нижче), якщо ви починаєте бачити PAGELATCH_*очікування нового нового файлу, а не багато чи будь-яке інше. Це зазвичай відбувається в системах , які мають високу TempDB активність і вже мають більш ніж один файл.

Зверніть увагу, що в SQL Server 2019 є варіанти змінити деякі базові системні таблиці на таблиці в пам'яті, які можуть мати покращення, оскільки об'єкти в пам'яті розподіляються інакше, ніж таблиці, запечатані на диску. Таблиці на основі дисків - це традиційні таблиці, з якими ми всі працювали протягом багатьох років. SQL Server 2014 представив таблиці, оптимізовані для пам’яті . SQL Server 2019 може обробляти деякі метадані розподілу в оптимізованих пам'яті таблицях.

Ще одна зміна була внесена в SQL Server 2019, щоб допомогти з паралельними змінами PFS, що, як правило, полягає в тому, що суперечка в структурі пам'яті при розподілі PAGELATCH_*чекає.

2. Що з гарячими плямами робить темпдб набагато гіршими?

Нічого ІМХО. Так, у TempDB є більше елементів, які можуть спричиняти запис до нього, не використовуючись безпосередньо, тому він може перешкоджати деяким елементам. Однак дуже зайнята база даних щодо швидкості зміни даних так само погана. Це не обмежується лише TempDB.

3. Які конкретні речі в БД стануть набагато гіршими?

Мені дуже подобається аналогія Аарона! У цьому суть того, що відбувається. Що насправді стає гіршим, це розподіл та відстеження місця для об’єктів у базі даних. Якщо ваша база даних в основному статична (низька швидкість зміни) або ваш TempDB насправді не використовується, ви нічого не помітите. Якщо, однак, це досить зайнятий сервер, ви можете запустити або посилити очікування сторінок, що може призвести до блокування конвоїв.

Аарон вже вказував, що в старій версії є прапори слідів, щоб переконатися, що використовуються рівномірні розширення та всі файли у групі файлів зростають разом (Аарон вказує 1117 та 1118, які є НОП у 2016+). Інше, що я хотів би ще раз зазначити, це те, що це стосується не лише TempDB, а будь-якої бази даних, і фізичний макет слід продумати залежно від потреб.

Це стосується не лише проблем з гарячою точкою, але також застосовно до інших частин системи, таких як резервне копіювання / відновлення, управління файлами, фрагментація метаданих файлової системи тощо. У цьому можна допомогти декількома файлами.

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