Настройки tempdb для 1с

Обновлено: 06.01.2025

Системная база данных TEMPDB участвует в работе пользователей, подключённых ко всем пользовательским базам данных сервера СУБД.

TEMPDB используется при работе с временными таблицами и процедурами, в ней создаются внутренние (internal) и пользовательские объекты (user objects) промежуточных результатов запросов и т.п..

При запуске сервера, TEMPDB создаётся заново, если TEMPDB по каким то причинам не может быть создана, то сервер СУБД не запуститься. По умолчанию размер этой базы данных неограничен и увеличение его осуществляется при необходимости автоматически, порциями по 10% от текущего размера TEMPDB, однако эти параметры могут быть переопределены пользователем. По умолчанию, минимальный размер этой базы данных, который устанавливается при старте Microsoft SQL Server, определяется размером системной базы данных MODEL. Очистка журнала транзакций в этой базе данных производится автоматически, при этом удаляются только неактивные записи журнала транзакций.

При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы. Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, ORDER BY, UNION, SORT, DISTINCT и т.п.

Наиболее частой проблемой, с которой сталкиваются пользователи, является значительное увеличение размера базы TEMPDB. Причиной увеличения размера базы данных TEMPDB, как правило, является невозможность автоматической очистки журнала транзакций и повторного использования свободного пространства в TEMPDB из-за наличия активных транзакций, использующих объекты этой базы данных.

Какие могут быть решения данной проблемы:

1. Перезапустить MS SQL Server. В этом случае размер базы данных TEMPDB будет установлен по умолчанию.

2. Сжать базу данных TEMPDB. Для этого нужно в Query Analyzer выполнить следующую команду: DBCC SHRINKDATABASE (TEMPDB).

3. Уменьшить размер отдельных файлов. Для этого нужно в Query Analyzer выполнить команды:

DBCC SHRINKFILE (Логическое_Имя_Файла_Данных, Желаемый_Размер_Файла_Данных_В_Мегабайтах)
go
DBCC SHRINKFILE (Логическое_Имя_Файла_Журнала_Транзакций,
Желаемый_Размер_Файла_Журнала_Транзакций_В_Мегабайтах)
go

Пример.

Уменьшение размера файлов базу TEMPDB до 20 мегабайт

USE TempDB
DBCC SHRINKFILE (tempdev, 20)
go
DBCC SHRINKFILE (templog,20)
go

Пункты 2 и з также можно выполнить с помощью Management Studio

4. Переместить базу данных TEMPDB нас диск большего размера. Изменить месторасположение файлов базы данных TEMPDB можно с помощью команды ALTER DATABASE. Для этого нужно в Query Analyzer выполнить следующую последовательность команд и перезапустить сервер СУБД:

В завершении еще парочка советов по работе с базой TEMPDB:

1. Для оптимизации работы базы данных TEMPDB рекомендуется ее вынесение на отдельный жёсткий диск или RAM-диск и разбиение MDF файла на части (одинакового размера) по числу процессоров (ядер): если процессоров < 8, то количество файлов = количество процессоров; если процессоров > 8, то количество файлов для начала 8, а затем добавлять по мере необходимости.

2. При использовании временных таблиц используется кеширование, но это не относится к операциям создания индексов, сортировки, группировки и т.п. Например: создали таблицу, построили индекс (что разумно с точки зрения построения плана), то данная таблица кешироваться не будет. Но если таблица очень маленькая и почти наверняка она SQL-сервером будет сканироваться и создается она очень часто, то возможно имеет смыл операцию создания индекса опустить, в этом случае за счет кеширования таблица будет создаваться быстрее.

Резервное копирования баз данных MS SQL Server на сетевой диск

При резервном копирования стандартными средствами Enterprise Manager для MS SQL 2000 и SSMS для MS SQL 2005 (2008R2) невозможно создать устройство резервного копирования, расположенное на сетевом диске, поскольку они видят только локальные, физически подключенные диски. Поэтому выполнение резервного копирования возможно только на локальные диски компьютера, на котором установлен Microsoft SQL Server. Использование этого варианта организации резервного копирования существенно снижает надежность, поскольку в случае выхода компьютера из строя становится недоступной как рабочая база данных, так и резервная копия.
Одним из способов решить эту проблему является создание сетевого устройства резервного копирования с помощью системной процедуры SP_ADDUMPDEVICE. Для этого нужно в Query Analyzer выполнить следующую команду:

