SQL.RU
 client/server technologies
 
 Главная | Документация | Статьи | Книги | Форум | Опросы | Рассылка | Работа | Поиск | FAQ |

Добро пожаловать в форум, Guest  >>  Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик  Ответить
 Write consistency by READ COMMITED isolation level   [new]
Violina
Member

Откуда: Санкт-Петербург
Сообщений: 3664
Вынесу в отдельную тему возникший вопрос по write consistency. Обсуждается следующий случай.

Как поступает Oracle если во время выполнения одиночного update запроса, в результате коммита в другой сессии меняется набор строк, удовлетворяющих предикату P в update запросе.

- Если к существующему набору строк добавляются новые строки, удовлетворяющих предикату, то Oracle игнорирует сей факт и выполняет update для тех строк, которые удовлетворяли предикату на момент начала update запроса.

Session 1                                  commit
|-------------------------------------------->

{1,2,3} ∈ P {1,2,3,4} ∈ P Session 2: single update statement |------------------------------------------------------>
{1,2,3} ∈ P 4 ignored updated for {1,2,3}


- Если из существующего набора строк изчезают некоторые строки, поскольку больше не удовлетворяют предикату, то Oracle перестартует update запрос и выполняет его для "нового" набора строк, которые удовлетвояют предикату на момент после коммита в другой сессии.

Session 1                                  commit
|-------------------------------------------->

{1,2,3} ∈ P {1,2} ∈ P Session 2: single update statement |------------------------------/ restart
{1,2,3} ∈ P /----------------------->
{1,2} ∈ P updated for {1,2}

Пример к схемам приведен во втором постинге.

Ссылки на исходные дискуссии

Ответ Тома на вопрос о consistent write...
Single-statement 'write consistency' on read committed. Oh, really?
write "consistency"

Комментарий vc123

The original poster, in the thread you've referenced, claimed the following:

1. Oracle READ COMMITTED isolation level makes a stronger consistency promise than the standard requires. The mechanism which ensures this stronger kind of consistency is the restarts Oracle performs when the subset of rows satisfying a certain predicate changes due to other concurrent transaction updates/deletes.

2. The restart mechanism, unfortunately, works only if the subset of such rows shrinks, otherwise no restart happens.

I disagreed with the OP on Item 1 because, in my opinion, Oracle has never made such a promise with respect to READ COMMITTED.

However, I agree with him on Item 2 where Oracle exhibits inconsistent behaviour. There are two possibilities here:

a. The restarts are unnecessary because READ COMMITTED promise is held without them anyway. So why bother and restart the statement ?

b. Assuming, as the OP believes, the restarts are necessary to make a 'better' READ COMMITTED, why does Oracle not restart in *all* the cases, whenever the subset of rows satisfying the predicate changes in any way ?
11 июл 04, 18:07    [798847] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
Violina
Member

Откуда: Санкт-Петербург
Сообщений: 3664
Исходные данные:
create table test(
id int,
flag int,
val int
);

insert into test values (1, 1, 0);
insert into test values (2, 1, 0);
insert into test values (3, 1, 0);
insert into test values (4, 0, 0);
insert into test values (5, 0, 0);
commit;

Пример 1: к существующему набору строк добавляются новые строки
select * from test;

        ID       FLAG        VAL
---------- ---------- ----------

1 1 0 2 1 0 3 1 0 4 0 0 5 0 0 Session 1 update test set flag = 1 where id = 4; -- добавлям новую строку id=4 удовлетворяющую предикату
update test set val = 100 where id = 1; select * from test; ID FLAG VAL ---------- ---------- ----------
1 1 100 2 1 0 3 1 0 4 1 0 5 0 0 Session 2 update test set val = 100 where flag = 1; -- ожидание
Session 1 commit; Session 2 -- продолжение после ожидания
3 rows updated. select * from test; ID FLAG VAL ---------- ---------- ----------
1 1 100 2 1 100 3 1 100 4 1 0 -- новая строка с id=4 проигнорирована
5 0 0

Пример 2: из существующего набора строк изчезают некоторые строки
select * from test;

        ID       FLAG        VAL
---------- ---------- ----------

