коли для даних не залишилося фізичної пам'яті, SQL Server переміщує вже наявні дані в TEMPDB
Стаття, з якою ви пов’язані, в кращому випадку вводить в оману, а в деяких місцях неправильна. Я думаю, що автор намагався надто спростити деякі складні речі, і при цьому пішов трохи надто далеко.
Таким чином, SQL Server не переміщує дані з пам'яті (буферний пул) у tempdb. У ній використовується стратегія кешування "найменше використаної" (загалом), тому якщо є тиск в пам'яті, і нові дані потрібно витягнути в пам'ять, SQL Server виведе дані LRU з буферного пулу для розміщення нових даних. Ця поведінка часто контролюється лічильником парфмонів під назвою "Тривалість життя сторінки" (PLE) :
Визначення PLE - це очікуваний час у секундах, коли сторінка файлу даних, прочитана в буферному пулі (кеш пам'яті сторінок файлів даних), залишиться в пам'яті, перш ніж виштовхуватися з пам'яті, щоб звільнити місце для інших даних сторінка файлу. Ще один спосіб думати про PLE - це миттєва міра тиску на буферний пул, щоб звільнити місце для читання сторінок з диска. В обох цих визначеннях більша кількість кращих.
Під час виконання запитів SQL Server може використовувати tempdb для певних операцій. Зазвичай це робиться, якщо оцінки погані, але низька доступна пам'ять може вплинути на таку поведінку.
Деякі з операцій, які можуть "розпливатися" до tempdb таким чином, - це хешування рядків (для об'єднань чи агрегатів тощо), сортування рядків у пам'яті та буферизація рядків під час паралельного виконання запитів.
Запити користувачів також можуть явно використовувати tempdb (із загальними або локальними тимчасовими таблицями), а також неявно використовувати tempdb (із знімком або зчитуванням рівнів ізоляції знімків, що виконуються).
Жодна з цих ситуацій насправді не відповідає заяві, яку ви цитували.
коли у вас не вистачає фізичної пам'яті, операційна система може використовувати СТАРТІЙНИЙ ФАЙЛ і переміщувати дані з фізичної пам'яті до нього
Це однозначно може статися, і здебільшого вона знаходиться поза контролем SQL Server. Існує ручка, яку можна повернути, щоб спробувати запобігти деяким типам підкачки на рівні ОС, а саме ввімкнути "Заблокувати сторінки в пам'яті" (LPIM) :
Ця політика Windows визначає, які облікові записи можуть використовувати процес для збереження даних у фізичній пам'яті, не даючи системі передати дані на віртуальну пам'ять на диску.
То що ж ми можемо не допустити, щоб перейти на сторінку на диску?
До початку SQL Server 2012 сторінки, які були виділені через компонент під назвою "Розподіл єдиної сторінки", були заблоковані в пам'яті (не можна було підключити до сторінки). Сюди входили пул буфера (сторінки бази даних), кеш процедур та деякі інші області пам'яті.
Докладні відомості див. У розділі Весело із заблокованими сторінками, AWE, диспетчером завдань та робочим набором ... , особливо розділ "4. Тепер я знаю, що SQL Server на x64 може використовувати" Заблоковані сторінки ", що саме заблоковано?" Тут можна ознайомитись із додатковими читаннями: Великі дебати на SQL сервері: Сторінки блокування в пам'яті
У SQL Server 2012 та пізніших версіях не існує "Розподільника однієї сторінки" (однорозподільник та багатосторінковий розподільник об'єднали відповідно до Поглибленого погляду на пам'ять - SQL Server 2012/2014 ). Деталі того, що саме можна, а що неможливо прописати на сторінці, детально не задокументовано ніде, що я бачив. Ви можете використовувати запит , як це , щоб побачити , що буде закритий
select osn.node_id, osn.memory_node_id, osn.node_state_desc, omn.locked_page_allocations_kb
from sys.dm_os_memory_nodes omn
inner join sys.dm_os_nodes osn on (omn.memory_node_id = osn.memory_node_id)
where osn.node_state_desc <> 'ONLINE DAC'
Згідно з тією ж статтею про підтримку MS, ви також можете використовувати, DBCC MEMORYSTATUSщоб побачити, скільки пам'яті "заблоковано".
Як бічну примітку, ви можете бачити докази того, що робочий набір SQL Server підписується системою в журнал помилок. Будуть повідомлення, які виглядають приблизно так:
2019-09-02 10: 19: 27.29 spid11s Значна частина оперативної пам’яті серверного процесу вимкнена. Це може призвести до зниження продуктивності. Тривалість: 329 секунд. Робочий набір (КБ): 68780, прихильний (КБ): 244052, використання пам'яті: 28%.