Использование System Monitor для диагностирования проблем в производительности

Рано или поздно мы все сталкиваемся с проблемой производительности. Поэтому для своевременного обнаружения узких мест в оборудовании необходимо проводить регулярный мониторинг загруженности всех основных аппаратных компонентов системы. К ним в первую очередь относятся:

Все рабочие сервера кластера 1С:Предприятия
Сервер СУБД
Клиентские рабочие станции, работающие под большой нагрузкой

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

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

Компоненты анализируемой системы интерпретируются как объекты, параметры которых представляются в виде набора счетчиков, при этом для каждого объекта определен свой набор счетчиков. Некоторые приложения в процессе установки расширяют системный набор своими, специфическими объектами и счетчиками, характеризующими производительность этого приложения. Например, при установке Microsoft SQL Server к стандартному набору объектов и счётчиков операционной системы добавляются специфические объекты и счётчики сервера баз данных.

Узкие места, которые могут оказать наибольшее влияние на производительность:
Память

Недостаток объема оперативной памяти, установленной на компьютере, оказывает негативное влияние на производительность всех компонент 1С:Предприятия 8 и Microsoft SQL Server.
При увеличении количества пользователей и объема информационной базы требования к этому ресурсу со стороны сервера 1С:Предприятия 8 и Microsoft SQL Server возрастают.
Нехватка памяти приводит к увеличению интенсивности страничного обмена между файлом подкачки и физической памятью, что существенно снижает производительность системы.

Процессоры

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

Дисковые операции

Производительность дисковой подсистемы является одним из решающих факторов, определяющих производительность Microsoft SQL Server.
На производительность сервера 1С:Предприятия 8 влияния, как правило, не оказывает.

Конфликты блокировок Microsoft SQL Server

Один из основных факторов снижения производительности в многопользовательском режиме
Вероятность возникновения конфликтов блокировок можно снизить за счет доработки прикладного решения

Перечень основных объектов и счетчиков, используемых при анализе
проблем с производительностью.

Обсуждаемая в статье проблема актуальна для клиент-серверных баз, размещенных на СУБД MS SQL Server. Она связана с настройками размещения системной базы tempdb, которые получаются при установке SQL-сервера с параметрами «по умолчанию». Подобные проблемы вполне возможны при работе 1С с другими СУБД (у меня не было возможности это проверить).

Описание проблемы:

И так «задача» – положить SQL-сервер с помощью обычной консоли запросов 1С. И решается она достаточно просто и непринужденно. Достаточно выбрать в запросе декартовое произведение какой-нибудь большой таблицы саму на себя (так сказать взять «декартов квадрат») и уложить результат во временную таблицу.

Самый подходящий кандидат для этого – таблица регистра сведений «Адресный классификатор». Но подойдет и любая другая, достаточно большая таблица. Если размер таблицы будет недостаточным, можно вместо «квадрата» выбрать «куб» или более высокую «декартову степень» таблицы.

И так проведем эксперимент:

Для его проведения нужно выполнить следующие «системные» требования:

Стандартно-установленный MS SQL Server (все равно, какой версии, на 2005-том сервере это проявляется);
Сервер 1С:Предприятие (все равно какой, на той же машине или нет – не важно);
Так же для «фокуса» нужно, что бы на системном разделе SQL-сервера было не слишком много свободного места (30-40 гигабайт, но не сотни). Как правило, так часто и бывает. Чем больше свободного места, тем труднее будет получить «результат». Причем труднее не в смысле, что этого трудно добиться, а в смысле, что этого придется дольше ждать;

Убедившись, что указанные выше требования удовлетворены, выполним следующую последовательность действий:

Создадим клиент-серверную информационную базу;
Загрузим туда выгрузку демонстрационной базы какой-нибудь типовой конфигурации (какой – сильно не важно);
Заполним адресный классификатор с диска ИТС, выбрав все регионы (примерно 112000 записей);
И наберем в обработке «Консоль запросов» следующий запрос