1 1 0 2 1 0 3 1 0 4 0 0 5 0 0 Session 1 update test set flag = 0 where id = 3; -- строка id=3 больше не удовлетворяет предикату
update test set val = 100 where id = 1; select * from test; ID FLAG VAL ---------- ---------- ----------
1 1 100 2 1 0 3 0 0 4 0 0 5 0 0 Session 2 update test set val = 100 where flag = 1; -- ожидание
Session 1 commit; Session 2 -- продолжение после ожидания
2 rows updated. select * from test; ID FLAG VAL ---------- ---------- ----------
1 1 100 2 1 100 3 0 0 -- Oracle учел что строка с id=3 уже не удовлетворяет предикату
-- и выполнил update для нового набора строк
4 0 0 5 0 0
11 июл 04, 18:09    [798848] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
Violina
Member

Откуда: Санкт-Петербург
Сообщений: 3664
PS
Проверила на MS SQL 2000 для READ COMMITED.

MS SQL restarts in *all* the cases, whenever the subset of rows satisfying the predicate changes in any way.

Другими словами, в таком случае update запрос всегда выполняется для нового набора строк, которые удовлетвояют предикату на момент после коммита в другой сессии.
11 июл 04, 18:44    [798857] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
denm
Member

Откуда: { empty }
Сообщений: 2792
Мне кажется, все дело в механизме блокировок.

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

Когда первая сессия снимает блокировку, проверяется уже второй раз, подходит ли эта строка под условия предиката и она изменяется или нет. Никакого рестарта апдейта нет.

Впрочем, это на уровне догадки. Надо почитать документацию.

Еще интересно, с каким SCN пишутся локи :)
11 июл 04, 18:57    [798862] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
Violina
Member

Откуда: Санкт-Петербург
Сообщений: 3664
Чтобы создать этот топик, я тщательно подготовилась, прочитав приведенные ссылки.

denm
Впрочем, это на уровне догадки. Надо почитать документацию.


vc123
The reason for the selective restarts has never been explained in any of Oracle texts. By the way, reading Concepts ain't gonna help much since the document does not have a single word to say about the restarts.


Есть только замечание

Note: Transactions containing DML statements with subqueries should use serializable isolation to guarantee consistent read.


denm
Никакого рестарта апдейта нет.


По видимому есть, из дискуссии

