ggvТак вот конкретный диалект SQL позволяет мне в этой ситуации получить поведение версионника на блокировочнике.
insert into <temptable> select from <maintable>
затем все нужные изменения в <temptable>, и в конце
merge into <maintable>

Yo!!честно говоря совсем не понял. на время модификации нужна блокировка именно основной записи иначе у вас 2 update смогут одновременно типа править одну и туже запись и получите lost update.
ну и имхо это все равно не решает главную проблему блокировочника - длинные транзакции в OLPT задаче.

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

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

ggvДополняю - речь идет о Cursor Stability,или Read Stability
Параметры называются Scip_inserted, scip_deleted, evaluate_uncomited

ggvНачал, правда, с конца, ошибочно полагая что всем известны возможности db2 де-факто, и не надо пояснять про scip_[inserted/deleted] и evaluate_uncommited.
Повторю лишь, что главный эффект этих фич - устранение эффекта ожидания транзакций и повышение concurency.
И эффект достигнут.


ggvОзвученый мной функционал предназначен для повышения "пропускной" возможности транзакций, аналитика и ibm'овские аналитический продукты предполагается использовать на хранилищах, классический референс дойч телеком, у них же и пополнение онлайновое хранилища.

2ggv
давайте вы определитесь у вас или "поведение версионника на блокировочнике" или какя-то опускная способность.
если версионика то таки пояснить кодом , а то мы люди маленькие и не образованые, в дойч телекоме небыли и не понимаем КАК вы на IL Cursor Stability можете "получить поведение версионника на блокировочнике" ?

SkyNet77Как я понимаю, при CS мы получим все закоммиченные данные на время начала запроса t1?
Версионности нету, значит во время t2 мы получим совершенно другие данные.
Так ведь?
где?

КалинаНу в блокировочнике, как ведет себя Oracle я знаю
в дб2 при cursor stability селект просто все блокирует и проблем с консистентностью у него никаких нет :) они у остальных писателей ...

SkyNet77но другие сессии при нужных настройках могут читать, так ведь?
у блокировочников столько видов блокировок что я потерялся, думаю при чтении ставится shared блокировка которая позволяет читать но не дает изменять. т.е. длинная такая транзакция - смерть OLPT и вариант от ggv ничего не решает.

Ув. gardenman, вы заблуждаетесь, на уровне CS ставится лок именно до конца транзакции:

READ COMMITTED (DB2 UDB: Cursor Stability)

The entire table is locked. Shared locks are released when the associated cursors are closed (isolation levels higher than READ COMMITTED hold shared locks until the end of a transaction ). Exclusive locks are held until the end of the transaction.

No other application can perform any DML operation on a table while an open cursor is accessing it. READ COMMITTED applications cannot see uncommitted changes of other applications.

Both nonrepeatable reads and phantom reads are possible. READ COMMITTED is the default isolation level, allowing maximum concurrency while seeing only committed rows from other applications.

http://publib.boulder.ibm.com/infocenter/weahelp/5.1/index.jsp?topic=/com.ibm.websphere.db2e.doc/db2e_iso_levels.html

извиняюсь не транзакции, а пока курсор открыт

gardenman
Поэтому в реальных системах с ОЛТП Оракл будет выигрывать в быстродействии по сравнению с блокировочником только в том случае, если ему дать раза в два-три шире канал для дискового ввода-вывода. Интенсивный ОЛТП - это прежде всего работа с диском. Тут Оракл пролетает. Сожалею.


и тут вы заблуждаетесь тоже. OLPT это не тольк и не сколько работа с диском. на примерно одинаковом железе оракл в OLPT показывает результаты не хуже дб2, а местами лучше.