Я разрабатываю новый сервер базы данных для среды Microsoft SQL Server. Раньше я создавал четыре отдельных RAID-массива для ОС, данных, журналов транзакций и tempdb. Теперь я рассматриваю возможность добавления нескольких твердотельных накопителей, чтобы еще больше повысить производительность. У меня есть бюджет только на два SSD, и я хочу отразить их на случай, если один выйдет из строя. Итак, я могу использовать SSD только для замены одного из четырех стандартных массивов.
Какой вариант даст наибольшее улучшение производительности?
Пол Рэндал провел серию тестов SSD:
По его заключению, сладкое место для SSD - это интенсивные случайные нагрузки ввода-вывода, что делает их кандидатом на Data или Tempdb. Какой из них лучше, зависит от ваших ожидаемых характеристик нагрузки. Я бы посмотрел в sys.dm_io_virtual_file_stats и sys.dm_db_index_usage_stats на существующем сервере, который обрабатывает ту же нагрузку (или тот же тип нагрузки), и посмотрите, где накапливается нагрузка ввода-вывода для MDF / NDF, и поместите эти файлы на твердотельные накопители.
Журналы не имеют особого смысла на SSD, типичный массив SCSI превосходит их при последовательной записи. Как и ОС, хост SQL Server никогда не должен касаться файлов ОС или файла подкачки.
Тот, где будет выполняться произвольный доступ для чтения и записи, и обычно на хосте базы данных, который является разделом данных (и данными tempdb). Раздел журнала, в свою очередь, обычно доступен только последовательно, поскольку большинство журналов являются кольцевыми буферами.
Разделы ОС, поддерживаемые SSD, обеспечивают наибольшую выгоду, если вы планируете довольно часто перезагружать сервер.
Сложно - смотря что делать.
Что-то среднее или не слишком сильное с обеих сторон - SSD, вероятно, потрачены впустую.
Если у вас есть текущая система с уже разбитыми на разделы data / log / tempdb, я бы посмотрел на вашу статистику ввода-вывода для каждого раздела и основал свое решение на этом.
В основном я видел людей, использующих SSD для своих TEMPDB. 2005 г. и далее повлекли за собой большую зависимость от TEMPDB, чем предыдущие версии. И в зависимости от того, что вы используете на своем SQL Server, это может быть самая используемая база данных (если смотреть на вас, SharePoint).
Но сначала я бы начал с того, что посмотрел на вашу среду и увидел, что там происходит.
HTH, Дэн
Это также зависит от типа RAID, установленного на ваших SSD-дисках. Если это RAID 10, то файлы журналов и базу данных tempdb лучше хранить на SSD, поскольку журналы и tempdb в основном используются для операций записи, а RAID 10 обеспечивает наилучшую производительность записи. Иногда после контрольной точки вы увидите активность чтения в файлах журнала. Если наоборот, это RAID 5, чем файлы данных лучше хранить на SSD, поскольку RAID 5 больше оптимизирован для операций чтения. Если у вас достаточно памяти на SSD, вы также можете установить ОС на SSD. Но на самом деле важно изолировать данные из файлов журналов и, если возможно, также и от Tempdb.
Кроме того, Пол Рэндал провел очень хороший анализ. этот блог. Я был очень впечатлен тем, как он подробно рассказал о своем анализе, представив множество возможных случаев.
Вы можете возразить, что вам поможет наличие файла подкачки Windows на отдельном зеркале SSD. При этом лучший способ повысить производительность подкачки - это не использовать подкачку. Кроме этого, не так много случайных операций ввода-вывода с загрузочным / системным томом.