Jonathan Lewis
Oracle restarts only if it comes to a row where the
predicate columns have moved the row from
being 'in-scope' to being 'out of scope'. (So no-change
to predicates, and a change that moves a row from
'out of scope' to 'in-scope' is ignored.


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

create or replace package logpkg is
cnt int;
end;
/

create or replace function gen100 return number
is
begin
logpkg.cnt := logpkg.cnt + 1;
return 100;
end;
/

Выполняя во второй сессии

Для первого примера
SQL> exec logpkg.cnt := 0;

PL/SQL procedure successfully completed.

SQL> update test set val = gen100() where flag = 1;

3 rows updated.

        ID       FLAG        VAL
---------- ---------- ----------

1 1 100 2 1 100 3 1 100 4 1 0 5 0 0 SQL> exec dbms_output.put_line(logpkg.cnt); 3 PL/SQL procedure successfully completed.
update запрос был приеменен к 3 строкам, фунцкия была вызывана 3 раза.

Для второго примера
SQL> exec logpkg.cnt := 0;

PL/SQL procedure successfully completed.

SQL> update test set val = gen100() where flag = 1;

2 rows updated.

SQL> select * from test;

        ID       FLAG        VAL
---------- ---------- ----------

1 1 100 2 1 100 3 0 0 4 0 0 5 0 0 SQL> exec dbms_output.put_line(logpkg.cnt); 5 PL/SQL procedure successfully completed.
update запрос был приеменен к 3 строкам, перезапущен и применен к 2 строкам, фунцкия была вызывана 5 раз.

PS
При этом происходит mini-rollback (термин встретила у Тома) и повторное выполнение для новых строк удовлетворяющих предикату.
11 июл 04, 19:45    [798873] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
vc123
Member

Откуда:
Сообщений: 310
To Violina:

It may be obvious but I should have probably said that it's hard, perhaps even impossible, to implement 2b (detecting new rows) efficiently while 2a is easy: Oracle has just to re-check the predicate during the write phase. However, the question why 2a is needed at all remains.

Regarding MS SQL Server. It does not restart the statement. The update locks just prevent the 'main' transaction from progressing any further until the concurent intervening transaction(s) commits. This is not the case in Oracle where the select part of the 'main' transaction gets all the candidate rows and then the update part tries to do its job.
11 июл 04, 20:08    [798883] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
vc123
Member

Откуда:
Сообщений: 310
<quote>
Note: Transactions containing DML statements with subqueries should use serializable isolation to guarantee consistent read.
</quote>

Actually Oracle's SERIALIZABLE is not truly serializable as this simple SQL will easily show:

insert into t1 select max(x)+1 from t1; -- generate unique seq ids

NB: I know that the sequence is 'better'

VC
11 июл 04, 20:40    [798904] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
Violina
Member

Откуда: Санкт-Петербург
Сообщений: 3664
vc123
Regarding MS SQL Server. It does not restart the statement.


Да, я не удачно взяла вашу цитату про resarts для описания ситуации в MS SQL, оставим

В MS SQL в таком случае update запрос всегда выполняется для нового набора строк, которые удовлетвояют предикату на момент после коммита в другой сессии.
11 июл 04, 20:52    [798907] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
Violina
Member

Откуда: Санкт-Петербург
Сообщений: 3664
to vc123

vc123
Actually Oracle's SERIALIZABLE is not truly serializable as this simple SQL will easily show:

insert into t1 select max(x)+1 from t1; -- generate unique seq ids


В чем "неправильность" этого запроса? SERIALIZABLE изолирует от "чужих" изменений, но не от своих собственных. Так что для меня поведение этого запроса вполне ожидаемое. В чем же загвозка?

vc123
I should have probably said that it's hard, perhaps even impossible, to implement 2b (detecting new rows) efficiently while 2a is easy: Oracle has just to re-check the predicate during the write phase.


Мне сложно судить, но почему должно быть намонго сложнее

re-check the predicate during the write phase in order to detect new rows

чем

re-check the predicate during the write phase in order to detect 'out of scope' rows

?
11 июл 04, 21:04    [798910] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
vc123
Member

Откуда:
Сообщений: 310
To Violina:

<quote>
В чем "неправильность" этого запроса? SERIALIZABLE изолирует от "чужих" изменений, но не от своих собственных. Так что для меня поведение этого запроса вполне ожидаемое. В чем же загвозка?
</quote>

Not quite. The very definition of SERIALIZABLE says, informally, that a concurrent execution of some transactions (transaction history) should be equivalent to a *serial* execution thereof. In other words, the database state achieved as a result of concurrent transaction run should be the same as when the transactions were executed serially. Clearly, with the SQL I gave, some transaction histories are not serializable however Oracle SERIALIZABLE would happily allow them. MS SQL Server, by the way, will produce correct results in its SERIALIZABLE mode by allowing only serializable hostories and aborting non-serializable ones.

Oracle can get away with the label since its SERIALIZABLE satisfies the old defective definition of the SERIALIZABLE in terms of "phenomena" ( see A Critique of ANSI SQL Isolation Levels, http://www.cs.duke.edu/~junyang/courses/cps216-2003-spring/papers/berenson-etal-1995.pdf ).

<quote>
Мне сложно судить, но почему должно быть намонго сложнее

re-check the predicate during the write phase in order to detect new rows

чем

re-check the predicate during the write phase in order to detect 'out of scope' rows
</quote>

Oracle gets a set of rows in the read-consistent mode and then proceeds to write changes in the current mode. When Oracle re-reads a block (previously read in the consisten mode) in the current mode, it 'sees' that, say, the row no longer satisfies a predicate and restarts. How would Oracle know that *new* rows satisfiing the predicate appeared ? What would notify it about the change ? Remember, Oracle read the original row as of the moment the query started so it has no way to discover that a new row, as a result of say update appeared.

VC
11 июл 04, 21:36    [798914] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
Violina
Member

Откуда: Санкт-Петербург
Сообщений: 3664
to vc123

vc123
MS SQL Server, by the way, will produce correct results in its SERIALIZABLE mode by allowing only serializable hostories and aborting non-serializable ones.


Потестировала на обеих СУБД. Да результат в MS SQL SERIALIZABLE правилен с точки зрения определения [equivalent to a *serial* execution thereof], но выполнение этих запросов действительно сериализовано - они выстраиваются в очередь. Как я поняла, собака зарыта в версионности versus блокировки чтения. В MS SQL запрос 'select max(x) from t1' ждет пока результат insert'a будет закоммичен.

vc123
When Oracle re-reads a block (previously read in the consisten mode) in the current mode, it 'sees' that, say, the row no longer satisfies a predicate and restarts. How would Oracle know that *new* rows satisfiing the predicate appeared ? What would notify it about the change ?


OK. Теперь понятно.
11 июл 04, 22:25    [798932] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
vc123
Member

Откуда:
Сообщений: 310
To Violina:

<quote>
В чем "неправильность" этого запроса? SERIALIZABLE изолирует от "чужих" изменений, но не от своих собственных. Так что для меня поведение этого запроса вполне ожидаемое. В чем же загвозка?
</quote>

Not quite. The very definition of SERIALIZABLE says, informally, that a concurrent execution of some transactions (transaction history) should be equivalent to a *serial* execution thereof. In other words, the database state achieved as a result of concurrent transaction run should be the same as when the transactions were executed serially. Clearly, with the SQL I gave, some transaction histories are not serializable however Oracle SERIALIZABLE would happily allow them. MS SQL Server, by the way, will produce correct results in its SERIALIZABLE mode by allowing only serializable hostories and aborting non-serializable ones.

Oracle can get away with the label since its SERIALIZABLE satisfies the old defective definition of the SERIALIZABLE in terms of "phenomena" ( see A Critique of ANSI SQL Isolation Levels, http://www.cs.duke.edu/~junyang/courses/cps216-2003-spring/papers/berenson-etal-1995.pdf ).

<quote>
Мне сложно судить, но почему должно быть намонго сложнее

re-check the predicate during the write phase in order to detect new rows

чем

re-check the predicate during the write phase in order to detect 'out of scope' rows
</quote>

Oracle gets a set of rows in the read-consistent mode and then proceeds to write changes in the current mode. When Oracle re-reads a block (previously read in the consisten mode) in the current mode, it 'sees' that, say, the row no longer satisfies a predicate and restarts. How would Oracle know that *new* rows satisfiing the predicate appeared ? What would notify it about the change ? Remember, Oracle read the original row as of the moment the query started so it has no way to discover that a new row, as a result of say update appeared.

VC
11 июл 04, 22:57    [798940] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
denm
Member

Откуда: { empty }
Сообщений: 2792
Спасибо, Виолина, за акцентирование внимания на этом (основном) вопросе. Очередной стереотип развеян :)

I am reading it and am realizing now what an awesome complex beast is Oracle

Завтра пороюсь в Металинке, может что-нибудь найду...

В обсужении на AskTom (ссылка - выше) содержится довольно много интересной информации, в частности:

1) the update always sees the rows as of the time the statement began, we just move the concept of "when the statement began" (т.е. в моем рассуждении выше, при снятии блокировки, если строка удовлетворяет условию, происходит рестарт - mini-rollback): It must restart in order to "do the right thing", it really needs to see the data as of "now" in order to safely update it (c) tkyte.

2) Причина рестарта, в том числе, чтобы сохранить атомарность первой сессии.

