[ОТВЕТИТЬ]
Опции темы
11.12.2008 02:25  
orekhov
В большинстве оракловых форумов дискуссии о том, нужно ли разносить табличные пространства по разным наборам дисков напоминают избитую тему противоборства сторонников Intel и AMD.
Одни утверждают, со ссылкой на Oracle, что физическое разделение тэйблспейсов, в частности, USERS и INDX, сулит значительное увеличение производительности. Другие, со ссылкой на тот же Oracle, твердят о том, что сегодня наилучшее решение - SAME (Stripe And Mirror Everything), т.е. попросту из _всех_ доступных физических дисков нужно делать RAID 0+1 и складывать на него базу - а уж умный современный RAID-контроллер сам во всём разберётся.
Возможно, истина либо где-то посередине, либо и вовсе вдалеке от этих утверждений. Посему интересно мнение тех, кто имел возможность на практике протестировать разные варианты применительно к Супермагу. Например, есть полка из 12 физических дисков. Какая конфигурация будет наиболее предпочтительной ?
 
11.12.2008 08:30  
kadr
Цитата:
Сообщение от orekhov
В большинстве оракловых форумов дискуссии о том, нужно ли разносить табличные пространства по разным наборам дисков напоминают избитую тему противоборства сторонников Intel и AMD.
Одни утверждают, со ссылкой на Oracle, что физическое разделение тэйблспейсов, в частности, USERS и INDX, сулит значительное увеличение производительности. Другие, со ссылкой на тот же Oracle, твердят о том, что сегодня наилучшее решение - SAME (Stripe And Mirror Everything), т.е. попросту из _всех_ доступных физических дисков нужно делать RAID 0+1 и складывать на него базу - а уж умный современный RAID-контроллер сам во всём разберётся.
Возможно, истина либо где-то посередине, либо и вовсе вдалеке от этих утверждений. Посему интересно мнение тех, кто имел возможность на практике протестировать разные варианты применительно к Супермагу. Например, есть полка из 12 физических дисков. Какая конфигурация будет наиболее предпочтительной ?
ИМХО Наши реалии таковы что настолько умные современные контроллеры стоят настолько нереальных денег, что лучше один раз помучаться и разнести ручками
 
11.12.2008 09:13  
OlegON
Я тоже против того, чтобы расчитывать на умный современный контроллер, в свете того, что надо еще для архивов место сделать и REDO выложить отдельно. Поэтому, когда у меня попалась такая полка (+2 диска на самом хосте), делал так, постараюсь вспомнить:
1) Два в зеркало на Flashback area, ну или место для архивлогов
2) Три в страйп для REDO и TEMP
3) Шесть в 5ку для остального кучей
4) Контрольники и сама инсталляция лежали на системном зеркале

по моему я что-то забыл :( Они еще разных размеров были, поэтому я их компоновал по размерам, на Flash ушли большие диски, на REDO - маленькие. По дискам проседов не было.
Да, на системном была reiserfs, на основных дисках - XFS c оптимизацией на большие файлы.
 
11.12.2008 11:02  
deucel
Цитата:
Сообщение от orekhov
Другие, со ссылкой на тот же Oracle, твердят о том, что сегодня наилучшее решение - SAME (Stripe And Mirror Everything)
Если не путаешь, то посмотри в сторону ASM (Automatic Storage Management). Это оракловая вещь которая работает с raw дисками и сама распределяет нагрузку (т.е. со временем раскладывает файлы для максимальной производительности при минимальной нагрузке), но в отличии от raw позволяет динамически изменять размеры таб.пространств и т.п. (типа как OCFS - oracle cluster file system).
У меня на текущий момент вся БД на ASM, средняя пиковая загрузка винтов 10-20%.
 
11.12.2008 12:54  
orekhov
Не путаю.
SAME - методология, предлагаемая Oracle для оптимального использования физических дисков внутри хранилища данных.
ASM - функционал, позволяющий средствами самого Oracle распределить нагрузку между RAW-устройствами.
 
11.12.2008 13:14  
akonev
у меня была возможность поиграться конкретно с см2000 и разными конфигурациями винтов, правда, еще на восьмом оракле. винтов поменьше было.
разнесение по физически отдельным винтам users и indx давало видимый невооруженным взглядом прирост скорости. естественно, это имеет смысл только если индексы супермага уже перенесены из users в indx.
архивлогов у меня не было, но если они есть - их тоже стоит отселить.
рас уж у тебя винтов богато - возможно, имеет смысл выселить в отдельные табличные таблицы и индексы аналитики и тоже их высадить на отдельные винты. база развалится на четыре примерно равные части
 
11.12.2008 14:18  
deucel
Цитата:
Сообщение от orekhov
Не путаю.
SAME - методология, предлагаемая Oracle для оптимального использования физических дисков внутри хранилища данных.
ASM - функционал, позволяющий средствами самого Oracle распределить нагрузку между RAW-устройствами.

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

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


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

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

Если интересно - в файле загрузка винтов в случайный момент времени.
Вложения
Тип файла: txt sysstat_k_x.txt (4.1 Кб, 145 просмотров)
 
12.12.2008 02:55  
isi
На примере своей БД скажу, проверял сам
У меня нет такого богатого набора дисков а всего 8, база примерно 120 гигов, пробовал делать 4 RAID0+1 и разносить табличные пространства, потом сделал raid0+1 под систему + raid10 из оставшихся 6 дисков, положил все табличные пространства включая temp на raid 10 - производительность примерно на 20% выше чем в первом случае... возможно при большом кол-ве дисков и сверхбольшой БД есть смысл раскидывать на разные диски, но применительно к моему случаю все прекрасно вертится и так. единственное что порекомендую для Raid10 так это размер страйпа не меньше 128, оптимально 256, иначе возрастает нагрузка на дисковую подсистему (применительно к БД Супермаг)
 
12.12.2008 08:49  
akonev
получили два противоположных результата экспериментов.
вывод: придется проверять самому на своем железе и своей базе :)
 
12.12.2008 10:04  
deucel
Цитата:
Сообщение от Andrew_Konev
вывод: придется проверять самому на своем железе и своей базе :)
Согласен.
В конечном итоге выбирать тому кто будет обслуживать БД.
При переходе на raw при большой загруженности винтов (периодически 100%) я получил выигрыш ~30%.
Преимущества raw от файловых систем в том, что пишет и читает только запрошенный объем данных, а файловая система по блокам еще и с буферизацией прочитанных данных, что тратит память которую можно отдать ораклу (это не относится к ocfs2 с включенными параметрами _netdev,datavolume,nointr). Это же относится и к RAID 0+1, 10, 5 ..., только там добавляется еще и размер страйпа. Опять же существует противоречивое мнение по использованию кэшей рейд контроллерами в связке с ораклом (buffer cache), т.к. у них разный подход и мы получаем доп.задержку при поиске в кэше контроллера.
 
 


Опции темы



Часовой пояс GMT +3, время: 02:54.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.