Рекомендуемый способ настройки БД SQL 2005

Question

Только что получил серверную версию win 2003 (64-bit) с дисками 6 x 320 ГБ и намерен установить mssql 2005 (64-bit стандарт). Думая о настройке следующего:

• На дисках 1 и 2 работает Raid 1, разделенная на C: \ для ОС (~ 50 ГБ) и D: \ для всех файлов .ldf (~ 250 ГБ)
• На дисках с 3 по 6 работает Raid 0, разбитый на E: \ для файлов .mdf (~ 700 ГБ) и F: \ для запуска резервных копий и т. Д. (~ 200 ГБ)

это было бы оптимальным?

Мне интересно, должен ли tempdb рассматриваться как остальные файлы .mdf и .ldf или быть перенесен в F: \

также погуглил и немного запутался в файловых группах, некоторые рекомендовали перенести индекс в разные файловые группы и использовать разбиение. было бы это полезно, так как аппаратное обеспечение объединяет диск с 3 по 6 в «1 физический диск» и sql не получит выгоду от одновременного чтения?

Answer 1

Зачем вам использовать Raid 0 для ваших файлов данных? Отказ одного диска может повредить ваш массив. RAID 10 - это то, для чего вам нужно: производительность + отказоустойчивость.

Answer 2

Ключевые моменты:

• Ваш SQL Server не может работать быстрее чем записи логов.

• Неудачная транзакция может привести к TempDB, чтобы заполнить диск, на котором он находится и сбой SQL Server.

Идеи:

Храните файлы журналов разделенными на дисках с самым быстрым временем записи.

Храните свою временную базу данных отдельно на дисках с наилучшей общей производительностью (чтение и запись).

Вам придется принять решение о компромиссах, поскольку никто не имеет всех ресурсов, которые они хотели бы.

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

Если вы не можете изолировать базу данных tempDB, ограничьте размер прироста.

Answer 3

Вне RAID-массива ОС оптимальная настройка жесткого диска для SQL Server - это иметь два отдельных массива RAID 5 (или 10, если поддерживается). Один для данных, другой для журналов транзакций.

Логическое обоснование между двумя массивами состоит в том, что в идеале вы не хотите, чтобы обновления оказывались затронутыми из-за ожидания другого.