3) при рестарте update не освобождает уже наложенные локи (и это позволяет избежать бесконечных рестартов с большой вероятностью)

4) кое-что про DDL в триггерах (в конце), представляет особенный интерес для Scott Tiger'а :)
11 июл 04, 23:39    [798966] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
yuniki
Member

Откуда:
Сообщений: 1171
<b>2 ALL !!!!!!!!! ></b>

Тоже тут поразбирал обсуждения :

http://ln.com.ua/~openxs/projects/oracle/ora048.html
http://ln.com.ua/~openxs/projects/oracle/ora071.html

а также :
http://www.sql.ru/forum/actualthread.aspx?tid=126913&hl=http+ln+com+ua+openxs+projects+oracle+ora048+html
( http://www.sql.ru/forum/actualthread.aspx?tid=106069#798847 - это это для полноты сссылок )

Суть, напомню, в мини-откатах на уровне отдельного UPDATE в транзакции с TIL=RC.


И не мог удержаться от 2 вопросов :
1) Получается Oracle не использует 2PL для блокирования при изменнеиях - Почему так?
А это ясно видно при журналированиии Tomom Кайтом в автономной транзакции - если бы это было не так, то то у нас журнал бы не подвисал на ожидании, а прежде , чем начал бы работать тригер журналирования, ВСЕ записи исходного предикатного множества были бы заблокированы.
2) Нигде при обсуждении причин мини-отката не нашел ответа на вопрос:
Почему нельзя в случае, если очередная строка при сканировании перестает попадать в исходное на начало UPDATE оператора предикатное множество, просто взять и пропустить ее и идти дальше - разве это как-то нарушит совместность данных ?

