Моя фраза состояла из 4 предложений. Обычно в русском языке в сложном предложении логической связью объединены именно соседние предложения. То есть, последнее подчиненное предложение «но ANSI SQL 92 не вводит такого понятия», очевидно, относится к предыдущему предложению «у людей зовется Snapshot».

Спасибо за уточнение. Если имелось в виду именно это, то уровня изоляции snapshot в ISO SQL действительно нет. Но я как-то не ожидал, что вы считаете, что Oracle по умолчанию позволено переопределять общепринятые понятия, и винить его в этом никто не может.

Вернёмся к этой цитате:

То, что использует Oracle под названием Serializable, у людей зовется Snapshot, но ANSI SQL 92 не вводит такого понятия. Да, оракл слукавил, но я не могу его винить в том, что ANSI принял двусмысленное определение уровней изоляции и не отделил изоляцию от сериализации.

Так вот:

Oracle не «слукавил», а грубо нарушает стандарт, да ещё и нагло лжёт, что это не так, в своей документации.

Винить его в вышеуказанном вполне можно – когда вам, к примеру, обещали поставить розы, а привезли одуванчики, и настаивают на том, что это нормально, потому что в их накладных (или где-то ещё) одуванчики называются розами, это мошенничество (IMHO).

ANSI, допустим (хотя это тоже ещё вопрос – как вы думаете, почему, несмотря на выход той статьи, на которую тут ссылались, стандартизаторы во всём этом разделе с тех пор ничего существенно не изменили?), принял несколько двусмысленные определения некоторых уровней изоляции, вот только к обсуждаемому «то, что использует Oracle под названием Serializable» это никак не относится – его определние однозначно.

и не отделил изоляцию от сериализации

Было бы странно, если бы отделил, т.к. классическое определении изоляции транзакций – это сериализуемость.

Уровни изоляции (кроме Serializable) – это возможности нарушения свойства «I» из ACID (для получения каких-то преимуществ). Т.е. транзакции становятся не [полностью] изолированными.

Стандарт обязывает каждую СУБД, которая утверждает, что соответствует ему в этой части, реализовывать Serializable, и именно с такими свойствами, как указано в стандарте (цитату я приводил).

Кстати, реализация других уровней (и даже, кажется, их наличие) не является обязательной, и к примеру, в PostgreSQL RU=RC, а в sqlite и вовсе (при стандартных настройках) RU=RC=RR=S (т.е. любой уровень ведёт себя точно так же, как и Serializable), и это полностью соответствует стандарту.

Oracle не «слукавил», а грубо нарушает стандарт, да ещё и нагло лжёт, что это не так, в своей документации.

Назвиздел - бывает:
https://docs.oracle.com/cd/B28359_01/server.111/b28318/consist.htm#CNCPT020
Справедливости ради, нужно отметить, что все-таки эффект serializable транзакции можно получить в оракле - просто нет такого режима транзакции, а вместо режима нужно писать select... for update.

Винить его в вышеуказанном вполне можно – когда вам, к примеру, обещали поставить розы, а привезли одуванчики, и настаивают на том, что это нормально, потому что в их накладных (или где-то ещё) одуванчики называются розами, это мошенничество (IMHO).

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

как вы думаете, почему, несмотря на выход той статьи, на которую тут ссылались, стандартизаторы во всём этом разделе с тех пор ничего существенно не изменили?

Стандартизаторы, как правило - это отбитые наглухо люди, которые протирают штаны и высирают макулатуру. Вот прямо как на моей нынешней работе, где отдельные кадры могут по часу обсуждать вопрос того, нужно ли добавить опцию выбора курсивного шрифта в настройках - и это на фоне пропущенных сроков релиза и куче нерешенных фундаментальных проблем.
Почему комитет не мог переделать стандарт? Маркетинг же ж. Вот представь: ты садишься протирать штаны вместо ушедшего на пенсию предшественника, смотришь на его дела, а там - полный ад и угар. Что делать? Говорить «предыдущая комиссия обкакунькалась, мы сделаем всё заново и правильно»? Пардон, но чем твоя комиссия отличается? Может это ты обкакунькаешься, а предыдущая сделала всё правильно? Этот вопрос возникнет у людей извне - а ты поди еще что-то докажи другим членам, которые две недели будут спорить о том, должно ли ключевое слово писаться заглавными или прописными буквами. Предыдущий стандарт стоил многих дюжин протёртых штанов - он не мог быть ошибочным.

Было бы странно, если бы отделил, т.к. классическое определении изоляции транзакций – это сериализуемость.

И тут ты такой приводишь определение изоляции до 1992 года.

в sqlite и вовсе (при стандартных настройках) RU=RC=RR=S (т.е. любой уровень ведёт себя точно так же, как и Serializable), и это полностью соответствует стандарту.

Уже нет. Сделали WAL, независимую запись-чтение, изоляцию, и прочее.

