dimitrК слову - как Оракл определяет, откуда брать блок? Есть какая-то внутренняя таблица txn ID, принадлежащих RS?
Чтобы ответить в деталях - надо искать. Полагаю, оптимальным будет спросить на форуме Оракла - там есть несколько человек, которые постоянно копаются на этом уровне.

dimitrИ еще - размер RS фиксирован админом или может динамически расширяться?
Может. Правда, насколько я в курсе, серьезные админы предпочитают работать руками.

Другой момент - начиная с Oracle9, появился некий Automatic Undo Management. Из интересных Вам фич - в этом случае есть возможность зафиксировать время, в течение которого блок не будет повторно использован. Также в этом случае идет полностью динамическое распределение места - в чем, правда, я вижу возможность минусов. В старом варианте я мог выделить транзакции rollback segment и быть уверен, что она отработает до конца; здесь же технически существует возможность проблем в моей супертяжелой транзакции из-за суммарной нагрузки текущих транзакций. Причем написать задание так, чтобы оно "переживало" такую проблему, будет не очень легко.

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

В общем - это безусловно вещь, которую нужно знать. Но заметных проблем она не доставляет.

dimitrС удовольствием бы почитал на эту тему.
На уровне технической реализации - увы, не ко мне. Ключевой момент - именно версионность блоков. Полагаю, прелесть этого понятна - любые, сколь угодно сложные механизмы автоматом учитывают версионность; не надо думать, например, о расщеплении branch-узлов итп. Каждая сессия работает в своем виртуальном пространстве блоков.

tru55
Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment

Вот здесь как раз не rollback, а UNDO
В первую очередь, UNDO появляется только если выставить Automatic Undo Management, чего делать необязательно. Во-вторых же, UNDO Tablespace - это те же самые rollback segment-ы (их можно увидеть в системных вьюхах); просто их менеджментом (создание и прочее) занимается сервер.

tru55SET TRANSACTION USE ROLLBACK SEGMENT
никто не отменял, вне зависимости от UNDO_MANAGEMENT
Вы в этом уверены? ;-)


Вы просто воткнулись в режим совместимости - есть параметр 'undo_suppress_errors', который подавляет вывод ошибок в случае "отмененных" операций. То есть вместо выдачи ошибки, как в примере, сервер просто игнорирует эту команду.

tru55К слову сказать, UNDO_RETENTION ("зафиксировать время") - это рекомендация, а не абсолют
Я не пытался "изнасиловать" этот параметр. Дока, однако, утверждает следующее:

Undo Retention Control

Long-running queries sometimes fail because undo information required for consistent read operations is no longer available. This happens when committed undo blocks are overwritten by active transactions.

Automatic undo management provides a way to explicitly control when undo space can be reused; that is, how long undo information is retained. A database administrator can specify a retention period by using the parameter UNDO_RETENTION. For example, if UNDO_RETENTION is set to 30 minutes, then all committed undo information in the system is retained for at least 30 minutes. This ensures that all queries running for 30 minutes or less, under usual circumstances, do not encounter the OER error, "snapshot too old."

dimitrВо-первых, смею предположить, что это работает не для всех блоков. Тем же сиквенсам версионность крайне вредна, например. Впрочем, хранятся ли их значения в своих собственных блоках или в системной таблице с инкрементом через блокировку, я не в курсе.
Правильнее сказать, тем же сиквенсам версионность пофиг. Сиквенсы генерятся через промежуточный серверный механизм, соответственно, изменение этих блоков идет не в пользовательской транзакции, а в своей собственной. Заодно этот механизм поддерживает "кэш сиквенсов" - крайне полезная для скорости штука.

В то же время я сейчас убедился в версионности блоков секвенсоров на следующем простом примере:


dimitrВо-вторых, интересен сам механизм. При апдейте двух соседних записей разными транзакциями в RS будет две копии блока? Если да, то не слишком ли эта прелесть накладна с точки зрения ресурсов и объема I/O?
Насколько я помню, в RBS хранится undo информация транзакции. К сожалению, эти вопросы не входят в круг моих "повседневных" знаний, поэтому не буду утверждать категорично.

protector
С другой стороны, если проводить просто вставку, а не изменение записей, то Оракул тоже что-то пишет в RBS. Неужели пустые блоки? Что он собирается откатывать?
Откатывать придется "занятое место" в этих блоках - заново пометить его как свободное.