Ps.
А Том то ,бедняга, сам не так уж давно это узнал ;) :
До августа 2003 года я не исследовал эту проблему настолько серьезно.

ТОгда же я хлопнул себя по лбу и сказал "Ага, это объясняет, что произошло в июне 2000 года".
10 фев 05, 03:03    [1312159] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
Я и ёжик
Member

Откуда: СПб
Сообщений: 1511
yuniki
1) Получается Oracle не использует 2PL для блокирования при изменнеиях - Почему так?
А это ясно видно при журналированиии Tomom Кайтом в автономной транзакции - если бы это было не так, то то у нас журнал бы не подвисал на ожидании, а прежде , чем начал бы работать тригер журналирования, ВСЕ записи исходного предикатного множества были бы заблокированы.

Искать в каком месте, какой “журнал бы не подвисал на ожидании" не имею сейчас возможности, но Вы по-моему неправильно понимаете 2PL. 2PL требует, что бы блокировки сначала ставились, а потом ( в конце транзакции) снимались. Нет требования , что бы они ВСЕ ставились сразу, что и невозможно, транзакция может состоять из нескольких операторов, выполняя один нельзя знать , что надо блокировать выполняя другой, да и в рамках выполнения одного оператора нельзя поставить ВСЕ блокировки СРАЗУ.
2PL требует что бы выставленная блокировка снималось в конце транзакции , а не в середине, т.е. чтобы не было внутри транзакций цепочек блокировок типа "постановка-снятие-постановка-снятие...".

yuniki

2) Нигде при обсуждении причин мини-отката не нашел ответа на вопрос:
Почему нельзя в случае, если очередная строка при сканировании перестает попадать в исходное на начало UPDATE оператора предикатное множество, просто взять и пропустить ее и идти дальше - разве это как-то нарушит совместность данных ?

Потому, что это не соответствует никакому последовательному расписанию транзакций. Если Вы дочитаете книгу Бернштайна, которую Вам рекомендовали tengizk и Merle_, до момента обсуждения неблокирующих шедулеров транзакций, то увидите, что для шедулера с упорядочиванием по меткам времени, если изменяющая транзакция натыкается на данные, которые были изменены после её начала, она должна быть откачена ( иначе будет нарушение сериализуемости). На уровне изоляции Oracle Serializable ( т.е. SNAPSHOT в теории, поскольку в Oracle нет "честного" Serializable) так и происходит, выдается ошибка ORA-8177 ( can't serialize).
Oracle уровень изоляции Read Commited, является некоторым гибридом между
теоретическим Read Committed и Snapshot, с некоторой натяжкой его можно назвать Snapshot-м на уровне отдельного оператора. Т.е. если оператор натыкается на данные, измененные после его начала, то он должен быть откачен, если откачен один оператор, то вроде бы должна быть откачена и вся транзакция, но это было бы несколько дороговато, поэтому Oracle после отката оператора пытается его выполнить снова (перезапуск).
Натяжка заключается в том , что откат и перезапуск осуществляется не всегда, а только при некоторых условиях. Почему так сделано и правильно ли это, здесь долго ломали копья vc123 с одной стороны и кто-то из DBGroup Consulting c Fucker-ом, но остались при своём.

Если Бернштайн слишком объемен и сложен, можно посмотреть сначала что-нибудь типа - Гектор Гарсиа-Молина Джеффри Ульман и Дженнифер Уидом "Системы баз данных. Полный курс", у них хорошие главы посвященные управлению параллельным исполнением заданий, там рассмотрены и блокировочные шедулеры и некоторые неблокировочные шедулеры транзакций. Книга по-моему ещё лежит в книжных магазинах.
10 фев 05, 12:40    [1313221] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
yuniki
Member

Откуда:
Сообщений: 1171
Я и ежик >
Спасибо за ответы.
Но должен все-же сказать следующее
1) По поводу 2PL я , возможно, действительно понимал неверно. Как -то где я не сталкивался с опсанием этого принципа на этом не затачивалось внимание и понимал именно так, что вначале ВСЕ блокировки наложить, потом обработать все множество, потом снимать блокировки.
Вопрос тогда будет такой :
Для транзакции полностью согласен, что такое более жесткое требование не возможно,
но для уровня оператора - почему бы было этого не сделать? Это бы сильно облегчило нам накладные расходы на мини-переоткаты в расматриваемом случае.
Почему я еще думал, что так работает 2PL - ведь SELECT FOR UPDATE делает именно это - накладывает все монопольные блокировки на предикатное множество.Почему же операторы UPDATE,DELETE,INSERT этим обделили, ну уж колб скоро используется техника блокирования.

