Yo.!! onstat-
Позвольне несогласиться.
Приведенный Андреем пример полностью противоречит
следующим строчкам стандарта:

тогда вам прийдется не согласится за одно с IBM, Microsoft, HP и прочими членами tpc council. ;) откройте любой их отчет они все пишут что оракловый serializable полностью удолетворяет стандарту 92. там буквально абзацем ниже дается дефениция всем уровням изолированости через феномены
The isolation level specifies the kind of phenomena that can occur during the execution of concurrent SQL-transactions.

Я не вижу противоречий между приведенной Вами цитатой и
стандартом.
SQL92
The four isolation levels guarantee that each SQL-transaction will
be executed completely or not at all, and that no updates will be
lost. The isolation levels are different with respect to phenomena
P1, P2, and P3. Table 9, "SQL-transaction isolation levels and the
three phenomena" specifies the phenomena that are possible and not
possible for a given isolation level.


Разница только в том, что цитата говорит о каких-то абстрактных типах феноменов которые могут быть в принципе,
А стандарт описывает правила поведения для уровней изоляции
для конкретных феноменов.

з.ы. В подтверждение Ваших слов, пожалуста, потрудитесь привести более точную цитату и ссылку.
Мне некогда искать tpc репорты, которым лично я не доверяю,
потому что в этих репортах ничего рекламы не вижу.
Что бы проверить их прадивость, нужно потратить миниум сумму с 5-ью нулями
для каждого репотра.

Yo.!!
надеюсь за мои труды мне воздастся ;)


Спасибо, будет у нас в Днепропетровске, сообщите в личку.
Пива выпьем ;)

Yo.!!
Fujitsu: http://tpc.org/results/FDR/TPCC/fujitsu_primequest480_tpcc_fdr.pdf
HP: http://tpc.org/results/FDR/TPCC/tpcc.hp.rx6600.fdr.pdf

fujitsu_primequest480_tpcc_fdr.pdf
Serializable Transactions:
Oracle supports serializable transaction isolation in full compliance with the SQL92 and
TPC-C requirements. This is implemented by extending multiple concurrency control
mechanisms long supported by Oracle.
.......
Oracle implements SERIALIZABLE mode by extending the scope of read consistency
from individual query to the entire transaction itself . ALL reads by serializable
transactions are therefore repeatable, as the transaction will access prior versions of data
changed (or deleted) by other transactions after the start of serializable transactions.
Thus, a serializable transaction sees a fixed snapshot of the database, established at the
beginning of the transaction.


Еще раз спасибо, за подтверждение.