ВЫБРАТЬ
ДекартовКвадрат.КодРегионаВКоде КАК КодРегионаВКоде ,
ДекартовКвадрат.Код КАК Код ,
ДекартовКвадрат.ТипАдресногоЭлемента КАК ТипАдресногоЭлемента ,
ДекартовКвадрат.КодРайонаВКоде КАК КодРайонаВКоде ,
ДекартовКвадрат.КодГородаВКоде КАК КодГородаВКоде ,
ДекартовКвадрат.КодНаселенногоПунктаВКоде КАК КодНаселенногоПунктаВКоде ,
ДекартовКвадрат.КодУлицыВКоде КАК КодУлицыВКоде ,
ДекартовКвадрат.Наименование ,
ДекартовКвадрат.Сокращение ,
ДекартовКвадрат.Индекс ,
ДекартовКвадрат.АльтернативныеНазвания ,
ДекартовКвадрат.КодРегионаВКоде1 КАК КодРегионаВКоде1 ,
ДекартовКвадрат.Код1 КАК Код1 ,
ДекартовКвадрат.ТипАдресногоЭлемента1 КАК ТипАдресногоЭлемента1 ,
ДекартовКвадрат.КодРайонаВКоде1 КАК КодРайонаВКоде1 ,
ДекартовКвадрат.КодГородаВКоде1 КАК КодГородаВКоде1 ,
ДекартовКвадрат.КодНаселенногоПунктаВКоде1 КАК КодНаселенногоПунктаВКоде1 ,
ДекартовКвадрат.КодУлицыВКоде1 КАК КодУлицыВКоде1 ,
ДекартовКвадрат.Наименование1 ,
ДекартовКвадрат.Сокращение1 ,
ДекартовКвадрат.Индекс1 ,
ДекартовКвадрат.АльтернативныеНазвания1
ПОМЕСТИТЬ тзДекартовКвадрат
ИЗ
(ВЫБРАТЬ
АдресныйКлассификатор.КодРегионаВКоде КАК КодРегионаВКоде ,
АдресныйКлассификатор.Код КАК Код ,
АдресныйКлассификатор.ТипАдресногоЭлемента КАК ТипАдресногоЭлемента ,
АдресныйКлассификатор.КодРайонаВКоде КАК КодРайонаВКоде ,
АдресныйКлассификатор.КодГородаВКоде КАК КодГородаВКоде ,
АдресныйКлассификатор.КодНаселенногоПунктаВКоде КАК КодНаселенногоПунктаВКоде ,
АдресныйКлассификатор.КодУлицыВКоде КАК КодУлицыВКоде ,
АдресныйКлассификатор.Наименование КАК Наименование ,
АдресныйКлассификатор.Сокращение КАК Сокращение ,
АдресныйКлассификатор.Индекс КАК Индекс ,
АдресныйКлассификатор.АльтернативныеНазвания КАК АльтернативныеНазвания ,
АдресныйКлассификатор1.КодРегионаВКоде КАК КодРегионаВКоде1 ,
АдресныйКлассификатор1.Код КАК Код1 ,
АдресныйКлассификатор1.ТипАдресногоЭлемента КАК ТипАдресногоЭлемента1 ,
АдресныйКлассификатор1.КодРайонаВКоде КАК КодРайонаВКоде1 ,
АдресныйКлассификатор1.КодГородаВКоде КАК КодГородаВКоде1 ,
АдресныйКлассификатор1.КодНаселенногоПунктаВКоде КАК КодНаселенногоПунктаВКоде1 ,
АдресныйКлассификатор1.КодУлицыВКоде КАК КодУлицыВКоде1 ,
АдресныйКлассификатор1.Наименование КАК Наименование1 ,
АдресныйКлассификатор1.Сокращение КАК Сокращение1 ,
АдресныйКлассификатор1.Индекс КАК Индекс1 ,
АдресныйКлассификатор1.АльтернативныеНазвания КАК АльтернативныеНазвания1
ИЗ
РегистрСведений.АдресныйКлассификатор КАК АдресныйКлассификатор ,
РегистрСведений.АдресныйКлассификатор КАК АдресныйКлассификатор1 ) КАК ДекартовКвадрат
ИНДЕКСИРОВАТЬ ПО
КодРегионаВКоде ,
Код ,
ТипАдресногоЭлемента ,
КодРайонаВКоде ,
КодГородаВКоде ,
КодНаселенногоПунктаВКоде ,
КодУлицыВКоде ,
КодРегионаВКоде1 ,
Код1 ,
ТипАдресногоЭлемента1 ,
КодРайонаВКоде1 ,
КодГородаВКоде1 ,
КодНаселенногоПунктаВКоде1 ,
КодУлицыВКоде1

