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

Откуда: город на Неве
Сообщений: 58
Вопрос проиллюстрирую на примере простой таблицы.
create table temp
(
id number,
id2 number
);
insert into t values (1);
Имеются две транзакции - T1 и T2, уровень изоляции read commited.
Транзакции делают следующее последовательно во времени.
1.Время TEMP1, транзакция T1
update temp set id=id+100;
2. Время TEMP2, транзакция T2:
update temp set id=(select t.id+1 from temp t where temp.id2=t.id2);
3. Время TEMP3, транзакция T1
commit;
4. Время TEMP4, транзакция T2
commit;
Значение поля id становится равным 2, то есть при update в T2 не учитываются изменения, сделанные в T1.
Второй случай - если update в T2 выглядит следующим образом:
update temp set id=(select t.id+1 t from temp where t.id=temp.id);
то значение поля id становится равным 102 то есть при update в T2 учитываются изменения T1.

Чтобы понять, что происходит, рассматривал следующее:
Oracle Database always enforces statement-level read consistency.
In the read committed isolation level, this point is the time at which the statement was opened.
The read committed transaction waits for the blocking transaction to end and release its row lock.
If the blocking transaction commits and releases its locks, then the waiting transaction proceeds with its intended update to the newly changed row.

Вопросы остались такие.
1. Верно ли, что подзапрос внутри update выполняется в момент TEMP2, то есть в момент запуска оператора update?
Этим обусловлено то, что в первом случае не учитываются изменения транзакции T1.
2. Почему во втором случае учитываются изменения, внесенные в T1? Ведь select подзапроса также как и в первом случае не блокирован первой транзакцией и читает "старые" данные в момент TEMP2. Или же после коммита транзакции T1 Oracle видит, что изменился temp.id и делает повторный связанный подзапрос? Если так - где про это можно почитать подробнее, в документации не нашел.
---
Oracle демотиватор
12 дек 10, 23:28    [9926494]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
nikonian
Member

Откуда: город на Неве
Сообщений: 58
Очепятался, во втором случае запрос конечно такой:
update temp set id=(select t.id+1 from temp t where t.id=temp.id);
12 дек 10, 23:29    [9926498]     Ответить | Цитировать Сообщить модератору
 Место встречи изменить нельзя  [new]
-2-
Member

Откуда:
Сообщений: 15330
nikonian,

к вопросу о задачках для собеседования
12 дек 10, 23:32    [9926508]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
nikonian
Member

Откуда: город на Неве
Сообщений: 58
Спасибо, я читал уже эту тему. Там упоминается "рестарт", но Nikotin_ вот здесь - 9883078 - говорит о том, что рестарт не причем. Поэтому эти вопросы и возникли и именно в такой формулировке. Потому как я не понял:)
13 дек 10, 00:23    [9926630]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
_Nikotin
Member

Откуда: СПб
Сообщений: 2965
nikonian,

вот тут рестарта нет, потому что так оно работает :)
update temp set id=id+100;

тут рестарта нет, потому что нигде нет ссылок на temp.id внутри подзапроса
update temp set id=(select t.id+1 from temp t where temp.id2=t.id2);

а здесь есть, потому что есть ссылка
update temp set id=(select t.id+1 t from temp where t.id=temp.id);
13 дек 10, 00:29    [9926637]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
nikonian
Member

Откуда: город на Неве
Сообщений: 58
Danke!
Nikotin_, а правильно я понимаю, что подзапрос выполняется именно в момент запуска update (несмотря на блокировку строк, на которую update сразу наткнется)?
В мануале Вы где-нибудь находили описание рестарта (при каких условиях и как он происходит)?
13 дек 10, 00:52    [9926687]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
Bfink
Member

Откуда: Москва
Сообщений: 2797
nikonian
подзапрос выполняется именно в момент запуска update (несмотря на блокировку строк, на которую update сразу наткнется)?


вопрос не в том, когда он выполняется, а в том, на какой момент он читает данные
13 дек 10, 00:56    [9926694]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
_Nikotin
Member

Откуда: СПб
Сообщений: 2965
nikonian
Nikotin_, а правильно я понимаю, что подзапрос выполняется именно в момент запуска update (несмотря на блокировку строк, на которую update сразу наткнется)?

Любой запрос должен получать согласованные данные на момент запуска. То что id "видит" данные, закомиченные после старта, это такая особенность поведения oracle в данной ситуации, расходящаяся с принципами ACID.
13 дек 10, 01:01    [9926703]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
_Nikotin
Member

