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
А дальше можно сколько угодно бухтеть про "транзакционную точку зрения"


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

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

А в чём проблема в oracle поднять уровень изолированности до Repeatable
Read? Какой смысл в извращении Read Committed + statement consistency?..


В чистом виде ( на уровне транзакции его там нет и в ближайшее время не будет),
по причинам связанным с архитектурой версионности.

Есть select for update который его эмулирует, но тоже только на уровне стейтмента.

andrey_anonymousЮнга очевидность
Мне лично ни разу не приходилось строить отчеты завязанные на консистентность
одного конкретного запроса.
Сталбыть, Вам ни разу не приходилось строить отчеты - по крайней мере, в oracle.
Так и запишем - мсье из теоретиков :)

Про влияние предикатов подзапрсов на консистентность отчета говорить будем ?

А то опять начинается, тут играем тут не играем , тут рыбу заворачивали.

С таким же успехом uncommited read справляется с отчетами в блокировочниках.

andrey_anonymousЮнга очевидностьПро влияние предикатов подзапрсов на консистентность отчета говорить будем ?
Ну давайте попробуем. Какое влияние Вы имеете ввиду?

Коррелированный запрос например, где для каждой выбранной строки
из основного запроса вызывается подзапрос.

Все вызванные подзапросы будут консистентны по состоянию на свое начало
или на начало основного запроса?

andrey_anonymousЮнга очевидностьВсе вызванные подзапросы будут консистентны по состоянию на свое начало или на начало основного запроса?
Основного.

Спорить пока не буду , у меня была другая информация, проверить нужно.

andrey_anonymous
Думаю, путаницу в вопрос могли привнести пользовательские pl/sql функции


Вы правы , pl/sql функции присутствовали.
Приводя пример, я как то не придал значения
влиянию переключения контекста выполнения sql - pl/sql на консистентность.