Dimitry SibiryakovApexникто не мешает выделить для redo log'ов отдельную группу дисков без всяких
аппаратных кэшей.
Ага, вот всегда так: как логи Оракула, так "выделить отдельную группу дисков". А как база
Firebird, так ужастики о дёргающихся головках одного-единственного диска. Ню-ню...

Не надо сочинять, про один диск для FB - это уже ваши измышлизмы. Или хотите сказать, что для FB можно выделить отдельную группу дисков и там проблема дергаюшихся головок будет решена, как в Оракле?

Basil A. SidorovЯ предлагаю не использовать двойных стандартов в отсутствии личной заинтересованности.
Отложенная запись - не вселенское зло.

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

Basil A. SidorovЕсли система записи Oracle гарантированно надёжна, то почему мы получали битые блоки после холодной перезагрузки сервера СУБД при том, что табличные пространства лежали на хранилище, у которого никаких проблем не было?
Очевидно потому что в погоне за производительностью отключили вот это DB_BLOCK_CHECKSUM и не отключили никому не нужный кэш файловой системы.

Dimitry SibiryakovYo.!помниться мне не удавалось донести до тебя и более простые вещи, чем индексы и
несколько таблиц в транзакции.
Ага. Но ты таки попробуй донести до меня как оракул запихивает индексы, несколько таблиц в
транзакции и ещё и redo лог в один-единственный блок undo лога.

Речь не про то, что Оракл меньше блоков обновит, обновить он может и больше, речь про то, что он по коммиту не обязан все эти блоки на диск писать. Вы же знаете, что такое checkpoint в Оракле? Представьте себе, что на каждый коммит Оракл станет делать chechpoint.

Dimitry SibiryakovAlexander Ryndinот 5к за сокет. SEO и SE лицензируются по сокетам.
Воот. А теперь смотрим что можно купить на сэкономленные пять килобаксов. Я, как ни
считаю, получаю ещё один сокет и десяток SSD сверху. То есть сколько Оракула ни ужимай,
Firebird на его месте получит вдвое лучшее железо.

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

Basil A. SidorovВы постоянно забываете штатную эксплуатацию, когда всё записанное в redo обязано, таки, попасть в data, и, соответственно, сгенерировать undo. И, если пропускной способности носителя/хранилища не хватает, то никакая "размазанность" операций ввода-вывода не позволит избежать тормозов.

P.S. Понятно, что при крахе, с высокой степенью вероятности, СУБД донакатит данные из redo, но в нашем конкретном случае я не мог назвать процедуру восстановления ни мгновенной, ни даже быстрой.
Не так. Изменения в данных генерирует и redo, и undo. Undo в свою очередь - это точно такие же данные, изменения в которых тоже приводят к генерации redo. В конечном счете на диск по коммиту пишется только redo. А все остальное только по checkpoint'у и меньшими порциями, чтобы размазать нагрузку на дисковую подсистему.

Dimitry SibiryakovАга. Запись разных страниц размажется по страйпам и они пойдут на разные шпинделя. Даже
если деньги пропить вместо покупки SSD.

Ну отлично, т.е. для FB надо покупать SSD, чтобы добиться того же результата, что и в Оракле?

Dimitry SibiryakovЭто звучит красиво пока все грязные блоки копятся в SGA. Забава начинается когда они
перестают туда помещаться.

А они туда всегда не помещаются, by design так сказать. Я даже больше скажу, что Оракл начал их сбрасывать на диск, он вовсе не должен ждать пока весь buffer cache заполнится грязными блоками. Сбрасываются грязные блоки регулярно, в идеале через равные промежутки времени и одинаковыми порциями. Это более контролируемый и более предсказуемый процесс, нежели совергенно непредсказуемые пользовательские коммиты.

Dimitry SibiryakovApexНа одном сокете сегодня до 8-ми ядер сидеть может у интеля.
И это автоматически означает, что при том же бюджете Firebird будет иметь в своём
распоряжении 16 ядер против 8 у Оракула.

Кстати, Дмитрий, и первый и второй. А не хотите запилить benchmark Oracle vs FB? Представляете какой это будет PR для бесплатного продукта, если выяснится, что он как минимум не отстает в производительности на аналогичных задачах?

Yo.!да без шансов. у ФБ пара сотен коннектов это уже неизведанная территория

Ну не такая уж и неизведанная. Работает там и пара сотен и больше. Другое дело, что работает это все равно хуже, чем у Оракла, я не понимаю зачем отрицать очевидное и доказывать, что разницы нет, когда она есть?

Yo.!почитайте топик. посмотрите сколько всего вскрыл простенький тест. понятно, что до этого товарища никто не ковырял на таких "страшных" нагрузках. и это уже на паре сотен коннектов. причем поймите, если что-то и исправлено, то в лучшем случае в 3.0. даже mysql этот этап в 90х прошел.
Так там речь про какой-то релиз кандидат идет.