В.К.[quot Журавлев Денис]Я полный ноль в оракл, и двоечник по информиксу, можно вопрос?

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


Прошу прощения что встреваю малость не в тему ни Informix (которого не видал лет 10) ни Oracle (в котором ориентируюсь постольку-поскольку и который не совсем версионник или, скажем так, странный версионник). Я так, заскучал малость и заглянул по ностальгии и в будущем мозги парить с типа саморекламой не буду :-) Настоящих версионников сейчас 2 - Postgress и Firebird/InterBase (который был первым и некоторое время единственным, и с которым я и работаю уже 8 лет). На горизонте ещё маячит Yukon, концептуально почти 1:1 срисовываемый с последних с обещаемым развитием и улучшением. Так вот, версионники могут вести себя по разному в зависимости от уровня изоляции транзакции и режима разрешения блокировок. И даже от количества конкурирующих транзакций в одном из сочетаний уровень-режим ;)

В.К.
"Многоверсионник" значит, что, по умолчанию, каждый оператор видит данные по состоянию на момент начала выполнения. Видит все зафиксированные на этот момент изменения, и ничего другого. Видит, несмотря на любые изменения, которые с этими же данными в этот момент происходят. Данные в согласованном виде (нужная "версия") берутся из ROLLBACK-сегментов.


Это описание уровня изоляции concurrency (snapshot). В уровне изоляции read_commited rec_version при последовательном чтении одних и тех же данных в одной и той же транзакции могут получаться разные результаты - если между чтениями были зафиксированы изменения этих данных, сделанные другими транзакциями. Не зафиксированные на чтение не влияют, считываются последние актульные на момент _чтения_ данные независимо от наличия незафиксированнных версий. Для снапшота - то же самое но на момент старта транзакции, то есть он не видит никаких изменений с момента своего старта, даже фиксированных. Есть уровень изоляции, эмулирующий блокировочник - read_commited no_rec_version - при попытке даже _чтения_ данных, имеющих нефиксированные версии, выдает lock conflict в режиме nowait и ждёт коммита/роллбака изменяющей транзакции в wait.

В.К.
Оператор, изменяющий строку, устанавливает на нее блокировку. Транзакция, которая попытается изменить ту же строку второй, будет заблокирована. А вот если до того, как вторая транзакция начнет менять строку, но после того, как она ее прочитает в исходном виде (невзирая ни на что), первая транзакция ее изменит и закончится (фиксацией), вторая транзакция спокойно эту же строку изменит еще раз и пойдет дальше. А изменение, выполненное первой транзакцией, будет потеряно.


Не, не так. Блокировок как таковых нет, блокировкой изменений является а) в случае снапшота - наличие версий изменяемой записи, появившихся после его старта (поэтому снапшот никогда не может затереть чужих изменений) б) в случае read_commited - наличие нефиксированных версий в момент попытки изменения. И вот этот - может. Поэтому многие люди применяют его именно при записи в случае инкрементных апдейтов - снижается вероятность конфликтов и данные не страдают. А для абсолютных применяют снапшот. Вот по разрешению блокировок (wait/nowait) в read_commited Oracle отличается. Во всех версионниках и в этом псевдоверсионнике конфликт ловится не на коммите, а непосредственно в момент выполнения изменений. В случае nowait все ведут себя одинаково - выдают исключение. В случае wait все ждут завершения конкурирующей транзакции и вот в этот момент Oracle проводит изменения независимо от того что сделал конкурент (коммит или роллбак), FB/IB в случае read_commited rec_version wait и коммита конкурента выдаёт исключение, за Postgress зуб не дам, но насколько помню, он поступает так же. Оракловая схема способствует абсолютно бесконфликтным инкрементным апдейтам, в FB/IB конфликты возможны, к добру или к худу - трудно сказать, от задачи зависит. А вот в read_commited no_rec_version wait на изменениях FB/IB в случае двух конкурирующих транзакций ведёт себя как Oracle, а если больше - выдаёт конфликт третьей и далее :) У версионников есть ещё уровень изоляции consistency - с блокировкой указываемых при старте таблиц целиком только на запись или вообще, но им очень редко пользуются, это скорее режим аварийного обслуживания. Так что возможности очень гибкие и обширные. Ещё раз извиняюсь за рекламу в чужом огороде, прощаюсь :)