cobalt_frogSYcobalt_frog,


Сессия А выдала SELECT * FROM TBL. Затем сессия Б изменила (с фиксацией) данные в TBL еще не прочитанные сессией A. Откуда Oracle достанет данные чтобы гарантировать statement level read consistency? Правильно, из UNDO. А если этот UNDO на этот момент уже переиспользован? Правильно - snapshot too old. Так-что частая фиксация может увеличить риск. Но все это в общих чертах (есть undo retention, и.т.п.).

SY.

Тут имеется ввиду частая фиксация в сессии А или в сессии Б? Я спрашивал именно про случай когда происходит частая фиксации в сессии А, например выборка в курсор селекта и обновление данных самой этой таблицы.

імхо
не так важно кто фиксирует, важно что кто-то затер данные ундо (пойдет на второй круг)
обычно сессии Б, но может и А

.....
stax

SYStax,

Как ни странно (хотя почему странно - типичная ошибка оптимизаторов долгоиграющих транзакций) чаще всего самострел. Сессия выдает select, читает данные в цикле, изменяет их и фиксирует через каждые N строк.

SY.

по разному, от системы зависит, у нас ОЛТП, было чаще Б (чистый долгоиграющий селект)

если сам (А) виноват, бороться проще

меня больше возмущало,
что даже если запись из выборки никто не трогал, меняли другие строки блока и затерли инфу, то всеравно 1555

но такая архитектура

.....
stax

Бракованный финский угорьStaxчто даже если запись из выборки никто не трогал, меняли другие строки блока и затерли инфу, то всеравно 1555
Для OLTP уменьшить размер блока.

счас уже менее актуально

.....
stax