Откуда: СПб
Сообщений: 2965
_Nikotin
То что id "видит" данные, закомиченные после старта, это такая особенность поведения oracle в данной ситуации, расходящаяся с принципами ACID.

Имеется в виду id в правой части set. Видит и не инициирует перзапуск.
13 дек 10, 01:02    [9926704]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18363
_Nikotin
Любой запрос должен получать согласованные данные на момент запуска.

Правильнее сказать - данные должны быть согласованы на некоторую точку времени между запуском и завершением statement. Эта точка - совсем не обязательно "момент запуска".
13 дек 10, 01:07    [9926707]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
_Nikotin
Member

Откуда: СПб
Сообщений: 2965
andrey_anonymous
Правильнее сказать - данные должны быть согласованы на некоторую точку времени между запуском и завершением statement. Эта точка - совсем не обязательно "момент запуска".

С момента запуска ещё многое может произойти, запрос должен дойти до оракла, распарсится в конце концов. Так что согласен.
13 дек 10, 01:14    [9926715]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18363
_Nikotin
С момента запуска ещё многое может произойти, запрос должен дойти до оракла, распарсится в конце концов. Так что согласен.

Ок, уточню. Точка согласования - между началом и завершением фазы execute.
Думаю, продемонстрировать Вы и сами при желании сможете.
13 дек 10, 01:17    [9926719]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
Bfink
Member

Откуда: Москва
Сообщений: 2797
andrey_anonymous
_Nikotin
Любой запрос должен получать согласованные данные на момент запуска.

Правильнее сказать - данные должны быть согласованы на некоторую точку времени между запуском и завершением statement. Эта точка - совсем не обязательно "момент запуска".


а можно поподробнее? Что имеется в виду под statement? Подзапрос или весь Update? Касается это всех подзапросов в Update или только некоторых? Если в update несколько подзапросов, они согласовывают данные все на одно и то же время или на разное? Ну, и наконец, что происходит при распределенной транзакции, когда время свое на каждом из серверов?
13 дек 10, 01:19    [9926722]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
_Nikotin
Member

Откуда: СПб
Сообщений: 2965
Bfink
Ну, и наконец, что происходит при распределенной транзакции, когда время свое на каждом из серверов?

Ну так Синхронизация SCN на ВBLINKнутых базах
13 дек 10, 01:22    [9926727]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
nikonian
Member

Откуда: город на Неве
Сообщений: 58
_Nikotin
То что id "видит" данные

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

_Nikotin
Имеется в виду id в правой части set. Видит и не инициирует перзапуск.

А как определить, когда инициирует, а когда нет?
И опять же, в доке есть про это:)?
13 дек 10, 01:24    [9926732]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
_Nikotin
Member

Откуда: СПб
Сообщений: 2965
nikonian
А как определить, когда инициирует, а когда нет?
И опять же, в доке есть про это:)?

А Вы в первой транзакции ещё вставьте что-нибудь помимо update, если перезапуск - увидит, если не было - не увидит. И ещё посмотрите сколько раз запустится триггер before statement
13 дек 10, 01:27    [9926738]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
Bfink
Member

Откуда: Москва
Сообщений: 2797
_Nikotin
Bfink
Ну, и наконец, что происходит при распределенной транзакции, когда время свое на каждом из серверов?

Ну так Синхронизация SCN на ВBLINKнутых базах


это касается согласования на начало транзакции, здесь же нам предлагают согласование на произвольный момент
13 дек 10, 01:29    [9926742]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
suPPLer
Member

Откуда: Харків, Україна
Сообщений: 7794
Блог
nikonian
_Nikotin
Имеется в виду id в правой части set. Видит и не инициирует перзапуск.

А как определить, когда инициирует, а когда нет?
И опять же, в доке есть про это:)?


nikonian
Спасибо, я читал уже эту тему. Там упоминается "рестарт", но Nikotin_ вот здесь - 9883078 - говорит о том, что рестарт не причем. Поэтому эти вопросы и возникли и именно в такой формулировке. Потому как я не понял:)


Непохоже, что читали, раз остаются такие вопросы.

PS: Из тем, связанных с тематикой Write Consistency, на SQL.RU Oracle редко какая заканчивалась хотя бы на второй странице... Интересно, станет ли эта исключением?
13 дек 10, 01:41    [9926750]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18363
Bfink
это касается согласования на начало транзакции, здесь же нам предлагают согласование на произвольный момент

