Рекомендуемая настройка диска / раздела для SQL Server


14

Я ищу несколько советов о том, как лучше настроить мои диски / разделы для SQL Server. Вот некоторые из моих основных проблем:

Как должны быть отделены файлы SQL (файлы данных, журналы, временные данные)?

Лучше ли RAID много HDD и разделить пространство или сделать несколько RAID с меньшим количеством дисков для каждого RAID?

Должны ли данные и файлы журналов иметь другой тип RAID?

Должны ли базы данных по умолчанию (master, msdb и т. Д.) Находиться на C: или они должны находиться в том же месте, что и другие файлы данных / журналов?

Ответы:


14

Вот хороший пост в блоге: http://sqlserveradvisor.blogspot.com/2009/03/sql-server-disk-configuration.html

Белая книга по выравниванию дисков: http://msdn.microsoft.com/en-us/library/dd758814.aspx

Короче говоря, ваша ОС должна быть на RAID 1, ваши файлы данных на RAID 10 (предпочтительно) и файлы журналов на RAID 1.

Статья по производительности SQL: http://www.sql-server-performance.com/faq/raid_1_raid_5_p1.aspx

PDF в топ 10 лучших советов по производительности: http://www.stlssug.org/docs/Best_Practices_for_Performance.pdf

Также не забудьте поместить вашу TEMPDB на отдельный диск из соображений производительности. Я уверен, что Пол Рэндал придет сюда и поразит вас почему-то.

MS говорит, почему для tempdb: http://msdn.microsoft.com/en-us/library/ms175527.aspx


@SQLChicken: Если есть предпочтение для типа диска -> SATA против SAS, есть ли рекомендации? SAS над SATA? (независимо от типа RAID и т. д.).
Pure.Krome

1
Диски SAS, если у вас есть деньги, предпочтительнее SATA из-за скорости и надежности.
SQLChicken

11

Это большой вопрос «это зависит».

Я не могу ответить на вопрос о том, как создать для вас вопрос по отдельным RAID-массивам, поскольку я не специалист по хранению данных, но могу помочь вам с остальными.

Первое, что вы должны рассмотреть, это какова нагрузка на различные базы данных - OLTP (чтение / запись) или DSS / DW (в основном чтение). Для рабочих нагрузок чтения / записи вы должны смотреть на RAID 1 или RAID 10 (RAID 1 + 0), поскольку они обеспечивают избыточность и высокую производительность чтения / записи. Для рабочих нагрузок в основном для чтения вы можете использовать RAID 5. Причина, по которой RAID 5 не должен использоваться для рабочих нагрузок чтения / записи, заключается в том, что вы платите штраф за производительность при записи.

Журналы транзакций по своей природе предназначены для чтения / записи (или в основном для записи, в зависимости от того, используете ли вы журнал транзакций для чего-либо - например, для резервного копирования или репликации журналов) и поэтому никогда не должны помещаться в RAID 5.

Это означает, что для некоторых баз данных и рабочих нагрузок у вас могут быть файлы данных на RAID 5 и файлы журналов на RAID 1/10, а для других баз данных у вас может быть все на RAID 1/10. Более того, если у вас есть многораздельная база данных, она может содержать некоторые данные для чтения и некоторые данные для чтения / записи, возможно, даже в одной таблице. Это может быть разделено на отдельные файловые группы, а затем каждая файловая группа помещается на соответствующий уровень RAID.

Разделение реальных баз данных опять-таки зависит от рабочей нагрузки и возможностей базовой подсистемы ввода-вывода - для хранения вещей может потребоваться более высокая степень разделения, например, в отдельных RAID-массивах, чем в SAN.

Tempdb - это особый случай сам по себе, так как он обычно сильно загружен и должен храниться отдельно от других баз данных. Системные базы данных не должны интенсивно использоваться и могут быть размещены где угодно, если есть избыточность.

Вот ссылка на официальный документ, который я помог написать, который должен вам помочь: Физический дизайн хранилища базы данных . Также убедитесь, что ваша подсистема ввода-вывода может справиться с ожидаемой рабочей нагрузкой - см. Этот технический документ: Рекомендации по вводу-выводу перед развертыванием . Наконец, убедитесь, что вы используете правильный размер полосы RAID (обычно 64 КБ или выше в более новых системах), правильный размер блока выделения NTFS (обычно 64 КБ) и что в системах, предшествующих Windows Server 2008, вы правильно установили смещение дискового раздела. , Для получения информации об этом и указаниях на дополнительную информацию о них и о том, почему вы должны настроить их таким образом, см. Этот пост в блоге: правильно ли установлены смещения дисковых разделов, размеры полос RAID и единицы размещения NTFS? ,

Линия Bototm: узнайте свою рабочую нагрузку и свои возможности подсистемы ввода-вывода, а затем реализуйте соответственно.

Я надеюсь, что это полезно для вас.

PS Что касается базы данных tempdb, то здесь очень много червей, связанных с тем, как вы должны ее настроить, и есть все виды противоречивой информации. Я написал исчерпывающий пост в блоге о конфигурации файла данных tempdb в разделе «Заблуждения вокруг TF 1118» .


Отличный пост Пол :)
Pure.Krome

1

Короткий ответ для серверов, которые я настроил, всегда был

Логи на отдельных физических дисках, рейд 1 или 10 (чередование + зеркалирование)

База данных на собственных дисках, в зависимости от производительности, обычно требуется RAID5

Много кеша на рейд контроллере

Желательно снова поместить свою ОС и файл подкачки Windows в отдельный массив, обычно это просто зеркало (Raid 1). Это позволяет разделить все операции записи, чтобы высокая производительность не затягивала все.

В прошлом я сталкивался с тем, что запись в базу данных + запись в журнал + запись в файл подкачки приведет к срыву массива Raid5, а производительность окажется в ручной корзине. Проблема в том, что ваша производительность будет хорошей в тестировании, разработке и т. Д. Но когда вы начнете повышать производительность и использование, эта проблема будет выглядеть «на ровном месте» и стремительно возрастают жалобы пользователей.


1

Здесь есть намного лучшие ребята из MSSQL, чем у меня, но в целом я бы предложил следующее;

ОС и код на C: - это должны быть локальные диски, должна быть пара массивов RAID1 - для этого мы используем 2 x 2,5-дюймовых диска SAS 146GB 10krpm, но вы можете использовать 2 x SATA 7.2 диска. Данные должны быть на довольно быстром (10krpm или лучше) массиве RAID 1/10, 5/50/6/60 любого необходимого размера - мы держим наши на FC SAN LUN, обычно на дисковой группе 'tier 2' / 10krpm , Журналы должны быть на отдельной ОЧЕНЬ БЫСТРОЙ (15krpm) маленькой (10 ГБ или меньше?) Паре массивов RAID 1 - мы держим наши на FC SAN LUN, обычно на очень маленькой дисковой группе 'tier1' / 15krpm или на 'tier0' / ссд групп.

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

Мы храним наш master / tempdb с нашими обычными базами данных, но вы можете разбить его на отдельный массив данных LUN.

Надеюсь это поможет.


Интересный момент о том, что диски журналов невелики. Это поможет с скоростью записи? Является ли хорошей идеей попытаться сделать так, чтобы ваши файлы журнальных файлов были настолько малы, насколько ваши данные могут обрабатывать?
Шон Ховат

Я далеко не эксперт, но мы, кажется, обнаруживаем, что они остаются маленькими - ваш пробег может варьироваться :)
Chopper3
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.