Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
 Уровни изоляции и версионность  [new]
Дед Маздай
Member

Откуда:
Сообщений: 655
Согласно ANSI определяются следующие уровни изоляции транзакций:
READ UNCOMMITTED - одна транзакция может прочитать изменения в данных, сделанные другой транзакцией, которые впоследствии не будут ею зафиксированы (грязное чтение).
READ COMMITTED - грязное чтение не допускается, однако внутри данных, уже прочитанных одной транзакцией допускаются изменения, сделанные другой транзакцией, так что если первая транзакция их перечитает, результат может отличаться от ее первого чтения.
REPEATABLE READ - лечит предыдущую ситуацию, не допуская модификации прочитанных данных, однако вставка новых записей внутрь прочитанного диапазона все-таки допускается (фантомы).
SERIALIZABLE - фантомы тоже не допускаются.
Вся эта классика поддерживается в SQL Server 2000.

Вопрос к представителям других конфессий. Какие уровни изоляции у вас поддерживаются и что с этой точки зрения означает версионность?
18 апр 03, 12:30    [178494]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Denis Popov
Member

Откуда: Санкт-Петербург
Сообщений: 7862
Oracle Isolation Levels
http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c21cnsis.htm#2641

Read committed This is the default transaction isolation level. Each query executed by a transaction sees only data that was committed before the query (not the transaction) began. An Oracle query never reads dirty (uncommitted) data.

Because Oracle does not prevent other transactions from modifying the data read by a query, that data can be changed by other transactions between two executions of the query. Thus, a transaction that executes a given query twice can experience both nonrepeatable read and phantoms.

Serializable Serializable transactions see only those changes that were committed at the time the transaction began, plus those changes made by the transaction itself through INSERT, UPDATE, and DELETE statements. Serializable transactions do not experience nonrepeatable reads or phantoms.

Read-only Read-only transactions see only those changes that were committed at the time the transaction began and do not allow INSERT, UPDATE, and DELETE statements.
18 апр 03, 12:41    [178516]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Дед Маздай
Member

Откуда:
Сообщений: 655
А может кто-либо из благородных донов популярно объяснить про версионность в Oracle или дать ссылки, где это описано в otn?
18 апр 03, 12:53    [178550]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Paul Atreidies
Member

Откуда:
Сообщений: 35
DB2 <=> MSSQL :)
Uncommited Read like MSSQL READ UNCOMMITTED
Cursor Stability - only ensures that the current row of every updatable cursor is not changed by other application processes and ensures that any row that was changed by another application process cannot be read until it is committed by that application process
Repetable Stability like MSSQL REPEATABLE READ
Repeatable Read like MSSQL Serializable
18 апр 03, 12:55    [178559]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
SiDen
Member

Откуда:
Сообщений: 518
To Дед Маздай:
Посмотрите http://doc.novsu.ac.ru/oracle/conceps/7013scm.10.html
или http://www.nwsta.com/Soft/oracle/7013scm.10.php
18 апр 03, 13:41    [178650]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Дед Маздай
Member

Откуда:
Сообщений: 655
Насколько я понял из этих материалов, версионность - это когда каждая транзакция получает свою личную копию потребного ей куска данных. Если другие транзакции уже работают с этими данными и что-то в них поменяли, но еще не закоммитились, изначальные данные реконструируются из undo-сегментов. Т.е. по сути в случае версионности транзакция работает не с реальными данными, а с их мгновенным снимком на ее начало. Реальные данные затрагиваются только в момент ее фиксации, поэтому несмотря на то, что де факто это уровень изоляции serializable, вероятность наткнуться на данные, заблокированные другой транзакцией, в этом режиме минимальна.

Если мое понимание верно, то ближайшим аналогом такого поведения в SQL Server является статичный серверный курсор. Однако он не допускает модификаций: "Defines a cursor that makes a temporary copy of the data to be used by the cursor. All requests to the cursor are answered from this temporary table in tempdb; therefore, modifications made to base tables are not reflected in the data returned by fetches made to this cursor, and this cursor does not allow modifications", что естественно, потому что при этом возможны конфликты: две транзакции взяли себе по snapshot, что-то с ним поделали и хотят записать его обратно. Как определить, кто из них прав? Я не нашел в оракловой документации информации о том, как в случае версионности разрешаются конфликты.
18 апр 03, 14:23    [178736]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Paul Atreidies
Member

Откуда:
Сообщений: 35
Сорри - опечатка:
не Repetable Stability а Read Stability
18 апр 03, 14:30    [178756]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Zaxx
Guest
2 Дед Маздай

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

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

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

Кто из них прав при записи решается блокировками.
18 апр 03, 15:10    [178853]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Дед Маздай
Member

Откуда:
Сообщений: 655
>открытый курсор это уже готовый результат запроса... если ты запустил запрос который будет отрабатывать полчаса, то должен получить результат на начало выполнения запроса без учёта всех свершившихся транзакции за последние полчаса.
Ты прав. Согласен. Курсорная аналогия не катит. Просто снимки данных на начало транзакции.

>Кто из них прав при записи решается блокировками.
Это как? Обычно в таких ситуациях победитель определяется по времени или по приоритетам сессий, а при чем здесь блокировки - я не знаю. Если можно, пример.
18 апр 03, 15:25    [178904]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Zaxx
Guest
>Кто из них прав при записи решается блокировками.
Это как? Обычно в таких ситуациях победитель определяется по времени или по приоритетам сессий, а при чем здесь блокировки - я не знаю.

