Yo!! ggv
Дык как раз решает, но вы как раз и не поняли.

По другому - создаем сегмент отката (snapshot данных), работаем с ним, а потом сливаем изминения в основные данные. Только здесь уже можно не только "кто первый встал того и тапки", а более гибко.
Полная эмуляция поведения версионника - на блокировочниках, где такое реализовано, само собой. Будет и OLTP - короткие задачи - будут и длинные транзакции в то же время.
Разруха она в головах.
Ну теперь точно до понедельника, на транспорт опаздываю.

да, похоже не понял. итак у нас 2 транзакции одновременно, первая читает майнтабле и пихает в темп, вторая ничерта не ждет и делает тоже самое читая те же данные, первая делает merge в майнтабле, вторая делает тоже самое, затирая все изменения первой транзакции.
в чем фишка ?

Да в том то и фишка, что получается поведение версионника. Только не обязательно перезатирает последующая транзакция изменения предыдущей - если посмотреть на синтаксис MERGE sql statement ---

>>-MERGE INTO--+-table-name-------+----------------------------->
+-view-name--------+
'-(--fullselect-- )-'

>--+------------------------+--USING--table-reference----------->
'-| correlation-clause | -'

>--ON--search-condition----------------------------------------->

.--------------------------------------------------------------------.
V |
>----WHEN--| matching-condition |--THEN--+-| modification-operation |-+-+-->
'-signal-statement-----------'

.-ELSE IGNORE-.
>--+-------------+---------------------------------------------><

То есть краткий вывод - с помощью SQL STATEMET MERGE можно сделать в блокировочнике поведение транзакций аналогичное версионнику, если нужно.
Другой вопрос, что я в своей практической деятельности такой необходимости пока не встречал (я не говорю, что MERGE не использовал)

Yo!!2ggv

что значит необязательно ? обязательно, отвлекитесь от вашего merge это просто синтетический прибамбас (к стате и в оракле он давно).
еще раз у вас 2 транзакции:
t1. транзакция1 insert into temptable select * from maintable ;
t2. транзакция2 insert into temptable select * from maintable ;
t3. транзакция1 merge
t4. транзакция2 merge

и получаете обязательный lost update, ничего похожего на версионный механизм тут нет.

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

Yo - да нет, не надо мне пояснять, что такое версионник.
Я просто смею утверждать, что описанными мной способом мы можем получить поведение версионника на блокировочнике, конкретно db2.
И схема очень простая и понятная.
Да, верно, в версионнике не надо временных таблиц в таком случае, в блокировочнике надо.
И вся разница.
И читатели также получат консистентный отчут (хотя, не всегда такое надо, но надо в ситуации repeatable read, хотя как я уже говорил, в бизнесе я таких потребностей не видел)
Далее, мне нисколько не интересно про select for update в оракле, и я про это не спрашивал.
Повторю - я просто показал, как в блокировочнике сделать поведение версионника - то есть создать snapshot данных, и объеденить его с основными данными.
И это работает, хоть вам это и непонятно.

ну после commit в t5 получить отчет - я не понял вопрос.
Лучше скажите, что произойдет на шаге t6 в версионнике?

Yo!!>ну после commit в t5 получить отчет - я не понял вопрос.

t1. транзакция1 insert into temptable select * from maintable ;
t2. транзакция2 insert into temptable select * from maintable ;
t3. транзакция1 merge
t4. транзакция2 merge
t5. транзакция1 commit
t5.1 транзакция3 длинный select * from maintable
t6. транзакция2 commit

вот тут шансов что транзакция3 "застанет" данные от транзакции1 почти нет.

100% в описаной ситуации транзакция3 получит все закомиченные данные транзакции1


>Лучше скажите, что произойдет на шаге t6 в версионнике?
в oracle это будет выглядеть вот так:
t1. транзакция1 update maintable
t2. транзакция2 update maintable
^^^^^^
ORA-00054: resource busy
t3. транзакция1 commit;
и все !


но если вас интеоресует именно такой вариант как вы делаете в дб2 то выглядел бы он так:

t1. транзакция1 insert into temptable select * from maintable for update nowait ;
t2. транзакция2 insert into temptable select * from maintable fro update nowait;
^^^^^^^^
ORA-00054: resource busy and acquire with NOWAIT specified
t3. транзакция1 merge
t4. транзакция1 commit

То есть вы хотите сказать, что после того, как транзакци1 один сделала COMMIT, а затем делает транзакция2 COMMIT , то транзакция2 получит отлуп???
Очень интересно, но нафиг не надо.
Наверняка вы что-то не то хотели сказать.
Еще раз ---- с помощью конкретного дилаекта MERGE можно получить поведение версионника - транзакция получит свой снапшот данных консистентных, сможет работать с ним, и до выполнения MERGE (у версионника это просто COMMIT во время которого выполняется слияние данных) никто не сможет получить доступ к этим данным.
Если пойдут более одного MERGE одновременно в разных транзакциях, они будут сериализоваться - блокировками, и выполнятся последовательно.
Эта часть понятна, надеюсь?

Yo!! автор100% в описаной ситуации транзакция3 получит все закомиченные данные транзакции1
втом то и дело что получит все , а не закомиченые на момент t5.1 как нужно для консистентного отчета.

Ничего себе - транзакция1 сделала COMMIT, после этого транзакци3 делает SELECT, и она не должна получить все данные? Она получит и то, что внесла/изменила транзакция1, и то, чего транзакция1 не трогала. Иначе бардак какой-то.

