Yo.!чя321Уровень изоляции LAST COMMITED ниже чем в SNAPSHOT.
Читатель не висит на заблокированной строке, а берет из журнала транзакций последнюю закоммиченную версию и идет читать дальше. Т.е весия только одна.
last commited ниже RC блокировочника и совсем ниже RC ораклового.


в некотором приближении согласен.

Yo.!
RC блокировочника может считать данные которые на момент окончания чтения уже были удалены
и в том же наборе выдать те что на момент начала чтения еще не появились,


Давайте будем объективны
Если рассматривать транзакционную консистентность ,
то Oracle RC позволяет себе тоже самое.

Результат то один, неконсистентность на уровне всей транзации.


Yo.!
выдать одну запись несколько раз (если по ходу чтения она редактировалась и перехала),

Не верю !

Yo.!
last commited же ко всем феноменам RC добавляет еще парочку дополнительных титпа lost update.

В oracle RC в транзакции вроде тоже самое.


Изолированность на уровне транзакциями оценивается,
всем комплексом действий внутри транзакции, а не единичным запросом.
Притягивать уровень изоляции к части транзакции как то не красиво,
типа тут играем, тут не играем , тут рыбу заворачивали.

А результат все равно один - RC. Не больше не меньше.

Что касается миграции 98% кода , то это маркетинговый булшит.
ИМХО Серьезное приложение после такой смарт миграции нормально работать не будет.

Yo.!Юнга очевидность
В oracle RC в транзакции вроде тоже самое.
Изолированность на уровне транзакциями оценивается,
всем комплексом действий внутри транзакции, а не единичным запросом.
Притягивать уровень изоляции к части транзакции как то не красиво,
типа тут играем, тут не играем , тут рыбу заворачивали.
вы путаете транзакцию с понятием "statement level consistency". так вот в оракле все совсем по другому,


Я как раз и указал на разницу. И не просто на разницу ,
а на критерий сравнения ( или на точку наблюдения).


Yo.!
он на RC гарантирует "statement level consistency" (есть нюанс с рестартом транзакции и сдвигом времени старта),


Да пускай сколько угодно гарантирует, топик то про миграцию на DB2, там этого понятия нет, ему все равно какой там "statement level consistency" подразумевал программер когда писал код.

DB2 оперирует более общеизвестным понятием уровень изолированности транзакции .

C точки зрения всей транзакции на RC они( Oracle & DB2) ведут себя
приблизительно одинаково.


Yo.!
блокировочник не гарантирует даже попадание дублей. блокировочник реально может выдать на RC одну и туже запись по несколько раз т.к. единственный механизм этого не допустить удерживать блокировки до окончания чтения, а RC их не удерживает. вот тут раcсжевано

Ну опять Вы за свое , попробуйте в Oracle то же самое, в рамках транзакции разными запросами. У вас точно также разъедутся результаты.
Блокировочники соответствуют заявленным уровням изоляции на уровне всей транзакции,
и то что в Oracle существует "statement level consistency" , ему только в плюс, но это не делает его RC гораздо лучше чем у блокировочников если оценивать транзакционно.

andrey_anonymous

Зато делает DB2 непригодным для прямого переноса кода с oracle,


Так я вроде этого не отрицал:

Юнга очевидность
Что касается миграции 98% кода , то это маркетинговый булшит.
ИМХО Серьезное приложение после такой смарт миграции нормально работать не будет.



andrey_anonymous
о чем Вам и пытаются сказать.
select в oracle возвращает внутренне согласованный набор данных независимо от уровня изоляции.
И на этом строится, к примеру, логика любого отчета.
Точка.

Мне лично ни разу не приходилось строить отчеты завязанные на консистентность
одного конкретного запроса.
Вы хотите сказать что предикаты в подзапросах тоже консистентны относительно запроса?

andrey_anonymous
А дальше можно сколько угодно бухтеть про "транзакционную точку зрения"


Предлагаю дальше не бухтеть.