Как конфигурировать RAID под ORACLE ?

[Nikel]

Задача:
База данных Парус 8.5.1 based on ORACLE 8.1.7
Имеем хороший сервер в котором установлен LSI Logic RAID 320-2 (двухканальный) и 10 U320 SCSI HOT SWAP винтов по 36GB.

Вопрос:
Как сконфигурировать RAID по каналам и логическим драйвам для оптимально быстрой и надежной работы?

[gs]

По каналам распределение не особо важно, хотя теоретически лучше половинки зеркал с разных каналов брать. Скорости не прибавит, но мало ли канал целиком отвалится. Хотя редко помогает.

По логическим драйвам я бы предложил так:
1. зеркало под систему,
2. 0+1 под базу,
3. зеркало под логи.

Хотя в принципе логи можно писать и на системный драйв - он же все равно бездельничать будет.

[gs]

А если нет батарейки, то на логовом диске отключить кэш.

[a_shats]

См. рис. 1

Зеркальные винты половинок страйпа расположены на разных каналах. Т.е. при убиении даже одного канала (ну мало ли - у винта просела электроника и нагнула канал) - жить будет. К тому же, на каждом канале по 1 глобальному hot-spare, что дополнительно облегчит задачу.
Расклад по массивам:
1. Бьется на пару томов средствами ОС: один под собственно ОС и второй том - под БД, туда кладутся сегменты: TEMP, INDEX, LOG, RBS, 1 файл CTRL сегмента.
2. Один том, кладется: DATA(все сегменты), ARCHIVE, 1-файл CTRL-сегмента.

Попытаюсь обосновать расклад: на самом деле, все операции с сегментами, вынесенными на первый том - "короткая" запись/чтение и "вразброс". Т.е. они хорошо группируются на один массив, и друг другу не мешают. Мало того, размер кластера на этом томе нужно сделать относительно небольшим - по указанным выше причинам.
Данные на втором массиве - вот их отдельно. Суть: самое большое место в кэше Оракла занимают именно они, и чтение, и запись их происходит "пакетами" (предвыборка блоков на чтение и сброс dirty buffers - запись). Размер кластера на этом томе/массиве равен половине или целому размеру блока БД, указанного при его создании.
gs
Дык... я бы сказал, что если уж совсем проблемно, то - можно отключить кэш первого массива...

[gs]

Разбивать средствами ОС необязательно - можно контроллером порезать на две части.
Принципиально то, что случайная выборка (собственно база) и последовательная (логи всяческие) должны лежать на разных ФИЗИЧЕСКИХ дисках.

По поводу размера блока - вопрос сложный. Теоретически все правильно, но на практике фирмварь контроллера пишут ориентируясь на какое-то одно значение (которое по дефолту в контроллере стоит ). В результате реальное поведение контроллера от теории отличается очень сильно. Майлекс например на большинстве задач шустрее всего с блоком 64к. Даже если короткие блоки гонять.

[a_shats]

Я имел в виду кластер файловой системы ОС...
Естественно, его размер должен быть кратен размеру блока в установках RAID-контроллера... Имхо.

[Nikel]

А вот что нам порекомендовали специалисты по парусу-ораклу:



В общем их рекомендация сделать 10 JBOD-дисков.

[ВТБ!]

А вот что нам порекомендовали специалисты

"Специалистам" на надёжность наплевать - у них базы тестовые.

320-2, вроде бы, 64 с BBU, 128 с TBBU.

[a_shats]

Повбывав бы. "Специалистов".
В такой схеме Оракл вылетит при отказе практически одного любого винта.
Ых... Вот, кстати и еще один миф, что "программное" распараллеливание операций чтения/записи с винтов эффективнее аппаратного: на практике это просто вызывает рост неэффективной (не относящейся к основной задаче, сервером выполняемой) нагрузки на CPU и неэффективное использование возможностей дисковой п/с. О надежности программных решений и говорить не приходится, т.к. не о чем.

[ВТБ!]

Кстати, эту тему лучше бы переместить в подобающий форум...

[Johnson]

320-2, вроде бы, 64 с BBU, 128 с TBBU.

На самом деле вариантов поставки больше:
MegaRAID SCSI 320-2 (518) 2ch, 64MB U320
MegaRAID SCSI 320-2 (518) 2ch, 128MB U320
MegaRAID SCSI 320-2 (518) BBU 2ch, 64MB U320
MegaRAID SCSI 320-2 (518) BBU 2ch, 128MB U320
MegaRAID SCSI 320-2 (518) TBBU 2ch, 128MB U320
Плюс два апгрейда: BBU и 128Mb TBBU.

[gs]

Честно говоря иногда софтовикам хочется сказать, чтобы они своим делом занимались, а не лезли в железо. Они как правило много о себе думают, но о работе компьютерного железа имеют весьма относительное предствавление.
Комментировать таблицу не хочется (придется лекцию читать) - можете делать как они рекомендуют, только потом не надо слезных просьб спасти информацию.