Суть в выделенных словах и главное из них itself .
Как много смысла может поменять одно слово из 6 букв:(

andrey_anonymous onstat- fujitsu_primequest480_tpcc_fdr.pdf
Serializable Transactions:
Oracle supports serializable transaction isolation in full compliance with the SQL92 and
TPC-C requirements. This is implemented by extending multiple concurrency control
mechanisms long supported by Oracle.
.......
Oracle implements SERIALIZABLE mode by extending the scope of read consistency
from individual query to the entire transaction itself . ALL reads by serializable
transactions are therefore repeatable, as the transaction will access prior versions of data
changed (or deleted) by other transactions after the start of serializable transactions.
Thus, a serializable transaction sees a fixed snapshot of the database, established at the
beginning of the transaction.

Суть в выделенных словах и главное из них itself .
Как много смысла может поменять одно слово из 6 букв:(
Простите, а что конкретно изменило слово "itself" применительно к процитированному тексту?

Постараюсь расставить точки над Ё :)

ИХМО 1. itself озанчает, что serializable
действителен только внутри транзакции, где конкуренции и так нет.

ИХМО 2. Если смотреть на стандарт, то это не full compliance

Нонсенс какойто, точки противоречат.
А первая еще и вносит неясность с понятием serializable из-за itself
усилинным словом entire .


зы Хорошая игра слов однако. Или у меня плохо с Английским?

softwarer
onstat-ИХМО 1. itself озанчает, что serializable
действителен только внутри транзакции
Это слово относится к read consistency, а не к serializable, и в сумме получается примерно так: "распространением согласованности чтения на уровень транзакции в целом, не более и не менее" [entire и itself задают две границы, снизу и сверху].



ИХМО itself относится к транзакции в целом, которая работает в serializable mode.

Oracle обеспечивает serializable mode как расширение области видимости
конкретного консистентного запроса ко всей транзакции в целом.

Не знаю что они хотели этим сказать.

и далее


Thus, a serializable transaction sees a fixed snapshot of the database, established at the
beginning of the transaction.


serializable transaction видит фиксированный моментальный снимок(я специально перевел shapshot)базы данных устновленный на начало транзакции.

То есть берем данные на начало транзакции, предикаты не блокируем
(потому, что снапшот), вносим изменения в базу данных
на основании данных из снапшота, не учитывая закомиченых
транзакций из других сессий после старта нашей serializable транзакции.

Теперь я не понимаю чем этот serializable отличается от RC.

softwarer
onstat-ИХМО 2. Если смотреть на стандарт, то это не full compliance
Имхо, конечно, может быть любым, но в данном случае существует общепринятое мнение, выработанное по сути авторами стандарта, и спорить относительно формы вряд ли осмысленно.

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

Полностью поддерживаю.

andrey_anonymous onstat-ИХМО itself относится к транзакции в целом, которая работает в serializable mode.
Oracle обеспечивает serializable mode как расширение области видимости
конкретного консистентного запроса ко всей транзакции в целом.
Не знаю что они хотели этим сказать.

То, что в транзакции может содержаться более одного запроса. Соответственно, в serializable oracle обеспечивает согласованное чтение не только отдельно взятого statement, но всей транзакции целиком.


Понял, спасибо, Я под запросом понимал не только чтение.


andrey_anonymous
onstat-
Thus, a serializable transaction sees a fixed snapshot of the database, established at the beginning of the transaction.
То есть берем данные на начало транзакции, предикаты не блокируем
(потому, что снапшот), вносим изменения в базу данных на основании данных из снапшота, не учитывая закомиченых транзакций из других сессий после старта нашей serializable транзакции.
Теперь я не понимаю чем этот serializable отличается от RC.
:) Как чувствовал - не надо было этот пример сюда постить, теперь начались грязные инсинуации :)
Господа, отсутствие ограничений целостности и операция insert в приведенной иллюстрации - далеко не случайность , без должной подготовки обобщать не следует .


Никакого злого умысла я не предполагал.
Прошу прощения.

С уважением, onstat-

Anton Demidov softwarerВ данном случае такое понимание вполне корректно. Операторы MERGE, UPDATE и DELETE также читают данные, и к ним применимо понятие read consistency.
Не совсем верно - они читают только current mode - т.е. текущее значение, которое и можно изменить. Consistent read - это snapshot на какой-то момент времени - его не меняют - это состояние в прошлом.

ИХМО.
Для update данные берутся из снапшота,
при попытке изменения проверятется слот транзакции, если в слоте содержится SCN транзакции которая закомичена после начала
текущей то сессия вылетает по исключению ORA-08177.

А если конкурирующая транзакция не закомичена, то и подавно,
правда может быть исключение ORA-00054.

andrey_anonymous onstat-при попытке изменения проверятется слот транзакции, если в слоте содержится SCN транзакции которая закомичена после начала
текущей то сессия вылетает по исключению ORA-08177.
Только в serializable.
В RC может либо рестартовать statement, либо взять "как есть" в зависимости от характера изменений, проведенных транзакцией-конкурентом. onstat-
А если конкурирующая транзакция не закомичена, то и подавно,
правда может быть исключение ORA-00054.
Нет. update в принципе не способен генерировать ora-54, поэтому просто будет ждать освобождения блокировки.


Давайте пока остановимся только на serializable. Что бы не путаться
что за чем и когда происходит.

Если он будет ждать освобождения, а потом выполнит изменение,
то будет нарушена целостность данных с точки зрения serailizable.
Чтение консистентно на момент времени в прошлом,
а изменение не учитывает закомиченные транзакции
после старта serailizable транзакции.
Я об этом уже писал.

ИХМО
В serializable он ждать не имеет права.
Либо должен брать информацию не из снапшота.

Как сервер ведет себя в действительности я не знаю.

andrey_anonymous onstat-Как сервер ведет себя в действительности я не знаю.
Ждет завершения конкурирующей транзакции.
Блокирует строку.
Анализирует характер изменений.
Если изменения несовместимы - откат statement.

Где об этом можно почитать?