Результаты и "последствия" эксперимента:

После нажатия на кнопку «Выполнить» нам придется запастись терпением. Для файловой базы все закончится довольно быстро и не очень интересно – клиент 1С «подавится» памятью и «лопнет» без глобальных последствий.

Для клиент-серверной базы все будет несколько иначе. Через достаточно большое время операционная система на сервере начнет жаловаться, что «не достаточно места на диске», а возмущенные пользователи (если сервер вдруг окажется рабочим) – начнут звонить и спрашивать: «почему тормозит и вылетает 1С».

Еще более серьезными будут последствия, если сервер является «трехголовым Змеем-Горынычем», в одном лице – SQL сервер, сервер 1С и терминальный сервер. Тогда произойдет «полный коллапс».

В такой ситуации приходится срочно предпринимать чрезвычайные меры: срочно что-то освобождать на системном разделе, а также перезапускать SQL сервер (чтобы усечь базу tempdb) и сервер 1С:Предприятия (на всякий случай).

Причины проблемы:

Причиной описанных выше бед является то, что при установке MS SQL Server «по умолчанию» системная база tempdb целиком размещается на системном разделе и при этом не ограничивается рост ее размера. Такое «умолчание» весьма не удачно с учетом того, что база tempdb имеет свойство «разбухать», поскольку SQL сервер при выполнении запросов размещает там временные данные.

При показанных выше настройках, база tempdb может легко «съесть» все свободное дисковое пространство на системном разделе сервера и поставить тем самым операционную систему р… в неработоспособное состояние.

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

Лично на моем опыте такой «фокус» удавался два-три раза. После чего мы решили что-то с этим сделать. Так какие можно предпринять меры, чтобы избежать описанных выше неприятностей?

Варианты решения проблемы:

Окончательного (раз и навсегда!) решения этой проблемы, конечно, нет. Но есть способы сделать такой сценарий развития событий менее вероятным:

А) Можно расширить системный раздел сервера. Не всегда это можно сделать (тем более «на горячую»). И это не панацея – у меня в ходе эксперимента на тестовом сервере (не самом хилом, но не самом крутом) свободное пространство размером 80 гигабайт съелось где-то за 40 минут. И к тому же сейчас много свободного места, а завтра его может стать не так много.

Б) Можно еще установить SQL сервер не на системный раздел. Но говорят, это не слишком оптимально по производительности. Есть и другой веский довод «против» - не переустанавливать же «боевой сервак»!

В) Можно переместить файлы базы tempdb с помощью команды ALTER DATABASE (способ указан AKV77 в комментарии (5) ):

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

Г) Еще один вариант решения проблемы (пожалуй, самый взвешенный, его можно сделать без перезапуска сервера) - это оптимизация размещения системной базы tempdb без ее физического перемещения с системного раздела на другие диски:

После проведения такой оптимизации размещения базы tempdb мне уже ни разу не удавалось «завалить» сервер описанным образом. В худшем случае возникали не требующие чрезвычайных мер «тормоза», которые решались личным «харакири» через консоль кластеров серверов 1С.

Для начала посмотрим на метрики, какой же прирост производительности может быть получен от использования RAM-диска.

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

При использовании RAM-диска у нас всегда будет возникать одна проблема - что будет, если размер tempDB выйдет за пределы RAM-диска?

Эта проблема решается весьма просто - MSSQL позволяет создавать дополнительные файлы данных и логов, в том числе для tempDB.
Таким образом общие рекомендации сводятся к следующему:

Первый файл данных tempDB - на RAM-диске, фиксированного размера (я ставлю 75%) от размера RAM-диске. Отключен autogrowth.
Первый файл логов tempDB - на RAM-диске, фиксированного размера (я ставлю 25%) от размера RAM-диске. Отключен autogrowth.
Второй файл данных tempDB - на обычном диске, начальный размер 8 Mb. Включен autogrowth.
Второй файл логов tempDB - на обычном диске, начальный размер 8 Mb. Включен autogrowth.

