Разместите TempDB на SSD или виртуальном RAM-диске, чтобы повысить производительность временной таблицы.

Ежемесячно у нас есть множество временных расчетов, которые в общей сложности занимают 4 дня. Мы не можем изменить так много сценариев, поэтому я ищу конфигурационное/аппаратное решение.
Фон



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



Если на этом этапе расчета произойдет сбой (падение сервера), мы легко сможем его перезапустить.

Проблема Сервер MSSQL, на котором выполняется этот расчет, имеет только 2 HDD-raid1. Один RAID1 для данных, индексов и базы данных tempdb и один для журнала.

Эти вычисления производят так много операций ввода-вывода, что весь процесс занимает несколько дней.

На сервере установлено 180 ГБ рома, и теоретически все данные и результаты этих вычислений могут поместиться только в 5 ГБ памяти.

Это означает, что мы неправильно используем базу данных/ресурсы.
Возможное решение Я думаю, что нам нужно в первую очередь сократить объем ввода-вывода, а также обрабатывать тот ввод-вывод, который в любом случае необходим, на втором этапе. Кстати, сервер — MSSQL 2014 SE.

• Переместите базу данных tempdb на виртуальный ром-диск (около 40 ГБ). Это значит, что мы переместим основной ввод-вывод в память, верно?
  
• Используйте больше временных таблиц, чтобы сократить время ведения журнала сервера и восстановления, а также используйте новый ром-диск (действительно меньше журналов?)
  
• Поместите логи, индексы и важные таблицы на новый SSD-рейд5.
  
• Все остальные данные поместите на старые HDD-диски.
  

Это хорошее решение или вы также можете предложить стандартное решение d.h tempdb для твердотельных накопителей. Любая помощь будет оценена по достоинству. С наилучшими пожеланиями

Я почти перестал использовать MSSQL около 8 лет назад, поэтому не могу конкретно прокомментировать, но вот мои мысли. 1. мало что исправит, поскольку вы все еще зависите от скорости ввода-вывода диска, а то, что вы предлагаете, по сути, является разделом на том же диске.

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

Поскольку у вас достаточно оперативной памяти, я бы серьезно рассмотрел этот вариант. 2. Звучит контрпродуктивно.

Чем больше у вас таблиц, тем больше транзакций вы получите, что увеличивает накладные расходы.

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

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

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

Это также денормализует ваш проект и может создать дополнительную сложность на уровне приложения. 3. Определенно было бы улучшение.

Однако о каких журналах вы говорите? Я бы не стал размещать журналы ошибок или журналы, не связанные с транзакциями, на SSD.

В идеале, если есть возможность раскачать, закинуть все это дело на SSD-массив RAID 5 или 10. Скорость чтения/записи SSD-массива по сравнению с HDD-массивом RAID 1, вероятно, сама по себе достаточна, чтобы объяснить плохую конструкцию базы данных.