Разносить ли табличные пространства по разным дискам ? : Oracle

В большинстве оракловых форумов дискуссии о том, нужно ли разносить табличные пространства по разным наборам дисков напоминают избитую тему противоборства сторонников Intel и AMD.
Одни утверждают, со ссылкой на Oracle, что физическое разделение тэйблспейсов, в частности, USERS и INDX, сулит значительное увеличение производительности. Другие, со ссылкой на тот же Oracle, твердят о том, что сегодня наилучшее решение - SAME (Stripe And Mirror Everything), т.е. попросту из _всех_ доступных физических дисков нужно делать RAID 0+1 и складывать на него базу - а уж умный современный RAID-контроллер сам во всём разберётся.
Возможно, истина либо где-то посередине, либо и вовсе вдалеке от этих утверждений. Посему интересно мнение тех, кто имел возможность на практике протестировать разные варианты применительно к Супермагу. Например, есть полка из 12 физических дисков. Какая конфигурация будет наиболее предпочтительной ?

ИМХО Наши реалии таковы что настолько умные современные контроллеры стоят настолько нереальных денег, что лучше один раз помучаться и разнести ручками

Я тоже против того, чтобы расчитывать на умный современный контроллер, в свете того, что надо еще для архивов место сделать и REDO выложить отдельно. Поэтому, когда у меня попалась такая полка (+2 диска на самом хосте), делал так, постараюсь вспомнить:
1) Два в зеркало на Flashback area, ну или место для архивлогов
2) Три в страйп для REDO и TEMP
3) Шесть в 5ку для остального кучей
4) Контрольники и сама инсталляция лежали на системном зеркале

по моему я что-то забыл :( Они еще разных размеров были, поэтому я их компоновал по размерам, на Flash ушли большие диски, на REDO - маленькие. По дискам проседов не было.
Да, на системном была reiserfs, на основных дисках - XFS c оптимизацией на большие файлы.

Если не путаешь, то посмотри в сторону ASM (Automatic Storage Management). Это оракловая вещь которая работает с raw дисками и сама распределяет нагрузку (т.е. со временем раскладывает файлы для максимальной производительности при минимальной нагрузке), но в отличии от raw позволяет динамически изменять размеры таб.пространств и т.п. (типа как OCFS - oracle cluster file system).
У меня на текущий момент вся БД на ASM, средняя пиковая загрузка винтов 10-20%.

Не путаю.
SAME - методология, предлагаемая Oracle для оптимального использования физических дисков внутри хранилища данных.
ASM - функционал, позволяющий средствами самого Oracle распределить нагрузку между RAW-устройствами.

у меня была возможность поиграться конкретно с см2000 и разными конфигурациями винтов, правда, еще на восьмом оракле. винтов поменьше было.
разнесение по физически отдельным винтам users и indx давало видимый невооруженным взглядом прирост скорости. естественно, это имеет смысл только если индексы супермага уже перенесены из users в indx.
архивлогов у меня не было, но если они есть - их тоже стоит отселить.
рас уж у тебя винтов богато - возможно, имеет смысл выселить в отдельные табличные таблицы и индексы аналитики и тоже их высадить на отдельные винты. база развалится на четыре примерно равные части

я не агитирую, для себя выбор сделал.

может поможет в поисках
[ ➜ ]

там вроде есть ссылки и на оракловые документации и презентации.

P.S.
к примеру у меня 45 дисков, часть функций берут на себя рейд контроллеры, остальное ASM. Добиться результата как с ASM простым разносом по винтам у меня не получилось. Соответственно у меня не все диски в одной группе.
ASMCMD [+] > ls
INDX/
ORAFLASH/
REDO1/
REDO2/
SYSTEM/
TEMP/
UNDO/
USERS/

Если интересно - в файле загрузка винтов в случайный момент времени.

Вложения

sysstat_k_x.txt (4.1 Кб, 194 просмотров)

На примере своей БД скажу, проверял сам
У меня нет такого богатого набора дисков а всего 8, база примерно 120 гигов, пробовал делать 4 RAID0+1 и разносить табличные пространства, потом сделал raid0+1 под систему + raid10 из оставшихся 6 дисков, положил все табличные пространства включая temp на raid 10 - производительность примерно на 20% выше чем в первом случае... возможно при большом кол-ве дисков и сверхбольшой БД есть смысл раскидывать на разные диски, но применительно к моему случаю все прекрасно вертится и так. единственное что порекомендую для Raid10 так это размер страйпа не меньше 128, оптимально 256, иначе возрастает нагрузка на дисковую подсистему (применительно к БД Супермаг)

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

Согласен.
В конечном итоге выбирать тому кто будет обслуживать БД.
При переходе на raw при большой загруженности винтов (периодически 100%) я получил выигрыш ~30%.
Преимущества raw от файловых систем в том, что пишет и читает только запрошенный объем данных, а файловая система по блокам еще и с буферизацией прочитанных данных, что тратит память которую можно отдать ораклу (это не относится к ocfs2 с включенными параметрами _netdev,datavolume,nointr). Это же относится и к RAID 0+1, 10, 5 ..., только там добавляется еще и размер страйпа. Опять же существует противоречивое мнение по использованию кэшей рейд контроллерами в связке с ораклом (buffer cache), т.к. у них разный подход и мы получаем доп.задержку при поиске в кэше контроллера.