Уважаемые проконсультируйте по RAID и физ. размещению файлов

[Игорь_777]

Здравствуйте, ситуация: имеется дисковый массив из 12 дисков (8 по 146Гб и 4 по 73 Гб).

Требуется разместить файлы БД. Имеется 4 БД - одна продакшн и три остальные для тестов, разработки и обучения.
Требуется обеспечить высокую производительность(по крайней мере что касается ввода-вывода) основной(продакшн), а производительность остальных БД менее важна. Все БД примерно одинакового размера по 33 Гб. Только продакшн БД работает в ARCHIVELOG и имеет flash area, остальные нет. У продакшн БД помимо хранения архивных журналов в flash области должно существовать второе место для архивных журналов.
По событиям ожидания - проблема ввода-вывода, у продакшн лидируют два файла - один файл данных и другой индексный. Режим работы всех БД смешанный - днем может быть много вставок с одновременной генерацией мощных отчетов.

Я предложил сисадмину следующий способ размещения файлов,учитывая, что, для остальных трех БД также требуется обеспечить безотказную работу, следующее:
весь дисковый массив переводим в 1 RAID. У нас остается 4 диска по 146Гб и 2 по 73Гб. На первом (146Гб) диске раполагаем файлы данных, на втором(146Гб) индексы и табличное пространство TEMP, на третьем (73Гб) системные табличные пр-ва и UNDO. Четыре группы ONLINE REDOLOGов(по 3 файла в группе) распределяем по этим трем дискам, а также по ним распределяем STANDBY REDOLOGи. Контролфайлы аналогично.
Для трех оставшихся БД используем один диск по 146Гб и один по 73Гб.
Оставшийся диск по 146Гб отводим по flash область, файлы экспорта, хранение бакапов, различные скрипты для CRON и т.д, так как, дисков больше не остается, к великому сожалению, второе место хранения архивных журналов придется расположить на этом же , оставшемся диске (что мне конечно очень не нравится).
Все БД растут примерно по 10Гб за 6 месяцев.

ПОЖАЛУЙСТА!!! Подскажите, какие минусы в моей схеме распределения файлов БД и как лучше их расположить.
Спасибо

[a_shats]

Главная проблема - странный подбор дисков в массиве (разные винты в одной полке), в итоге - их не хватает ни на одно, ни на другое.
Слишком мало винтов, чтобы так разбрасываться.
Вариант фактически один:
8хRAID10+4хRAID10/
А вот варианта раскладки 2 - либо мы на "большой массив" кладем все БД, на "маленький" - логи, либо - на "большой" кладем боевую базу, на "маленький" - второстепенные. Соответственно массивы отдавать через разные контроллеры, если массив 2-контроллерный и имеет такую возможность.
Плюс первого варианта - все приложения получают всю производительность массива.
Минус первого варианта - второстепенные базы отъедают производительность у боевой.
Плюс второго варианта - устранение минуса первого
Минус второго варианта - при относительно небольшой нагрузке на второстепенные БД у боевой БД отъедается производительность 4 винтов.
Ваш вариант вообще не годится для внешнего массива с таким количеством винтов - контроллер аппаратно разложит нагрузку на винты в любом случае лучше, чем Вы - руками. Основан он на известном подходе 10-летней давности, когда RAID-контроллеры были большими и медленными, и вручную можно было разложить нагрузку удачнее. Почитайте современные вещи по Ораклу

[Игорь_777]

Да, Вы правы, количество дисков ограничено. Возможно в будущем дисков станет больше...
Да, я читал SAME Oracle. Там советуется вообще сделать один 10 рейд и поместить туда все. И сделать 2 рейда по одному диску для расположения онлайн логов. Вщт в принципе такой совет.
Что Вы думаете об этом?

[a_shats]

Тоже вариант - но он по сути эквивалентен варианту 1 плюс - производительность на запись у моего варианта лучше.

[S&L]

8хRAID10+4хRAID10/

....когда RAID-контроллеры были большими и медленными, и вручную можно было разложить нагрузку удачнее. Почитайте современные вещи по Ораклу

так если сейчас все так хорошо с контроллерами,
то зачем же предлагать 10-й рейд, давайте использовать 5-й ?
оракловому SAME (тот же 10-й рейд) тож уже порядка 10-ти лет,
когда RAID-контроллеры были большими и медленными  :roll:

[a_shats]

S&L
Ну зачем утрировать ? У 10-ки лучшая производительность на запись при достаточной отказоустойчивости. Хотя, если отношение чтения к записи в районе 75/25% - можно и 5-ый использовать, почему нет

[S&L]

по крайней мере HDS утверждала еще лет 5 назад, что ее 5-й рейд не уступает на записи рейду 1 (10)

[gs]

Рэйд5 уступает по записи десятке по определению. Возможно они имели в виду, что сам контроллер успевает считать - это другое дело. Но большее количество дисковых операций при записи никуда не денется.

[S&L]

но они то пишут полным страйпом, так что никакого
"большего количество дисковых операций при записи"

[gs]

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

[S&L]

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

ну как - гиговые кэши, отложенная запись, формируй полный страйп и вперед  :roll:

[S&L]

тем более у них в райде тока максимум 4 диска,
так что полный страйп небольшенький

[gs]

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

[S&L]

я подозреваю что все базы пишут в так сказать режиме write ahead log,
так что постоянно база пишет в журнал, а грязные кэш-буфера скидываются довольно редко, когда переключаются логи.
Аналогично, как понимаю, работают журналируемые файловые системы.

[a_shats]

S&L
я подозреваю что все базы пишут в так сказать режиме write ahead log,
Аналогично
так что постоянно база пишет в журнал, а грязные кэш-буфера скидываются довольно редко, когда переключаются логи.
В зависимости от интенсивности, с которой пишет приложение. Чаще всего flush по двум условиям: % заполнения и временному интервалу.