[ОТВЕТИТЬ]
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 Кб, 147 просмотров)
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), т.к. у них разный подход и мы получаем доп.задержку при поиске в кэше контроллера.
12.12.2008 11:48
deucel
 
В продолжение темы







12.12.2008 16:43
orekhov
 
ASM наверное хорош, но, во-первых, функционал требует тщательного изучения, во-вторых, возможности тестирования и наработки изрядного опыта. Ну а в-третьих лично меня, например, несколько смущает тот факт, что ASM-хранилище представляет собой этакий "чёрный ящик". В случае сбоя - абсолютно непонятно, что с ним делать и какова структура данных. Файловая система в этом отношении как-то ближе и привычней :)
12.12.2008 17:35
deucel
 
Цитата:
orekhov ASM-хранилище представляет собой этакий "чёрный ящик".
Я тоже так думал.
Но все относительно.
Например в случае выхода из строя рейд контроллера вероятность запуска на другом (другой модели) минимальна, т.к. обычно создается подобие логического диска, а четкой спецификации не существует и производители делают по своему усмотрению.
В отличии от чистого raw ASM оставляет идентификаторы на дисках и при попытке подключения такого диска к группе он выдает предупреждение о существующем идентификаторе и его имя :p
У ASM есть консоль (позволяет производить простые манипуляции с 'файлами') пример шесть постов назад, также информацию можно получить в оракле.
Функционала особого у него нет, но по сравнению с raw можно увидеть какие диски входят в группу, добавлять, удалять без необходимости переноса - ASM сам освобождает диск перенося с него данные. ASM умеет работать в трех режимах - когда зеркалированием (избыточностью) занимается рейд контроллер или ОС (VLM, ...), и когда он сам контролирует избыточность на отдельных винтах или выделяя пространство на них (типа raid5). С ASM могут работать несколько БД и на различных ОС. ASM это отдельный экземпляр отвечающий за хранение данных - можно назвать даже сетевым хранилищем, рейдом, или некой файловой системой как коммерческая VERITAS File System
это я для понимания что такое ASM :)

ну и чтоб не так страшно было, графический интерфейс ASM в файле
Миниатюры
Нажмите на изображение для увеличения
Название: ASM.jpg
Просмотров: 423
Размер:	74.8 Кб
ID:	411   Нажмите на изображение для увеличения
Название: ASM2.jpg
Просмотров: 381
Размер:	52.2 Кб
ID:	412  
Опции темы


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

 

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