wurduПоэтому давно и делается SAME, что обеспечивает максимальное кол-во IOPS и максимальную производительность.

SAME тоже устарел, как и идея использования HDD (в любом виде) для чего либо иного, как log/archlog/backupset

Установка SSD позволяет практически (в реальных применения) неограниченно повышать масштабируемость системы, при этом тебе прощаются очень, даже слишком многие огрехи сайзинга и тюнинга.

Как ни крути, а 120-240 iops для HDD против 44000-80000 iops на SSD дают себя знать - поместить 360 HDD для достижения сопоставимой с 1-м SDD производительности по iops - никакими SAME не достичь в разумных пределах.

Т.е. вполне достаточно поставить пару SSD и ограничиться RAID1 mirroring, вынеся копии логов и контролфайлы на HDD для самоуспокоения.

index_dataВсегда был уверен, что для распределения IO индексы и данные нужно хранить на разных лунах. Сам оракл так рекомендует.

это расхожий миф из каких-то очень древних книжек вида Стив Бобровски Oracle 7 для профессионалов 1994-го года издания.

в те годы и о пользе третьей и выше форм нормализации заливали отрокам, многие неофиты верили гуру. да и сейчас поди верят, не имея возможности напрячь извилины и проверить догматы.

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

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

а учитывая откровенно рандомизированную (ибо в основе - HEAP) природу чтений и записей - единственно разумным является именно один большой тейблспейс на все схемы и объекты (не нужно париться с размерами), который действительно лежит на страйпах и зеркалах из всех имеющихся устройств.

даже страйпы особо не нужны, оракл, как ни странно, довольно неплохо справляется с распределением сегментов по дейтафайлов сам, нагружая все диски более менее равномерно.

а лимиты для приложений (защита от бешеной схемы с намерением съесть все место) отлично решаются квотами


единственное место, где оправданы отдельные тейблспейсы - это разные размеры block size для разных типов данных, и, соотвественно, разные размеры кеш буферов под них.

типовой случай - отделение горячих данных бизнес фактов за сегодян от справочников, и отдельно - уже исторических данных бизнес фактов от первых двух.

но при наличии SSD даже это становится малоактуальным.

wurdudbpatchпропущено...


SAME тоже устарел, как и идея использования HDD (в любом виде) для чего либо иного, как log/archlog/backupset

Установка SSD позволяет практически (в реальных применения) неограниченно повышать масштабируемость системы, при этом тебе прощаются очень, даже слишком многие огрехи сайзинга и тюнинга.

Как ни крути, а 120-240 iops для HDD против 44000-80000 iops на SSD дают себя знать - поместить 360 HDD для достижения сопоставимой с 1-м SDD производительности по iops - никакими SAME не достичь в разумных пределах.

Т.е. вполне достаточно поставить пару SSD и ограничиться RAID1 mirroring, вынеся копии логов и контролфайлы на HDD для самоуспокоения.SSD тут принципиально ничего не меняет, т.к. например база на 20ТБ и естественно как-то странно пытаться воткнуть в тот же сервер SSD на 40TB чтобы получить единую точку отказа, поэтому нужен storage к которому как-то надо подключаться по нескольким путям, а там уже задержки появляются. Ну и возникает тот же вопрос, как storage нарезать, а не разнести ли нам индексы и таблицы по разным SSD.
И естественно HDD используются и будут использоваться еще долго. Достаточно взглянуть на последние модели Exadata, ODI и т.д.
Масштабируемость SSD наверное как-то могут повышать в ограниченных случаях, но по мне так это редкость. Плохая масштабируемость связана обычно с кривым дизайном-запросами, а какая там скорость одноблочного чтения и сколько IOPS уже не принципиально. Все обычно упирается в кол-во логических чтений, в сколько из них физических и насколько они быстрые уже не принципиально.

SSD на 40TB не бывает, это раз. про масштабируемость на HDD - твои попытки выдать окроваения ничего, кроме зубной боли не вызывают. терабайтные объемы и мастштабирование HDD звучат актуально ну наверное для 2013 года, в 2017 такое слышать совсем не смешно.

про экзадату, с ее flashcache - как-то совсем уже мимо кассы, я надеюсь ты не стал даже думать, что там все на hdd построено?

