2 Дед Маздай

>Если мое понимание верно, то ближайшим аналогом такого поведения в SQL Server является статичный серверный курсор.

Я думаю что это не так. В данном случае открытый курсор это уже готовый результат запроса. И после того как он открыт, естественно, все изменения в базе на этот результат не влияют.
А речь идёт о том что, если ты запустил запрос который будет отрабатывать полчаса, то должен получить результат на начало выполнения запроса без учёта всех свершившихся транзакции за последние полчаса.

>две транзакции взяли себе по snapshot, что-то с ним поделали и хотят записать его обратно. Как определить, кто из них прав? Я не нашел в оракловой документации информации о том, как в случае версионности разрешаются конфликты.

Кто из них прав при записи решается блокировками.

>Кто из них прав при записи решается блокировками.
Это как? Обычно в таких ситуациях победитель определяется по времени или по приоритетам сессий, а при чем здесь блокировки - я не знаю.

Про блокировки это я к тому что одновременно они туда не запишут - блокировки не дадут. А дальше победитель определяется по времени.

2 javajdbc

>--Петя и Вася делают апдейты без комитов (в рамках своей сессии), никто никого не блокирует.

Как это "никто никого не блокирует"??? Проапдейченные записи блокируются для изменения другими сессиями. Если Вяся изменит запись и её же попытается изменить Петя то его update тормозит и ждёт до завершения Васиной транзакции.

>--Шустрый Вася комитится. Оракле берет изначальный
> Васин снапшот, делает аналогичный селект из текущих
> данных и сравнивает. Чужих комитов не было : старый и
> новый селект совпали : Оракле разрешает Васе комит.
> Петя делает комит. Оракле обнаруживает, что текущие
> значения (спасибо Васе) НЕ совпадают с изначалйным
> Петиным снапшотом. Комит не проходит. Петя отдыхает.

Какая по вашему ошибка (ORA-XXXXX) выдаются Пете когда "Комит не проходит" и "Петя отдыхает" ???

Как-то странно Оракл у вас в Монреале работает... глючит наверное. У нас всё по другому.

Ни чего оракл не сравнивает, не делает "аналогичных селектов" (непонимаю как вы это вообще себе представляете...."старый и новый селект совпали"....а если в селекте миллион записей? Запрашивать снова миллион и сверять построчно? ) и тем более не может запретить коммит. После васиного коммита просто пройдёт петин update (который ждал снятия блокировки) а затем петин коммит.

То что вы тут изобразили похоже на поведение Oracle Forms при установленном у датаблока оптимистическом режиме блокировки (возможно у вас так делает не Forms а какой-либо иной клиент). Но это чисто клиентские измочки. И реализуется это без "аналогичных селектов". Просто перед post записи клиентом в бд делается select этой записи по rowid , и делается сравнение.

2 javajdbc

Вы вообще как то странно представляете себе весь процесс. Точнее вы его просто не представляете.

>Петя делает селект. Оракл запоминает все выбраные записи (значения!) с подвязкой на Петю.

Где оракл "запоминает все выбраные записи" да и ещё "с подвязкой на Петю" ??? На самом деле клиент Петя получил просто результат запроса "select * from table where zzz=ddd" (несколько байт или килобайт никчему не обязывающей информации которые отобразило или сохранило его клиентское приложение).

>Вася делает селект, скажем, на той же таблице. Оракл запоминает все значения Васиного селекта.

Тоже самое: на самом деле Вася просто получил результат запроса. Оракл НИЧЕГО ни запоминает.

>Петя и Вася делают апдейты без комитов (в рамках своей сессии), никто никого не блокирует.

Перевожу: Петя и Вася делают update table set aaa=xxx where bbb=yyy причём
ток кто делает это раньше блокирует строчку, а следующий ждёт снятия блокировки (если хочет изменить ту-же строчку).

>Шустрый Вася комитится. Оракле берет изначальный Васин снапшот

Нету НИКАКОГО "изначального снапшота". Что такое по вашему "изначальный Васин снапшот"??? Это то что выбрал "изначальный Васин селект" ??? Дык селект непричём. Коммит просто фиксирует изменения от "update table set aaa=xxx where bbb=yyy" и оракл не помнит все васины селекты...не волнуют оракл васины селекты...

> делает аналогичный селект из текущих данных и сравнивает. Чужих комитов не было : старый и новый селект совпали : Оракле разрешает Васе комит.

какой старый и новый селект ??? Что такое старый селект? Мало-ли чего вася с утра населектил, к прошедшему update и будующему commit это отношения не имеет.

Ну про остальное я уже высказался в предыдущем постинге.

В общем всё что вы тут описывате это либо поведение клиентского приложения (тогда то что вы называете "снапшотами" это клиентские dataset-ы которые при изменении данных, записи не блокируют а при post-записи (перед тем как сделать "update table set aaa=:new-value-of-aaa where rowid=:rowid") в базу проверяют её состояние в БД) либо вольное изложение главы "репликация снппшотами" из документации (там и снапшоты есть и коллизии похожие). Но и то и другое к обсуждаемой теме отношения не имеет.

