MSSQL2005, Дисковая подсистема.

Посоветуйте как оптимально распределить диски сервера БД
Windows Server 2003 Standart 64-bit/MSSQL 2005 Standart 64-bit.
2 x Intel Xeon 2.8GHz, 32Gb RAM, 8 x HDD SAS 300Gb, Контроллер RAID с поддержкой RAID 0,1,5,10
Объем БД 80Гб, лог 10Гб, tempdb 8Гб + лог 5Гб, приложение интенсивно использует tempdb.
Рассматриваются только варианты RAID с избыточностью.

Например:

Вариант 1
2 x HDD - Raid 1 (mirroring) объем (300Гб) - система
2 x HDD - Raid 1 (mirroring) объем (300Гб) - файлы БД, индексы
2 x HDD - Raid 1 (mirroring) объем (300Гб) - tempdb
2 x HDD - Raid 1 (mirroring) объем (300Гб) - журналы транзакций

Вариант 2
2 x HDD - Raid 1 (mirroring) объем (300Гб) - система
4 x HDD - Raid 10 (mirroring+stripe) объем (600Гб) - файлы БД, индексы и журналы транзакций
2 x HDD - Raid 1 (mirroring) объем (300Гб) - tempdb

Вариант 3
2 x HDD - Raid 1 (mirroring) объем (300Гб) - система
4 x HDD - Raid 10 (mirroring+stripe) объем (600Гб) - файлы БД, индексы
2 x HDD - Raid 1 (mirroring) объем (300Гб) - tempdb и журналы транзакций

или другие варианты?

Если интенсивно использует tempdb, то первый.

Я бы рассмотрел вариант 6 дисков в 1+0

Или R1 под базы и 4 1+0 под логи и tempdb

На самом деле нужно смотреть, какая нагрузка по файлам на чтение-запись и уже потом принимать решение.

Я бы сделал так:

2 x HDD - Raid 0+1 (mirroring) объем (300Гб) - система
Разбить на 2 лог. диска (50 система + 250 лог файлы)

6 x HDD - Raid 5 объем (1500Гб)
Разбить на 2 лог. диска (1200 - файлы БД, индексы и журналы транзакций + 300 - tempdb)

Владимир М.

6 x HDD - Raid 5 объем (1500Гб) Разбить на 2 лог. диска (1200 - файлы БД, индексы и журналы транзакций + 300 - tempdb)

жернал на 5-й рэйд - это смерть :-(

вариант 2 * R10
на один R10 - все данные (база + tempdb)
на второй - логи (база + tempdb), система
R1 по сравнению с R10 тормозит весьма ощутимо, разница будет очень заметна
я бы R1 не рассматривал
а может таки забить частично на надежность и наделать просто страйпов? под tempdb, операционку? а надежность бакапами подпереть?

alexeyvg

Владимир М. 6 x HDD - Raid 5 объем (1500Гб) Разбить на 2 лог. диска (1200 - файлы БД, индексы и журналы транзакций + 300 - tempdb) жернал на 5-й рэйд - это смерть :-(

Подразумевалось (1200 - файлы БД, индексы и журналы транзакций + 300 - tempdb)

Alexey Kozlov

Вариант 1 2 x HDD - Raid 1 (mirroring) объем (300Гб) - система .. Вариант 2 2 x HDD - Raid 1 (mirroring) объем (300Гб) - система .. Вариант 3 2 x HDD - Raid 1 (mirroring) объем (300Гб) - система

Во всех трех вариантах 25% дискового пространства (что не так страшно) и 25% шпинделей (что гораздо хуже) пропадают, как говорится, зря

Alexey Kozlov

приложение интенсивно использует tempdb

насколько интенсивно по отношению к самой БД ?

А если так? какие соображения:
2 x HDD - RAID 1 - система
4 x HDD - RAID 10 - tempdb и журналы транзакций
2 x HDD - RAID 1 - файлы БД, индексы

Если tempdb используется интенсивно, не вижу смысла делать его на RAID 1 (как уже выразились "RAID 1 тормозит весьма ошутимо по сравнению с RAID 1+0"). А вот для системы RAID 1 самое оно. Оставшиеся 2 диска в зеркало под базы и индексы. Но опять же не известна нагрузка ни на базу, ни интенсивность записи в журнал, вообще ничего.

Еще вот такой вариант, мне больше нравится
2 x HDD - RAID 1 - система
2 x HDD - RAID 0 - tempdb и журналы транзакций
4 x HDD - RAID 10 - файлы БД , индексы

Если в данном случае упадет stripe не думаю, что кому-то от этого плохо будет, зато мы имеем скорость и вполне приемлему надежность.
Жду критики :)

VxS_

2 x HDD - RAID 0 - tempdb и журналы транзакций

"Поздравляю, вы только что обрезали собственные яйца" (с)
Курить BOL на тему tail-log backup и чем грозит его потеря. Не говоря уже о том, что характер нагрузки для tempdb и логов совершенно разный.

Как вариант:
Raid 1 - система + журналы транзакций
Raid 10 - база (ну или 2 x Raid 1 - база и индексы, тут смотря какая нагрузка)
Raid 0 - tempdb. Если полосатик сдохнет, воткнуть новый диск и рестартануть сервис, потери только во времени.

Непонятно только, куда топикстартер бэкапы класть собирается - уж не в сеть ли. Ну и маловато инфы по типовой нагрузке на БД, конечно.