pkarklinАлександр, полагаю, Вы в курсе, что такая же "замечательная оптимизация" есть и у MS SQL?!
Ну, учитывая, что мы с Вами и с Merle ещё лет семь назад обсуждали тонкости её реализации в MSSQL - таки наверное в курсе :)

StalkerSчем ближе система к чистой oltp (писателей больше, читателей меньше)
Могу лишь ещё раз подчеркнуть, что у Вас забавное (с моей личной точки зрения) представление об oltp. Для меня oltp - это "очень много более-менее простых писателей и ещё немного больше более-менее простых читателей".

StalkerS(т.е. представьте, что вам необходимо сделать оракл для pure writing environment с нулевым или крайне незначительным числом читателей). Можно-ли оптимизировать теперь архитектуру Оракл (и как) с учетом этого?
В рассматриваемых моментах - скорее нет, чем да. Для того, чтобы отказаться от redo, нужно отказаться от журнализирования, инкрементальных бэкапов и вообще половины всего хорошего, что придумано с 70-го года. Чтобы отказаться от undo, придётся отказаться от восстановления после сбоев. Таким образом, если не говорить о глобальном редизайне и применении для тех же целей каких-либо принципиально иных механизмов - "оптимизировать" не получится. В том-то и прелесть версионности в Oracle, что она практически не потребляет дополнительных ресурсов, разница только в том, что информация в rollback сегментах дольше сохраняет статус актуальной.

SergSuperесли конкретно - банк работал каждым филиалом в своей базе, потом решил что база должна быть общая, сеть теперь позволяет
И изначально не сделал репликации? Ну... в голове надо иметь не опилки, конечно. Хотя это лирика.

SergSuperт.е. если надо перенести клиента, то сначала он проверялся в базе приемнике по ФИО, дате рождения, адресу .... и мне бы не помешал совет об эффективном выполнении
1. Создать в таблице уникальный индекс по набору проверяемых полей
2. insert into client select * from client@otherinstance log errors into err$client reject limit unlimited

SergSuperно сейчас все работает автоматом
Критерии сравнения всё равно надо как-то задавать. В том числе по ним можно автоматом создать индекс - это не медленнее, чем писать руками a1.f = a2.f or a1.f is null and a2.f is null. В целом описанный способ - не быстрейший, но по скорость/простота для этого случая, пожалуй, оптимален.

StalkerSзачем отказаться от журналирования, только от поддержки версий.
"Зачем отказываться от коробки передач, только от её крышки".

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

Какие-то - наверное, получится. Существенные - вряд ли.

StalkerSСкажем зачем у вас журнал разделен на 2 части - undo и redo
Это... м... существенно неверное утверждение. Журнал не поделен на части, журнал - это redo. В журнале сохраняется информация об изменении большинства объектов БД, в том числе - об изменении undo.

StalkerSГде-то читал, что это как раз оптимизиция под версионность
Ни в коей степени. Это "оптимизация под откат транзакций", в том числе под восстановление после сбоев.

sdvsamaraДык в Oracle журналирование и есть поддержка версий. Если в нём отказаться от версионности, это означает отказаться от журналирования
С точностью до наоборот. Отказаться от поддержки версий можно, но это бесплатное приложение к механизму журнализирования, который всё равно нужен для других фундаментальных задач.

sdvsamaraПричём это дело развивается, раньше были rollback сегменты, а сейчас undo tablespace.
И шо, Вы таки хотите сказать, что в базах с undo tablespace нет rollback сегментов?

pkarklinБерем единственный результат MS SQL в этом списке:

и ближайщий превосходящий результат Oracle
Вы, конечно, виртуозно играете доступными материалами, но раз Microsoft сливает в секции дорогих решений, попробуйте таки сравнить на сколь возможно похожем железе. Для этого достаточно взглянуть на Top Ten Price/Performance Results:

МестоСерверАппаратураДата измеренияСтоимость1OracleHP ProLiant ML350 G608/16/10.39 USD 2MSSQLHP ProLiant DL580 G710/15/10.49 USD
Так что продолжайте меряться ;-)