Yo!!
[quot автор]Еще раз ---- с помощью конкретного дилаекта MERGE можно получить поведение версионника [/quot автор]

тогда давайте разбиратся что такое merge, у оракла (да и в стандарте 99 кажется ) это просто синтаксическая фича, если запись есть то делется update .. set value=new_value, если записи нет то делается insert into .. values (new_value)
и все. неужеле в дб2 это что то другое ??
если нет то попробуйте расписать без merge такой код:

транзакция1 update maintable set value=value+5 ;
транзакция2 update maintable set value=value+5 ;
транзакция1 commit ;
транзакция2 commit ;

Дак я же говорю, что для получения поведения версионника необходимо использовать конкретную реализацию sql statement MERGE.
Зачем мне пробовать расписать без MERGE, если тогда я не получу такого поведения??

Yo!! авторНичего себе - транзакция1 сделала COMMIT, после этого транзакци3 делает SELECT, и она не должна получить все данные? Она получит и то, что внесла/изменила транзакция1, и то, чего транзакция1 не трогала. Иначе бардак какой-то.

как только транзакция1 сделала COMMIT, транзакция2 заблокирует данные и транзакция3 будет ждать пока вторая не закомитится. поэтому этот селект никогда не получит отчет на момент t5.1

Полная неправда. В описанной вами ситуации, и с предложенной мной схемой - получит.
Yo!!
автор
Зачем мне пробовать расписать без MERGE, если тогда я не получу такого поведения??

потому что MERGE это всего лишь обыкновенный update в нашем случае и никакой магии не привнесет.
если table.value=0 и идет 2 транзакции одновременно:
t1.транзакция1 insert into temptable select value+5 from table
t1.транзакция2 insert into temptable select value+5 from table
t2.транзакция1 merge
t3.транзакция2 merge
t4.транзакция1 commit
t5.транзакция2 commit

у вас в темтабле будет по 5рке и merge просто заместит table.value пятерками из temptable два раза, т.е. в результате в table.value будет 5 вместо 10, что есть страшный косяк.

Страшный косяк?? Интересно - изменения данных выполнялись изолированно , в своих собственных копиях данных, стало быть value в обеих копиях данных был увеличен на 5 и стал равен 5, затем первая транзакция слила данные во вторую таблицу и закоммитила, после чего вторая транзакция слила данные и закомитила - с чего бы вдруг в основной таблице возникло 10?
Может, поясните логику, откуда в описанной ситуации возьмется 10?
И второе - я предлагал немного другой способ - insert into <temptable> select * from <maintable> where <search condition>,
и только после этого update <temptable> c последующим MERGE.
Но очень хочется понять, с чего в основной таблице value должен будет увеличиться дважды, то есть стать равен 10 (+5 в первой транзакции, в изолированном наборе данных, и +5 во второй транзакции, в ее и изолированном наборе данных)

таак, Yo!!, действительно, с пивом надо завяязывать :)
Давайте сначала.
1) в блокировочнике db2 писатель не блокирует читателя безо всякого Uncomited Read. Это дело управляется тремя переменными (отдельно на insert, update и delete). То есть набором значений трех переменных для трех случаев можно добиваться нужного поведения. Гибко, но когда нужна такая гибкость я не знаю, может кому и нужна. В oracle для этого никаких переменных не надо, но и изменить поведение видимо нельзя, да еще так гибко.
То есть любая транзакция получит свой набор данных несмотря на незакомиченные транзакции писателей. И все это безо всяческих сегментов откада, очень дешевым и производительным способом. Эти конфигурационные параметры действуют на момент компиляции запроса, что позволяет (используя static SQL) иметь разное поведение в паралельных транзакциях в один и тот же момент времени.
2) Если получив в предыдущем случае данные, транзакция поместит их во временную таблицу, то может гонять курсор туда/обратно сколько ей угодно и абсолютно изолировано,и данные консистентны на момент начала транзакции. Этакий сегмент отката, или снапшот данных. Но этот случай мало интересен, а вот когда транзакция начнет менять данные
3) то она превращается в писателя, и на своем изолированном снапшоте данных делает изменения сколь угодно долго. Для слияния своих изменений с основной копией данных транзакция должна вызвать MERGE; COMMIT
В Oracle для этого просто COMMIT.

Получается, что в блокировочнике db2 для получения эффекта версионника надо больше sql предложений, и более тщательное планирование транзакций при дизайне приложений.
Но при этом достигается более высокая производительность за счет того, что не база, а разработчик транзакций определяет, когда надо создавать изолированный набор данных, и более гибко регулируемое поведение (если оно только кому надо)

А теперь я таки хочу понять, почему при начальном значении в таблице value==0 и после того, как две транзакции изолированно выполнят value+=5, потом сольют изменения в основную таблицу --- откуда возьмется 10???

Yo!! еще раз, внимательно
в пункте 1) благодаря трем конфигурационным параметрам db2 писатель не блокирует читателя
в пункте 2) ясно сказано, что читатель, получивший набор согласованных данных в пункте 1) и выгрузивший их во временную таблицу может гонят курсоры сколько угодно на изолированном наборе данных полученных в пункте 1) и никак не влияя на другие транзакции.

Что непонятного?
Или так противно признать, что блокировочник может иметь сходное поведение с версионником, но достигнутое более производительным путем (но требуя более тщательного дизайна транзакций)?

Я попробую запросить ресурс на публично доступную тестовую db2, и если будет желание, все сказанное мной можно будет вжимвую посмотреть.
Быстрее будет встретится в москве и на моем ноуте показать, но если есть время подождать, то можно и на доступном в инете db2