2 javajdbc

Sorry, веду себя прилично. Но настаиваю на своём.

1. >"Изначальный "снапшот" есть. Оракл хранит его несколько минут (в зависимости от нагрузки).

А если время прошло и оракл его уже не хранит ? Что происходит с Васей и Петей?

На самом деле "снапшотов никаких нет. есть следующее (По документации) : "Oracle stores control information in each data block to manage access by concurrent transactions"

2. >апдайт без коммита никого не блокирует, ни читателя,
ни писателя (без комита!).

Что может быть проще. Попробуй. Открой две сессии, сделай
set transaction ISOLATION LEVEL SERIALIZABLE, проапдейть запись в одной не коммить, запусти update той-же записи в другой сессии, и убедитесь, что сессия 2 ждёт завершения транзакции в сессии 1. Тоесть запись ЗАБЛОКИРОВАНА.

Далее 2 сценария:
1. Commit в сессии 1 : Блокировка снимается. На update в сессии 2 выдаются ошибка "ORA-08177: can't serialize access for this transaction". Причём ошибка не на попытку КОММИТА в сессии 2 как ты написал. А на попытку UPDATE изменённой другой сессий записи.

2. Rollback в сессии 1 : Блокировка снимается. В сессии 2 совершается update.

Причём ORA-08177 будет только если сессия 2 попытается сделать Update раньше чем первая завершит транзакцию. Никакие селекты васи и пети тут не при чём.

3. >Насчет всех утренних селектов Васи. Я уверен, что вы знаете,
что транзакции начинаются с селекта.

Да вы что??? Мы всё ещё про Оракл? Ну тогда вы открыли для меня что-то новое в Oracle. Может ссылка на документацию есть?

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

Хотя насчёт последнего пункта формально "According to the ANSI/ISO SQL standard, with which Oracle is compatible, a transaction begins with the user's first executable SQL statement. Незнаю является ли select - "executable SQL", но попробуйте:

1.
begin
commit;
select XXX into VAR1 from TABLE where rownum<2;
set transaction ISOLATION LEVEL READ COMMITTED;
end;

2.
begin
commit;
update st_employee set fname='sssssa50' where employee_id=3;
set transaction ISOLATION LEVEL READ COMMITTED;
end;

Пример №1 отработает без ошибки, и пример №2 скажет "ORA-01453: SET TRANSACTION must be first statement of transaction". То-есть в примере один транзакция не началась на select-е, а в примере 2 транзакция уже началась на Update.

2 javajdbc

1. Те снапшоты про которые написано в статье "Сегменты отката в СУБД Oracle" нужня для обеспечения непротиворечивости данных ВО ВРЕМЯ выполнения select-a, а не после того как он выполнился. Причём это не снапшот результата твоего select-a (который ты предлагал сравнивать) а снапшот исходных данных в табличке на момент начала запроса (а в случае SERIALIZABLE вероятно на начало твоей транзакции).

Цитаты из твоей доки
/*
In rare situations, Oracle cannot return a consistent set of results (often called a snapshot) for a LONG-RUNNING QUERY. This occurs because not enough information remains in the rollback segments to reconstruct the older data. Usually, this error is produced when a lot of update activity causes the rollback segment to wrap around and overwrite changes needed to reconstruct data that the long-running query requires.
*/

И по поводу как решаются проблема "была или не была изменена кем-то запись с начала моей SERIALIZABLE транзакции" безо всяких снапшотов.

/*
Serializable isolation permits concurrent transactions to make only those database changes they could have made if the transactions had been scheduled to execute one after another. Specifically, Oracle permits a serializable transaction to modify a data row only if it can determine that prior changes to the row were made by transactions that had committed when the serializable transaction began.

To make this determination efficiently, Oracle uses control information stored in the data block that indicates which rows in the block contain committed and uncommitted changes. In a sense, the block contains a recent history of transactions that affected each row in the block. The amount of history that is retained is controlled by the INITRANS parameter of CREATE TABLE and ALTER TABLE.
*/

2> В данный момент не могу подтвердить на живом Оракле, хотя помню ситуацию - конкретно проверял и тестировал около 2 лет назад

Сочувствую что проверить не можешь, но я перед тем как сообщение №3 запостил - проверил. Есть блокировка. Описание в постинге №3 сделано именно по результатам проверки на живом Oracle 8.1.7 SE.

3> ролбака хватает на несколько минут (3-5 минут на "средний" коробке, примерно 50-70 тх/сек). затем "снапшот ту олд" кажется ора-1555.

Так сказать ("средняя коробка", "минут" ) вообще трудно. это зависит update activity во ВРЕМЯ ВЫПОЛНЕНИЯ твоего селекта и от размера и количества rollback segment-ов.
--You can avoid this error by creating more or larger rollback segments.