Я бы из этого набора дисков сделал бы raid5. Производительность от этого стала бы намного выше, чем с зеркалом. Журнал транзакций имеет смысл выносить на отдельный диск, но когда стоит выбор: raid5 или разнесение лога и базы по разным дискам, (годами выработанное IMHO) raid5 гораздо привлекательнее.

У нас сервера HP. Проблем нет. Т.е. были, но после просекания ньюансов они перестали быть. NetRAID 2M - выбор неплохой. Главное, убедитесь что там кэш вам поставили в размере ни в коем случае не менее 16Mb. Лучше 32, а еще лучше 64.

Какие проблемы с восстановлением RAID5 ?! Сломавшийся диск вынимаешь, новый вставляешь, говоришь ему rebuild и все! Работа с базой даже не прерывается. То, что в Микрософте не восстановился raid5, предполагаю, что это у них совсем другая реализация (ихняя софтовая). А у тебя будет аппаратная. Не зря же контролер под штуку баксов стоит. Кэш на запись действительно надо отключить, точнее установить WRITE BACK. Но это же рекомендуется сделать и для отдельного устройства под базу, если на контролере нет батарейки. Конечно, на производительность это несколько скажется, но падение производительности будет несравнимо меньше выиграша от использования raid5. Дело в том, что запись все равно кэшируется средствами СУБД (процесс LAZY WRITER). Сама Микрософт и SYBASE рекомендует такую конфигурацию: журнал на отдельном зеркале, база на RAID5, система на отдельном зеркале.
В твоем случае если удасться пробить 5-ый диск, можно сделать очень удачную конфигурацию:
система и журнал на зеркале, база на RAID5 из 3-х дисков. И быстро, и защищено. Но если нет, то лучше все же из 4-х дисков сделать один RAID5.

RAID10 - это безусловно, самое лучшее. Но чрезвычайно и неоправданно дорого. К тому же вышеуказанный райд-конролер не поддерживает RAID10

В любом случае рекомендую настроить WRITE BACK везде. Когда-нибудь наступит момент, что ты не пожалеешь об этом.

RAID5, сделанный на HP контролере протестировать просто: при работе с базой выдергиваешь диск из массива, проверяешь, что все работает, затем вставляешь этот диск и говоришь ему rebuild. Когда ребилд закончится, опять все проверяешь. Ни в какой момент не должно быть сбоев. Особенно проверь, как идет бэкап большой базы в тот момент, когда в массиве не достает одного диска. Это критический момент.

Ой, оговорился. Конец рабочего дня, однако. Извиняйте. Везде, где в моих словах написано 'WRITE BACK', конечно же, надо понимать наоборот 'WRITE THRU'. Уж простите великодушно!

Наибольшая производительность для транзакционной базы будет при размере страйпа 64-128кб, а для аналитической базы 128-256кб. Эти же величины рекомендуют люди из Микрософт неофициально. Официально Микрософт хранит гордое молчание по поводу рекомендаций по размеру страйпа. Не понятно, чем руководствуется производитель контролера, задающий размер страйпа по-умолчанию в 4кб. Кстати, при размере страйпа меньше 8кб (меньше размера страницы) при работе mssql весьма вероятны глюки, падение сервака и разрушение базы (!). О последнем меня лично предупреждал человек из представительства Микрософт.
Идем дальше. Размер UNIT в NTFS. Задается при форматировании раздела. Оказывается, что он тоже имеет влияние на производительность mssql, причем максимум достигается при 32кб. А по-умолчанию предлагается 4кб. Несмотря на зависимость производительности от размера юнита, Микрософт рекомендует оставить размер по-умолчанию в 4кб.
Идем дальше. Если внимательно почитать инструкцию к контролеру, то увидим, что производитель рекомендует делать размер юнита больше или по-крайней мере таким же, как размер страйпа.
И здесь мы видим противоречие рекомендаций Микрософт и производителя контролера. Но что делать? Выбирать-то надо что-то.
Намаявшись экспериментами и с'аккумулировав все вышеперечисленные соображения, я для себя (вам не навязываю!) вывел оптимальную конфигурацию: размер страйпа - 64кб, размер юнита ntfs - 64кб. При этом достигается и максимальная производительность, м не нарушается требование производителя контролера. Нарушается только рекомендация Микрософт о размере юнита в 4кб, причем они это никак не обосновывают.

Имейте в виду один момент. Если размер юнита ntfs больше 4кб, то теряется возможность сжимать файлы средствами ntfs. Для базы это, конечно, безразлично. Это имеет смысл для хранилищ файловых архивов и файловых серверов.

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