Справедливости ради, нужно отметить, что все-таки эффект serializable транзакции можно получить в оракле - просто нет такого режима транзакции, а вместо режима нужно писать select… for update.

Нет, нельзя – этого и близко не достаточно. В простейшей демнострации write skew вообще используются только UPDATE (которые можно так же заменить и на 1) SELECT … FOR UPDATE + 2) UPDATE выбранного), и это никак не поможет. В общем, никакого «простого» и «общего» практического подхода для реализации надёжной изоляции транзакций на основе того, что даёт Oracle, нет – есть максимум набор приёмов, которые чаще всего срабатывают (а иногда нет, и… «у нас тут где-то пропало 1234567$… как?! когда?!»).

Все коммерсы занимаются мошенничеством - это совершенно нормально.

Как считают некоторые, но не я. Опять-таки, какое отношение это имеет к технической дискуссии (и вообще, мне кажется, всё это ушло далеко от темы)?

Оракл это сделал достаточно тонко - никакой суд никаких проблем не найдет.

Найдёт, если захочет.

Стандартизаторы, как правило - это отбитые наглухо люди, которые протирают штаны и высирают макулатуру.

Внезапно, по отношению к авторам ISO SQL это, во многом, верно. Но к этому случаю (и некоторым другим – стандарт принёс существенную пользу для некоторых «частей» языка SQL), это возможно, и не относится.

Почему комитет не мог переделать стандарт? Маркетинг же ж.

А у меня есть другой вариант – они по-прежнему считают своё описание правильным, и про себя думают про тех, кто написал эту статью: «эти дебилы прочитали 5 страниц нашего текста, судя по всему, раз десять… и всё равно ни хрена не поняли – какой толк тратить время на то, чтобы им вообще что-то объяснять?! Они же и объяснений-то не поймут!».

И тут ты такой приводишь определение изоляции до 1992 года.

И тут вы такой открываете определение из любого современного учебника… и с ужасом убеждаетесь, что оно всё такое же.

Уже нет. Сделали WAL, независимую запись-чтение, изоляцию, и прочее.

Изоляция там и так была. Как был один writer, так и остался. Насколько я помню, без pragmas отношение к уровням изоляции точно такое же. Если есть чем опровергнуть – давайте ссылку.

А вообще, вернулись бы вы к теме. Что, воспроизводимые тесты так и не нашлись?

Нет, нельзя – этого и близко не достаточно. В простейшей демнострации write skew вообще используются только UPDATE (которые можно так же заменить и на 1) SELECT … FOR UPDATE + 2) UPDATE выбранного), и это никак не поможет.

Напомню статью для мимопроходящих, на всякий случай: A Critique of ANSI SQL Isolation Levels
Как это не поможет? Тебе нужно устранить тупо это самое write skew, то есть, условие логической связанности, целостности для группы кортежей после выполнения транзакции. Проблема snapshot-а заключается в том, что он читает старые, а пишет новые данные. Блокируя читаемые данные, snapshot гарантирует, что они не будут изменены и взаимосвязанность не нарушится - всё, ты получил свой serializable по ANSI.

Как считают некоторые, но не я. Опять-таки, какое отношение это имеет к технической дискуссии (и вообще, мне кажется, всё это ушло далеко от темы)?

Если бы ты действительно был недоволен обманом коммерсов, то давно бы уже к этому привык и выработал бы какую-то позицию, как это сделал я. Но ты удивляешься, как малое дитя «что? Обманули? Нечестно! Надо разоблачить!».

А у меня есть другой вариант – они по-прежнему считают своё описание правильным, и про себя думают про тех, кто написал эту статью: «эти дебилы прочитали 5 страниц нашего текста, судя по всему, раз десять… и всё равно ни хрена не поняли – какой толк тратить время на то, чтобы им вообще что-то объяснять?! Они же и объяснений-то не поймут!».

Не угадал. Никто вообще не читает стандарты. Частенько текст этих стандартов простому смертному непросто достать.

И тут вы такой открываете определение из любого современного учебника… и с ужасом убеждаетесь, что оно всё такое же.

Миллион мух не может ошибаться. ТЫ пробовал когда-нибудь интеерсоваться тем, кто пишет учебники?

Как это не поможет?

Вот так. Возьмите https://wiki.postgresql.org/wiki/SSI#Simple_Write_Skew и попробуйте в своём прекрасном Oracle, наконец.

Проблема snapshot-а заключается в том, что он читает старые, а пишет новые данные.

Нет, проблема snapshot заключается в том, что даже с FOR UPDATE на те данные, которые не читаются (или же вовсе не существуют в данном снимке), никаких блокировок, естественно, не накладывается.

Блокируя читаемые данные, snapshot гарантирует, что они не будут изменены и взаимосвязанность не нарушится - всё, ты получил свой serializable по ANSI.

Т.е. в вопросе вы пока не разбираетесь. Откроете вы наконец учебник или нет, а? Мне уже как-то надоедает его «зачитывать вслух».