Таким образом, при росте размера tempDB и выходе его "из берегов" RAM-диска он просто расширится на медленные диски.

Чтобы сжать дополнительные файлы БД, если tempDB выросла в их размеры, настраивается простенький план обслуживания на ночь:

P.S. Лишь внедрением RAM TempDB мы смогли ускорить закрытие месяца в ERP в два раза.

Специальные предложения

Эх! А я-то думал, что в статье будет описано, как именно сделать на сервере RAM-диск.
Какой понадёжнее, какой подешевле и т.п. Brawler; VKuser318125097; mpeg1989; sansys; Tavalik; alest; + 6 – Ответить (1) Ниже написал, каким диском пользуюсь.
Вопросы установки и настройки нужно рассмотреть? (5) Да не. Разобраться с установкой там легко.
Просто пишу свой отзыв о статье.
Я рассчитывал на сравнительный анализ ПО для RAM-дисков, а статья оказалась о другом. :) Ответьте, пожалуйста, с помощью какой программы вы делали RAM-диск? (8) а теперь 2 тыщи домашняя версия и чуть больше 3к - коммерческая. Для организации копейки, так-то. (4) Интерес скорее вызывает не столько цена, сколько опыт эксплуатации.
У вас это на рабочей базе/базах?
И нормально работает? Плюсанул за разнесение по файлам для решения проблемы переполнения.
Вроде банальная штука, но почему-то никогда в голову не приходила. Правда и вопрос этот всерьез не рассматривал. (9) Хм. И за счет чего ожидается прирост, если файлики рядом лежат?
Да и выставлять степень параллелизма в единицу - тоже спорный совет. Это радикально замедляет формирование тяжелых отчетов.
ЗЫ. Почитал про разбиение tempdb - это скорее прикрытие возможного узкого места (при большом количестве конфликтов при мультипоточном доступе к файлу), чем кнопка "турбо". Т.е. может и не иметь никакого эффекта. (15) Правильно ли я понял Ваш вопрос - за счёт чего возникает прирост производительности после перемещения tempDB в RAM. Верно? (16) Нет. Вопрос касался разделения tempdb на несколько файлов на одном и том же диске. Вопрос был не к вам.
Но если знаете точный ответ - буду благодарен. И актуальна ли эта рекомендация для RAID 5 и выше. (9) Конечно знаю. Но в данной ситуации рекомендация разбивать неприменима. Нужно ли объяснить, почему? (9) Не правильно давать ссылку на "перепосты", а не на первоисточник.
Плохо, что для 1С-ников истина по SQL на сайте 1С, а не на MSDN (((( MS SQL сам кэширует в памяти все что нужно без всяких RAM-дисков. Без тестов производительности статья ни о чем. Разбивать TempDB на несколько файлов - описано в настройках MS SQL от 1С, вероятно закрытие месяца от этого и ускорилось. (12) Я не являюсь экспертом по SQL, но насколько мне известно есть куча настроек (хеширование, статистика), которые отвечают за скорость работы с данными, ХРАНЯЩИМИСЯ НЕПОСРЕДСТВЕННО в базе (файле MDF). Но эти настройки (ИМХО) не ускоряют работы с файлами TempDB, которые (источник этой информации указать не могу) не планировались в роли оперативного хранилище здоровенных массивов информации, как сейчас их использует платформа 1С.
MS SQL сам кэширует в памяти все что нужно без всяких RAM-дисков.

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

Было такое, как по изначальной статье, даже базы выносили, но потом все равно на ssd перешли.
Тем более в новых скулях есть настройки Buffer Pool Extension.
Как вы после перезагрузки сервера действуете или MSSQL в отложенном запуске?

Да, конечно от статьи ждал большего. Хотелось бы анализа причин, прироста производительности. Ну, простите меня, не ведующего, ну не могу я понять, почему если от SQL сервера откусить несколько десятков гигабайт памяти и сделать на них RAM-диск, то операции на этом сервере станут выполнять ЗАМЕТНО быстрее (и уж тем более в общем случае, а не как у автора - в частном случае закрытия месяца).

Ведь, насколько я знаю, все операции над temdb SQL сервер и так делает над таблицами (условно будем считать всё, что хранится в tembdb таблицами) с установленным внутренним приоритетом хранения в оперативной памяти (если её конечно достаточно)! То есть, временная таблица не будет выгружаться на диск, если для неё достаточно свободного места в оперативной памяти. Понятно, что если будут обрабатываться достаточно большие таблицы - они будут выгружаться на диск (при этом будет дублирование - часть данных наборов страниц будет в оперативном кеше и на диске). Но насколько же это будет в общем случае критично? Чтобы лишать SQL сервер гибко управлять всей своей свободной памятью, ради того, чтобы достаточно большая часть была всегда выделена под RAM диск с temdb - которая, скорее всего, в 90% не будет использована и на половину (а что будет использовано ещё и будет частично повторно кешировано в буфере SQL Server - неэффективно расходуя оперативную память на свои копии данных)! Так как SQL Server и всё-равно будет стараться держать временные таблицы в оставшейся у него оперативной памяти и выгружать их RMA-tempdb (причём выполняя объёмную пересылку данных между блоками памяти самым не производительным способом - через кучу посредников и между изолированными доменами приложений) в одну и в другую сторону только по мере необходимости (нехватки памяти, которая как раз и будет вызвана тем, что её попросту недодали SQL Server'у).

На мой взгляд RAM-диск для базы - это больше экстремальное экспериментирование, чем реальное предложение по ускорению! Вы вот так насоветуете админам - а они на своих серверах с 64Gb оперативной памяти, при базе(ах) объёмом боле 1Tb (с самой большой базой около 100Gb) и temdb, который у них при закрытии месяца пухнет свыше 100Gb возьму и выделять под RAM-tempdb минимум 16Gb (а кто-то и все 32Gb) и тем самым у них просядет обычная работа с данными рабочих баз на 25% (условно) в обычном режиме (а в пике ещё больше), а скорость работы с temdb (в часы макс нагрузки) увеличится ну максимум на 20% (и это в пике) - будет ли это реальной панацеей? Большой вопрос! Очень большой!

Тут в статье нужно было писать про исследования, которые должны были предварять такие вот серьёзные перераспределения ресурсов. Показывать где и как возникают узкие горлышки использования temdb. Обосновывать (с конкретными доводами тестов) когда и почему стоит отнимать буферную память от SQL сервера и отдавать её temdb.

И главное, в чём будет реальный экономический выигрыш - от того, что сервер будет требовать больше очень недешёвой серверной оперативной памяти, нежели - как альтернатива - просто разместить temdb на хорошем (тоже не дешёвом, но это пока с памятью не сравнить) серверном SSD диске - с высоким IOPS (лучше всего модели для PCI-ex, а не SAS/SATA; ну или хотя бы в слот M.2 - но это только на современных матерях) , и низким коэффициентом снижения производительности от числа полной перезаписи. Тут важна скорость - надёжность не так важна - это же не для хранения рабочей базы данных.

Вот тогда от статьи был бы толк.

Ну а если помещать в RAM tempdb - то я был начал только с лога temdb - который только пишется (и перезаписывается) в simple rec. mode, ему не требуется хранить большие объёмы дублирующихся данных. А данные временных таблиц - пусть SQL Server сам размещает в доступной ему буферной памяти, и выгружает на физ диск (лучше SSD), когда памяти уж совсем не хватает (а если это часто -то лучше 100 раз задуматься о том, чтобы её нарастить - ведь если её не хватает, от её перераспределения её больше не станет).

Вообще, прежде чем переходить на RAM - лучше сначала освоить перенос temdb на другой диск - если Ваш tempdb находится в том же RAID массиве что и диски рабочей базы - то задумайтесь сначала об этом, крайне негативном факторе - вынесите tempdb на отдельный RAID массив, да хотя бы просто на отдельный диск (два диска : данные и лог) и Вы сразу почувствуете прирост скорости, особенно в пиковой нагрузке! А уж если вы выберите для temdb PСI-ex SSD диски - то, наверняка, дальнейшее желание переносить их на RAM у Вас уже пропадёт!