два - когда говорят про пиписькомерку в 40TB, обычно забывают упомянуть, что из этих 40 терабайт реально горячих данных - от силы 50 гектар, остальное - это просто исторический хлам, который лишь иногда жует какой хадуп или его подобие.

и три - ну если вам сильно, сильно надо, кто мегает натолкать на 40терабайт этих самых SSD?

если там реальные бизнес-факты, то у вас бизнес как минимум на 100-200m$ ебитды в год, подобная установка вполне себе по карману.

wurduТем более сейчас, когда пара терабайт на Buffer Cache уже обычное дело.

Да, подобное вполне доступно на commodity железе, вкупе с inmemory compression, но в реальной практике это не принципиально, если вы конечно не какой процессинг пластика из небезызвестного банка, который умудрился все в один сервер как единую точку отказа затолкать (хотя бизнесу в том нет никакой нужды).

найти же бизнес, которому нужно иметь в near-realtime такие объемы oltp данных - это еще поискать, и там наверняка будет стоять вовсе не Oracle EE RDBMS как inmemory database

Relic Hunterdbpatch,

на SSD индексы - не нужны. только место отъедают.

о да! индексы это конечно не близкое к рандомному чтение, это строго секвенальное выкачивание многих сотен гигабайт в секунду.

напиши еще откровений.

Вячеслав Любомудровdbpatchединственно разумным является именно один большой тейблспейс на все схемы и объектыНе, ну это уже совсем за гранью

безусловно, в стандартные шаблоны штатного "нарезателя" ресурсов такое никак не вкладывается.

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

реально ни в какие ворота такое не лезет, ипотеку то как оплачивать?

AlexlsРасположение всех объектов на одном диске да еще и SSD - это просто замечательно.
А вот как быть в случае с массированной записью ( 50 -200 млн/сутки).
Как себя поведет SSD в данном случае.
Да если еще при этом и клиенты с этими данными работают.

50-200 млн. сутки чего? TCP трафик в базу данных кладете?

и еще раз - никто нигде не говорил иметь один SSD диск на всё (там конечный ресурс по терабайтам записи)

говорилось несколько обратное - положить все, что не redolog/archlog/backupset на SSD диск(и), т.е. таблицы и индексы, и не заниматься ерундой с нарезкой и "тонкой" балансировкой этого всего.

в остальном - если диск способен на 40000 iops, то в сутки он сможет 3,456,000,000 iops, это несколько больше, чем 200m, верно?

кроме того, большой fast_start_mttr и buffer cache позволит отложить запись в дейтафайлы, по сути вся sync-ронизируемая запись будет только в redo/ctl файлы, в дейтафайлы будет информация будет сбрасываться пакетировано (индексный блок обновится десятки раз в кеше, прежде чем упасть на диск, и т.п.).

этож азы, зачем это объяснять?

Вячеслав Любомудровdbpatchкроме того, большой fast_start_mttr и buffer cache позволит отложить запись в дейтафайлыЭто, точно
Он прямо слушается твоего "большого fast_start_mttr"_target(?)

И? Сделать эксперимент и проверить поведение при 3600 самому тебе не позволяет чувство очень глубокого самоуважения?

Впрочем.

Вячеслав ЛюбомудровДа, вроде, наоборот
Все, (кроме меня ), высказались за одну большую помойку
Это, может, и неплохо, когда у тебя есть куча места в твоем безраздельном пользовании, но когда собираешь по кускам, с одного массива, с другого...

и в чем трудность собирать по кускам? собирать можно откуда угодно, нигде не озвучивалось требование иметь один большой datafile
речь была именно про один большой tablespace, в котором лежат таблицы и индексы со всех юзерских схем, а где там евойные datafile лежат - дело десятое.

wurduindex_dataВсем спасибо. Поскольку никто не высказал явных аргументов против, то создаю свою БД по принципу данные отдельно, индексы отдельно.Ну если более низкая производительность такого решения не аргумент (просто потому что не получится добиться такой же степени утилизации), то можно и так. Только не понятно, почему только индексы. Можно UNDO, TEMP разбросать по шпинделям, еще чего-нить придумать можно

:)

TEMP отдельная тема. даже очень, очень многоуважаемые сервис провайдеры (ну очень уважаемые, дальше уважать просто некуда) умудряются раскладывать TEMP на LUNы, которые еще и синхронно реплицируюся в соседний датацентр.

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