Если бы ты действительно был недоволен обманом коммерсов, то давно бы уже к этому привык и выработал бы какую-то позицию, как это сделал я. Но ты удивляешься, как малое дитя «что? Обманули? Нечестно!

Я к этому привык и выработал какую-то позицию. А ещё я, к примеру, привык к тому, что существуют убийцы-маньяки, и не «удивляюсь, как малое дитя».

Надо разоблачить!».

Про Oracle – это довольно известный (среди database developers) факт… и что?

Не угадал.

Вам-то откуда знать, угадал я или нет? В этом комитете заседаете? Или по «секретным документам»?

Никто вообще не читает стандарты.

Отучитесь говорить за всех.

Частенько текст этих стандартов простому смертному непросто достать.

Что касается ISO SQL – в сети общедоступны drafts (которые почти 1:1 с официальными документами), от SQL92 до SQL2011.

Миллион мух не может ошибаться.

Учебники, как раз, пишут не «мухи». «Мухи» их не читают.

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

Да. И большинство из них – известные computer scientists. Хотите предложить почитать что-то от альтернативных «учёных»?

Как внутри устроен Oracle знают только программисты Oracle

4.2 Сообщения, содержащие вызывающе неверную … информацию

Судя по багам, ничего такого они не знают:)

Вот так. Возьмите https://wiki.postgresql.org/wiki/SSI#Simple_Write_Skew и попробуйте в своём прекрасном Oracle, наконец.

Сорян, без меня. У меня сейчас оффтоп основная, там оракель попрыщавее любой СУБД будет, а в виртуалку ставить тоже ни разу не весело. Придется на пальцах, или кто-то из вас поставит и будет тестить выполнение.

Проблема snapshot-а заключается в том, что он читает старые, а пишет новые данные.

Нет, проблема snapshot заключается в том, что даже с FOR UPDATE на те данные, которые не читаются (или же вовсе не существуют в данном снимке), никаких блокировок, естественно, не накладывается.

Во-первых, всегда есть вариант «LOCK TABLE... IN SHARE ROW EXCLUSIVE MODE», если прям уж совсем досконально нужно поддерживать взаимоотношения между записями в таблице. Во-вторых, какая разница, как меняются независимые наборы кортежей? Чтобы контролировать их взаимосвязь, должна быть транзакция, читающая связанные данные, но такой транзакции у нас нет - так о чем разговор? Это я про «те данные, которые не читаются (или же вовсе не существуют в данном снимке)».

Про Oracle – это довольно известный (среди database developers) факт… и что?

Ну прямо тут есть люди, которые пишут, например, «крайне занимательная статейка для тех, кто считает что оракл покупают только ради откатов и возможности указать пальцем».

Вам-то откуда знать, угадал я или нет? В этом комитете заседаете? Или по «секретным документам»?

А я просто знакомлюсь с их трудами. Слыхал про стандарт, где комитет позаседал-позаседал, и решил между 32 бита и 64 бита выбрать размер данных 48 бит? С++, ALGOL-68 - вот еще одни жертвы комитетов.

Что касается ISO SQL – в сети общедоступны drafts (которые почти 1:1 с официальными документами), от SQL92 до SQL2011

Это очень хорошо. Интернет-протоколы еще общедоступны. Но есть куча стандартов, за которые просят денежку.

Учебники, как раз, пишут не «мухи». «Мухи» их не читают.

Учебник, который никто не покупал и не читал, ты сам не будешь читать. Ты следуешь именно за мухами, а не за авторами.

Про Oracle – это довольно известный (среди database developers) факт… и что?

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

Придется на пальцах, или кто-то из вас поставит и будет тестить выполнение.

Ну так прочитайте, по ссылке же подробное объяснение (опять-таки, это «классический» пример, его можно найти в десятках мест, для разных СУБД).

Во-первых, всегда есть вариант

Во-первых, всегда есть вариант прочитать, наконец, хоть что-то (для ясности: то, что вы написали – неверно)!

Во-вторых, мне надоело вам разжёвывать тут «букварь», с меня хватит.

Ссылки были даны, sapienti sat.

Ну прямо тут есть люди, которые пишут, например, «крайне занимательная статейка для тех, кто считает что оракл покупают только ради откатов и возможности указать пальцем».

Что касается «прямо тут» – на LOR специалистов по СУБД мало (но это только моё впечатление по воспоминаниям об их обсуждениях здесь).

Но есть куча стандартов, за которые просят денежку.

За стандарт SQL тоже просят, и даже общедоступного draft SQL:2016, насколько я помню, нет.

Ты следуешь именно за мухами, а не за авторами.

Вы тиражи / стоимости этих учебников видели? Смешно даже сравнивать с трудозатратами на них (т.е. редко кому из авторов это не в убыток). Что покупают и читают «мухи» – думаю, очевидно.

это довольно известный факт среди дегенератов неосиливших доки.

Доки Oracle тут ни при чём, дегенерат. Почитай thread… ах да, о чём это я – ты же умеешь только «накатывать», очевидно.