Про блокировки это я к тому что одновременно они туда не запишут - блокировки не дадут. А дальше победитель определяется по времени.
18 апр 03, 15:36    [178929]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Roman Ignatiev
Member

Откуда: Москва
Сообщений: 680
Interbase/Firebird
READ UNCOMMITTED нет, остальное есть кроме SERIALIZED, но можно эмулировать и это, через блокировки таблиц
у транзакций гораздо больше параметров, и явного соответствия уровней нет - версионность.
Подробно: http://www.ibase.ru/devinfo/ibtrans.htm
18 апр 03, 16:55    [179105]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Paul Atreidies
Member

Откуда:
Сообщений: 35
Я в прощлые выходные скачал SAPDB посмотреть.
По поводу транзакций - стандарту ANSI соответствует. + есть еще один уровень - что-то промежуточное между READ COMMITTED и REPEATABLE READ.

Кстати, кто говорил что это аналог Oracle 7? В чем это заключается? Судя по документации к базе - только в частичной поддержке языка 7-й версии. Или в чем-то еще?
19 апр 03, 15:18    [179471]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
javajdbc
Member

Откуда: Montreal
Сообщений: 17715
Дед,

ТХ сериалазабле отрабатывается примерно так:

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

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

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

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

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

ЙЙ.
19 апр 03, 17:27    [179490]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Zaxx
Guest
2 javajdbc

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

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

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

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

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

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

То что вы тут изобразили похоже на поведение Oracle Forms при установленном у датаблока оптимистическом режиме блокировки (возможно у вас так делает не Forms а какой-либо иной клиент). Но это чисто клиентские измочки. И реализуется это без "аналогичных селектов". Просто перед post записи клиентом в бд делается select этой записи по rowid , и делается сравнение.
20 апр 03, 20:49    [179635]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Zaxx
Guest
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") в базу проверяют её состояние в БД) либо вольное изложение главы "репликация снппшотами" из документации (там и снапшоты есть и коллизии похожие). Но и то и другое к обсуждаемой теме отношения не имеет.
20 апр 03, 22:19    [179647]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
javajdbc
Member

Откуда: Montreal
Сообщений: 17715
Захх, Ок, давайте по порядку:

на пост 20.49

1. Я описал поведение лично Оракла (без клиентов) при
ТХ левел - сериалайзабле. По слыслу это оптимистическая
блокировка.

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

3. ОРА ошибки вы сможете найти по ссылке в конце поста.

4. Захх, ваше описание похоже на пессимистичный локинг
путем селекта фор апдайт.

на пост 22.49

5. то что я описал - я представляют нормально, если вы
думаете про другой случай (другой вид лока) то потрудитесь,
пожалуйста, вести себя прилично, по крайней мере.

6. Изначальный "снапшот" есть. Оракл хранит его несколько минут
(в зависимости от нагрузки). Насчет повторного селекта - скорее вы
правы - делается не полный селект, а сравнение только тех
записей, которые апдейчены (блин, как по русски то?).

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

надеюсь, английский у вас без проблем:
http://download-west.oracle.com/docs/cd/A91202_01/901_doc/appdev.901/a88876/adg08sql.htm#2655

ЙЙ
21 апр 03, 01:42    [179655]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Zaxx
Guest
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. Может ссылка на документацию есть?

И если транзакция начинается с первого утреннего селекта Васи и Пети и если к обеду они решили изменить по записи то огребут кучу проблем?
21 апр 03, 08:34    [179692]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Zaxx
Guest
Хотя насчёт последнего пункта формально "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.
21 апр 03, 09:21    [179727]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
javajdbc
Member

Откуда: Montreal
Сообщений: 17715
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 раньше чем первая завершит транзакцию. Никакие селекты васи и пети тут не при чём.


В данный момент не могу подтвердить на живом Оракле, хотя помню ситуацию - конкретно проверял и тестировал около 2 лет назад. Если не было явной блокировки (напромер селект фор апдате) некомиченые изменения не блокируют другуе ТЖ ни в коем образе.

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

что транзакции начинаются с селекта.

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


Извольте, см. ниже.

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


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

Литература:
http://soft.teleserv.ru/oracle/product/administr.html
http://www.csis.gvsu.edu/GeneralInfo/Oracle/appdev.920/a96590/adg08sql.htm
www.cs.odu.edu/~ibl/450/pdf/view-on-line/ oralock/OracleLock.pdf
http://home.fms.indiana.edu/users/cshelton/oracle/server.815/a67781/c23cnsis.htm
21 апр 03, 16:22    [180288]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
Zaxx
Guest
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.
21 апр 03, 21:51    [180547]     Ответить | Цитировать Сообщить модератору
 Re: Уровни изоляции и версионность  [new]
javajdbc
Member

Откуда: Montreal
Сообщений: 17715
Zaxx,

что-то тут не так.... я доберусь до зеленого окошка,
а там и поговорим с листингом...ОК?

JJ
22 апр 03, 06:38    [180628]     Ответить | Цитировать Сообщить модератору
Все форумы / Сравнение СУБД Ответить