1) не на произвольный. На некоторый.
2) "согласование на начало транзакции" на уровне изоляции read commited - частный случай.
3) в чем, на Ваш взгляд, принципиальная разница между "на начало" и "на некоторый момент" кроме невозможности получить согласованный набор при первой формулировке?
4) показать как данные согласуются на момент, отличный от запуска statement, проблемы не представляет и это делалось уже многократно. Не вижу темы для дискуссии.
13 дек 10, 01:53    [9926762]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
сосед-акцессник
Guest
andrey_anonymous
Bfink
это касается согласования на начало транзакции, здесь же нам предлагают согласование на произвольный момент

1) не на произвольный. На некоторый.
2) "согласование на начало транзакции" на уровне изоляции read commited - частный случай.
3) в чем, на Ваш взгляд, принципиальная разница между "на начало" и "на некоторый момент" кроме невозможности получить согласованный набор при первой формулировке?
4) показать как данные согласуются на момент, отличный от запуска statement, проблемы не представляет и это делалось уже многократно. Не вижу темы для дискуссии.


ремарка:
2) с каких это пор и с какого такого "вдруг" уровень изоляции read-commited в Oracle стал обеспечивать "согласование на начало транзакции"?

к сожалению, остальные пункты я затрудняюсь перевести на русский язык.

_Nikotin
То что id "видит" данные, закомиченные после старта, это такая особенность поведения oracle в данной ситуации, расходящаяся с принципами ACID

Пока речь идет об уровне изоляции read-commited ни наличие рестарта ни его отсутствие не противоречит "принципам ACID".
(Которые Дейт вообще предлагает считать блажью) .
"принципы ACID" требуют, чтобы одна транзакция не видела незафиксированных операций другой. Это в любом случае обеспечено.
В данном случае речь идет о некотрой "сверхасидной" правильности - неточно говоря - результат выполнения двух "похожих" операций на одном и том же наборе данных не должен зависеть от последовательности транзаций.

На мой вкус, наиболее толковое мнение по этому поводу на текущий момент высказал S.Y. в предшествующем топике.
13 дек 10, 03:33    [9926812]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
nikonian
Member

Откуда: город на Неве
Сообщений: 58
suPPLer
nikonian
пропущено...
А как определить, когда инициирует, а когда нет?
И опять же, в доке есть про это:)?

Непохоже, что читали, раз остаются такие вопросы.

Видимо, я непонятно сформулировал вопрос. Имелось в виду не "как посмотреть, был ли рестарт" (то о чем писал Nikotin_), а по каким признакам в самом запросе/сопутствующих структурах этот рестарт определить, то есть просто посмотрев на них глазками.
Попытаюсь сформулировать:
1. рестарт происходит, если в связанном подзапросе упоминаются столбцы обновляемой таблицы (из конструкции update <tab>), которые были затронуты первой транзакцией
2. рестарт происходит, если в row-level триггере упомянута ссылка на :old-версию столбцов, которые затронуты первой транзакцией, даже если это просто put_line
3. рестарт происходит, если во второй транзакции используется update <tab> set id=id+1 where id=1, и при этом в первой транзакции значение id этой строки реально изменялось (не set id=id+0)
4. - ???
Вот эти ??? интересны, особенно при наличии сЦылок на мануал. Дополнения в knowledge base никогда лишними не бывают:)
13 дек 10, 12:48    [9928471]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
SomeOraGuest
Guest
nikonian,

поищите на форуме по фразе "Write Consistency". В числе прочих полезностей найдете и вот эту ссылку.
13 дек 10, 13:00    [9928580]     Ответить | Цитировать Сообщить модератору
 Re: Согласованные данные для подзапроса в update при конкурентном доступе  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 18363
сосед-акцессник
andrey_anonymous
пропущено...
2) "согласование на начало транзакции" на уровне изоляции read commited - частный случай.

2) с каких это пор и с какого такого "вдруг" уровень изоляции read-commited в Oracle стал обеспечивать "согласование на начало транзакции"?

В частном случае - если транзакция содержит единственный sql-statement и рестарта не происходит, то данные будут согласованы на начало транзакции :)

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

Неверно.
Результат параллельного выполнения двух statements должен соответствовать результату хоть какой-нибудь последовательности их выполнения.

2ТС: в топике, на который Вам дали ссылку, как и в прочих дискуссиях относительно write consistency, есть ссылки на статью Маркеленкова, посвязенную данному вопросу. Обязательно ознакомьтесь лично, а не через вольный пересказ коллег.
13 дек 10, 14:17    [9929298]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить