Здравствуйте, PCherkasova, Вы писали:

PC>Я была неправа. На самом деле, для уровня snapshot все плохо. Потому что сериализуемость также нарушается, если обращаться к записи по индексированному уникальному ключу, а проверять и обновлять неиндексированное значение:
Совершенно верно. Пример-то конечно надуманный, но общий смысл отражает. Аномалия вылезает в том случае, если существует ограничение зависящие от нескольких переменных и разные транзакции пишут в разные переменные. В данном случае записи по которым считается сумма могли вообще находиться в разных таблицах и тогда никакое бы отсутствие индекса не спасло.
Другое дело, что для snapshot'а такое поведение совершенно нормально это просто особенность данного уровня изоляции, остальные IL допускают еще более любопытные эффекты.
С теориетической точки зрения гарантированную защиту от всех аномалий дает только Serializable уровень изоляции, но обычно это слишком дорогое удовольствие.

Что же касается наличия/отсутствия индекса, то это отдельная история. В данном случае Юконовский snapshot оказался даже строже чем "классический", который пропустил бы эту аномалию в любом случае, ни каким образом не оглядываясь на индексы.
И из-за этого мне вообще довольно смутно видится перспектива использования Юконовского snapshot'а для пишущих транзакций, так как оптимизатор может выбрать table scan даже при наличии индекса, а это автоматически приведет к конфликту и, как следствие, откату, в случае обновления любой записи в таблице во время работы транзакции, даже если обновленная запись никакого отношения к работе нашей snapshot транзакции не имеет.
Проблема в том, что при snapshot'е, в отсутствии индекса, сиквел видит конфликт версий там, где его на самом деле нет.