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, можно же просто на локальный диск, их же после останова инстанса (или восстановления оного, переезда на другую ноду, итп) можно просто удалять, база их просто пересоздаст, состояние важно только для текущий сессий - стена непонимания.

Вячеслав Любомудровdbpatchпропущено...


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

Впрочем.Ну, 3600 я не пробовал, конечно
Но при обычной работе примерно так
И вот как-то всегда оно меньше того, что я заказываю
При больших закачках оно наверняка превысит, конечно FAST_START_MTTR_TARGET, но потом опять съедет к тому минимуму на котором может ненапряжно держаться
По крайней мере, я думаю это логично -- нехрен делать DBWR, почему бы и не поработать

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

проверялось как минимум на 10.2, не думаю, что что-то изменилось с тех пор.

хотя в Oracle есть такая... бяка, как forced direct path read (которая самовключается в 11g при даже при обычных, а не PQ фулсканах), она эту идилию может запросто свести в ноль (небезызвестная проблема _small_table_threshold)

т.е. чтобы сделать просчет SELECT -ом агрегатов минуя buffer cache (читая данные с диска напрямую в PGA) - ясен пончик, тебе нужно сделать полный чекпоинт и записать все грязные блоки их buffer cache, и плевать на MTTR target.

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

AlexFF__|dbpatchпри 3600 DBWR превращается в очень ленивого писателя, может держать грязные блоки целый день, пока явно не сделаешь flush кешу тем или иным образом
Ммм... и даже контрольный точки его не напрягают? Ни инкрементальные ни нормальные?
Если сделать сверхгигантские redo log, то инкрементальные - нет, не напрягают. С чего-бы?
Полные, ясное дело, напрягают.

AlexFF__|Или нет checkpoint's? Значит журналы не переключаются?
Ну тогда понятен твой посыл "все проблемы решают ssd".
Действительно при такой нагрузке, где логи не переключаются весь день, не стоит заморачиваться ... ну в принципе, ничем не стоит заморачиваться, все и так будет ОК =)
Да, именно сверхбольшие redo без переключений. Но см. выше про forced direct path read.

А так - да при таком подходе можно имея очень большой buffer cache и только HDD жить, когда в течении дня вся запись идет секвенально в redo, там любой HDD отлично справляется за счет группировки параллельных коммитов/redo log записей в один sync() вызов.

ну а по ночам делать full checkpoint джобой, чисто для профилактики.

но непредсказуемость времени этого самого full checkpoint (при рандомной записи скорость HDD падает со 100MB/s до 0.9MB/s) я бы не стал - время реакции системы не предсказуемо, тут все-таки стоит хотяб lvmcache/bcache (и подобное) подушку сделать какую, с применением SSD или иных каких write back технологий (мы такое правда не делали, ограничились явным управлением data lifecycle - горячие данные на SSD тейблспейсе, архивные - в отдельных тейблспейсах на HDD, которые еще и R/O помечаются, чтоб RMAN плохо не было)

Вячеслав Любомудровdbpatchпри 3600 DBWR превращается в очень ленивого писателя, может держать грязные блоки целый день, пока явно не сделаешь flush кешу тем или иным образом.
Интересно
Это именно при 3600?
При 3599 сбрасывает как есть возможность?
Ведь не зря же DBWR как минимум раз в 3 сек просыпается, неужели сразу засыпает, если очередь на запись не выросла до такой степени, что на восстановление потребуется почти час?
Попробую побаловаться как-нибудь, спасибо

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

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

но в целом как техника это все успешно взято на вооружение даже без условия реплицируемого SAN - если у тебя сильно рандомная запись в таблицу, то превратить ее в секвенальную можно очень просто - пишем рандом в течение часа, потом заряжаем контрольный SELECT с форсированным direct path read (через хинт PARALLEL к примеру) - и вуаля, DBWR начинает большими кусками последовательно сбрасывать грязные экстенты на диск, вместо мелоблочной хаотичной записи, при этом параллельные писатели не блокируются и сбрасывается не кеш целиком, а только данные табличный сегмент

отличия по времени реакции и объему I/O - десятки раз

AlexFF__|dbpatchЕсли сделать сверхгигантские redo log, то инкрементальные - нет, не напрягают. С чего-бы?
Полные, ясное дело, напрягают.

Ну кроме гигантских логов были бы еще и гигантские зависы БД при сбросе всех этих блоков при cp.
Ээээээ. какое еще cp, ты о чем сейчас?

AlexFF__|Хотя их как раз и не должно быть, инкрементальные точки должны потихоньку перебросить всю грязную очередь.
Так что все равно неясно, как блоки будут держаться целый день.
В RAM, как же еще?

AlexFF__|dbpatchо см. выше про forced direct path read
Тут будут висы не только при прямом чтении, а при всех операциях, требующих сброс блоков сегмента на диск, как пример truncate.
Непонятно, как это будут терпеть )
В общем, мне кажется, что это настолько необычная БД, что ее существованием можно пренебречь )
truncate требует сброса блоков сегмента на диск?
прямо откровение.

откуда трава?

AlexFF__|Так у вас есть такие реальные БД? Такой необычный подход могли бы и описать где-нибудь.
У вас там ручной аналог кешевой БД? Вся работа в памяти, сброс на диски подобен backup?
Ну, по правде говоря да, если приложение вообще хранит оперативные данные в своей in-process nosql базе данных отдельно, а в Oracle запись идет в режиме write-only, чтоб иметь возможость DWH и прочего intraday репортинга. Т.е. требование синхронных коммитов на каждый чих нет, array DML рулят. И часовой простой Oracle при restore ни на что не влияет.

Паттерн совсем не типовой, это факт. Но и задача закатывать миллиард фактов в день - тоже совсем не типовая.

AlexFF__|ЗЫ насчет форсированным direct path read (через хинт PARALLEL к примеру) - есть In-memory parallel execution.

Спасибо за наводку, это как-то прошло мимо меня https://www.rittmanmead.com/blog/2010/01/in-memory-parallel-execution-in-oracle-database-11gr2/

Хотя нововведение сильно сомнительно - там где нужен PQ - там данные гарантированно не могут уместиться в памяти и форсированное только дисковое чтение (особенно в случае exadata offloading) очень даже разумно, чтоб не вымывать из buffer cache горячие данные и справочники.

Но наверное кому-то прикольно получать SELECT SUM( по терабайтной выборке не за 60 секунд, а за 5, вот и запилили фич.

AlexFF__|Нда, прочитал и в который раз подумал, ну зачем я в очередной раз полез в спор со специалистами форума =(
dbpatchЭэээээ. какое еще cp, ты о чем сейчас?
В RAM, как же еще?
truncate требует сброса блоков сегмента на диск?
прямо откровение.
откуда трава?
Всем спасибо, ушел )

Ок, про 1475659.1 я не знал и потестирую на досуге, спасибо.

Практического смысла в этом впрочем мало, ибо intraday никакие drop/truncate и так не происходят, там не только озвученные выше проблемы блокировок, есть проблемы и похлеще (тот-же markhot)