2) По поводу главного вопроса.
К сожалению, у меня пока нет возможности закачать рекомендованые слишком тяжелые книжки, и купить удастся не скоро.
Я просил бы в нескольких словах раскрыть саму идею - почему в упомянутом случае нельзя пропускать заблокированные другими транзакциями записи.
Если это Вам или вашему ежику понятно, то нельзя ли сделать на один параграф объяснение что-то типа "Нedgehogs: one to one".

Так Вы сказали, что пропускать записи не возможно, иначе нарушится сериализуемость - Как я понимаю на уровне одного оператора UPDATE нарушится.
И ссылаетесь при этом на планировпние транзакций по временным отметкам, но Oracle разве так работает - разве при модификации он не использует блокировку записей? Вроде как использует. А раз использует, гибрид он этакий, то при таком ,даже пускай последовательном на уровне одного оператора подходе к блокированию-редактированию, я не могу понять простой вещи - в каком случае может произойти нарушение сериализуемости - никакого примера на ум не приходит. Ведь просто исходное множество предиката в UPDATE обработается так как и должно при единственном UPDATE(без параллельных), за исключением выкинутых из него (за счет других транзакций) данных . Пополняется исходное предикатное множество - ничего игнорируем, шагаем дальше по записям, усекается - сразу перезапуск оператора. Почему такая логика ?
Или что еще понимать под сериализуемостью - в том смысле, относительно какого исходного на начало оператора множества данных идет речь, должно ли оно оставаться постоянным, т.е. содержать те же элементы-записи ?
Помогите понять в чем нюанс.
10 фев 05, 20:45    [1314715] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
mcureenab
Member

Откуда: Murmansk
Сообщений: 5009
Violina

PS
При этом происходит mini-rollback (термин встретила у Тома) и повторное выполнение для новых строк удовлетворяющих предикату.



yuniki


Почему я еще думал, что так работает 2PL - ведь SELECT FOR UPDATE делает именно это - накладывает все монопольные блокировки на предикатное множество.Почему же операторы UPDATE,DELETE,INSERT этим обделили, ну уж колб скоро используется техника блокирования.



Update может выполтяться в два захода.
1. Получаем SCN. Без предварительного блокирования строк ищем запись, проверяем, что она не изменилась (по крайней мере неизменились те поля, которые фигурируют в запросе), изменяем её, ищем следующую, и т.д.... Если всё получилось, запрос выполнен.
2. Если наткнулись на изменённую запись, откатываем изменения, получаем новый SCN, выполняем, грубо говоря, select for update, только execute без fetch. Если блокировка не удалась (опять же по причине изменения записей), снова получаем SCN, выполняем select for update и т.д.
3. Снова ищем записи, изменяем их. Теперь нам уже никто не помешает.

Таким образом update может выполнить максимум две попытки обновления строки, при этом срабатывают триггеры. В каждой попытке могут изменяться разные наборы строк. Шаг 2 может выполняться бесконечно (собственно select for update с nowait или без, может выполняться бесконечно).

Для delete тоже не всё так просто. Фаза блокирования строк в нём тоже присутствует.
Собственно delete сначала выполняет грубо говоря select for update, а потом удаляет записи.
30 сен 05, 21:45    [1929159] Ответить | Цитировать    Сообщить модератору

 Re: Write consistency by READ COMMITED isolation level   [new]
Петя Какашкин
Member [заблокирован]

Откуда: Засранец из сортира
Сообщений: 8
mcureenab
...

:)

Повеселил меня, засранца...
1 окт 05, 12:03    [1929641] Ответить | Цитировать    Сообщить модератору

Все форумы / Oracle Ответить
Generated time: 125ms.
Rambler's Top100 Powered by ActualForum 1.5.3 [s1] Copyright (c) Alex Sibilev 2000-2010