Организация данных в SQL

[DmVash]

Добрый день.
Имеется сервер IBM с RAID-контролером ServeRAID-6i и 4-мя сказевыми дисками 73 GB на нем.
Планируется установка SQL-сервера - размер базы пока не ясен. Как лучше организовать данные - даст ли эффект разбиение тома RAID10 на тома под данные, логи, систему... - имеет ли это смысл на одном канале и логическом томе RAID...
Или может будут какие либо другие предложения организации...

[a_shats]

Имхо - лучше оставить RAID10, но если есть возможность - побить его на логические устройства. В крайнем случае, если контроллер не позволяет - на тома, средствами ОС. Нет смысла разводить кучу массивов на 4 винтах.

[DmVash]

а имеет смысл выделять отдельный раздел под транзакционные логи ?

[Stranger03]

а имеет смысл выделять отдельный раздел под транзакционные логи ?

Как советует MS, лучше делать три раздела, система (SQL), логи, данные.

[a_shats]

Stranger03
Ых... Хинт: посмотрите на дату этих советов. Вспомните, какие тогда были RAID-контроллеры. Сравните Mylex DAC960xx с 320-2Х  :roll:

[ALEX_SE]

Stranger03
Не раздела, а физических диска если точнее
a_shats
Между прочим, ИМХО, смысл в этом есть.
1. Лог использует последовательную запись, тогда как БД произвольную выборку. Имхо опять же, но разные алгоритмы работы с логом и БД не позволят сделать самой оптимальной настройки контроллера, или не позволят полностью использовать такую настройку (политики кеширования, тип записи, и т.п.)
2. При крахе диска с БД есть возможность сделать минимальные потери применив лог к последнему бакапу (если используется соотв. модель восстановления).

[a_shats]

Нету
1. Уже 64МБайт кэша WB разницу в нагрузках (random 8x8KB data и sequential 2x2 KB log) сьедят леХко. А если не сьедят - вопрос количества шпинделей в массиве: я не говорю, что имея 12-16 винтов и толстую базу обязательно делать единый массив на все
2. При крахе массива в любом случае придется восстанавливать базу - что без данных, что без работающего лога работать она не будет в любом случае

[ALEX_SE]

Ну на счет первого Вы может и правы - зависит опять же от размера базы и интенсивности работы. Можно ведь на эти 4 винта и 50 гиговую базу налепить
А вот на счет второго я про случай когда убит только массив где БД, а где логи он рабочий То есть не в варианте с разбиением средствами контроллера, а чисто отдельные массивы. Тогда можно будет восстановить БД на момент краха.

[a_shats]

1. Верно, но см. в моем посте выше "А если не сьедят..."
2. Практика показывает, что когда убиваются разом два винта - это проблемы, скорее, с чем-то другим - шлейфом, терминацией, контроллером, эл. сетью - и тут лог просто не спасет

[ALEX_SE]

Почему не спасет, если он цел и на другом диске?
Решаем проблемы с шлейфом, терминацией, контроллером, эл. сетью, восстанавливаем БД из последнего бакапа, при восстановлении выбираем лог, и указываем дату и время восстановления

[ALEX_SE]

следует наверное дополнить "а диск в другой корзине"

[DmVash]

коллеги, все понятно с другими каналами и винтами, но как говорится, что имеем...
имеет все таки какой нибудь смысл создание логического раздела под логи - типа уменьшение фрагментации и тд. ?

[a_shats]

При двух корзинах все намного проще: RAID10, половинки каждого из зеркал в разных корзинах. Даже при убиении канала массив работает.
Если убивается любой один винт - проблема решается заменой винта и ребилдом. Два винта - как минимум один из них с 90% вероятностью окажется живой и дело не в них, можно просто Make Online.
Таким образом - стандартные для RAID ситуации лучше решать средствами RAID же - а не софта

[Felixx]

И всё же. Есть RAID10. Сервер под SQL базу. Как рекомендуете разбить раздел логически в процентном соотношении?

[Vadik]

Попробуйте сначала в своем вопросе слово "КАК" заменить на "ЗАЧЕМ". Фрагментация файловой системы вряд ли будет узким местом в Вашем случае. Опять же непонятно, за счет чего она должна уменьшиться при разбиении массива на два тома.
Keep it simple, как говорится