Вячеслав Любомудров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)