softwarer

Упоминание подзапроса здесь имхо не совсем к месту. Если это существенная часть Ваших рассуждений, подозреваю, Вы хотели рассказать не о мини-откатах, а о специфике read consistency в этом случае.


И от том и о другом.
Мне кажется вы передергиваете. ( Уверен, что понимаете о чем идет речь).

А речь в следующем:
ИХМО read consistency здесь причина, а миниоткат следствие.
Нельзя разделять эти вещи с точки зрения подержки цеслостности данных.
Мною были упомянуты следствия, вы указали на причины.
Все логично.


softwarer
В общем, суть получается такой: версионник плох тем, что в некоторых случаях ведет себя так же, как блокировочник ведет себя всегда :))


Не буду спорить с авторитетом сайта.
Пусть будет по Вашему.

softwarer мнениеМне кажется вы передергиваете. ( Уверен, что понимаете о чем идет речь).
Нет, не понимаю. Зато заинтригован и хотел бы увидеть разъяснение, в чем именно я некорректен.


softwarer
Упоминание подзапроса здесь имхо не совсем к месту. Если это существенная часть Ваших рассуждений, подозреваю, Вы хотели рассказать не о мини-откатах, а о специфике read consistency в этом случае.

мнение
И от том и о другом.


а именно :

мнение
ИХМО read consistency здесь причина, а миниоткат следствие.
Нельзя разделять эти вещи с точки зрения подержки цеслостности данных.
Мною были упомянуты следствия, вы указали на причины.
Все логично.

То что эти понятия (рестарт и read consistency)
находятся в тесной связи, у меня сомнений не вызывает.

Yo.! мнение
То что эти понятия (рестарт и read consistency)
находятся в тесной связи, у меня сомнений не вызывает.

я понимаю, что тему мнение не осилило :) но ниосилить даже заголовок - это круто
http://www.oracle.com/global/ru/oramag/dec2006/images/write_consistency.zip]Алгоритм “мини-откатов” в Oracle или еще раз о Write Consistency

Похоже что кроме заголовка Вы ничего осилили:

автор
Происходит это потому, что выполнение команды UPDATE состоит из двух фаз: 1) согласованное чтение ( consistent read ) таблицы на момент начала выполнения команды для нахождения строк, подлежащих модификации (в том числе удовлетворяющих предикату, если он задан); 2) чтение блоков данных таблицы в текущем (current read) режиме для модификации найденных на предыдущей фазе строк.
Поэтому все новые строки, которые были вставлены в таблицу другими сеансами после начала выполнения команды UPDATE, “не видны” во время первой фазы команды UPDATE даже несмотря на фиксацию (COMMIT) таких вставок. Но, как мы увидим позже, это уже не так, если производится “мини-откат” этих команд.

......


Кроме того, в этом тесте я ввел четвертый сеанс “New rows”, который вставляет новые строки в таблицу wc_test, которые удовлетворяют предикату тестируемой команды. Эти строки вставляются после начала команды UPDATE в сеансе “Long update”. Моя цель в этом случае – показать, что, во-первых, эти строки после “мини-отката” будут изменены сеансом “Long update”. Во-вторых, что блокировка строк сеансом “Long update” после “мини-отката”, вполне возможно, будет происходить неоднократно.




За ссылку спасибо, раньше этого документа не видел.

не важно softwarer мнениеТо что эти понятия (рестарт и read consistency)
находятся в тесной связи, у меня сомнений не вызывает.
Прошу прощения, уезжаю, отвечу через пару часов. Пока ограничусь констатацией того, что зря "не вызывает".Следует отметить, что здесь "мнение" право. Не было бы read consistency - не было бы и write consistency. тобы понять это, достаточно схоить по вышеуказанной ссылке и внимательно почитать. Также стоит отметить, что частично "мнение" не право, так как "рестарты" в Oracle контролируемы, правда для этого его придется делать "супер-блокировочником" :)


Супер блокировочники имеют уровни изоляции

dirty read
read commited
repeatable read
serializable

привильное их использование позволяет не делать рестартов и не грузить систему вовсе,
а просто ждать.
Что на 1000 комитах в секунду очень немаловажно.

Это было причиной ввести пункт 3 ( о поддержке сервером максимального количества уровней изоляции) в рекомендацию.


с уважением, мнение

мнение


Супер блокировочники имеют уровни изоляции

dirty read
read commited
repeatable read
serializable

привильное их использование позволяет не делать рестартов и не грузить систему вовсе,
а просто ждать.

Что на 1000 комитах в секунду очень немаловажно.

Это было причиной ввести пункт 3 ( о поддержке сервером максимального количества уровней изоляции) в рекомендацию.


с уважением, мнение

Дабы упредить последующие нападки со стороны религиозных фанатиков
выделенный текст следует читать :

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

Anton Demidov мнениепривильное их использование позволяет не делать рестартов и не грузить систему вовсе, а просто ждать на блокировке, установленной на необходимом для поддеражания логической целостности уровне изоляции.
Такое впечатление, что у вас сложилось чрезмерно негативное мнение о реальном влиянии мини-откатов на общую производительность системы.
Там, где блокировочник будет просто долго ждать, оракл с мини-откатами освободится быстрее от очереди. Обратите внимание на примеры в статье Сергея Маркеленкова - первой была длинная транзакция, потом было несколько конкурирующих с ней коротких. Короткие отработали первыми (без задержек), длинная транзакция ждала.
В классическом блокировочнике (которому вы так безрассудно преданы) все бы ждали выполнения длинной транзакции, только позавершению оной прошли бы те мелкие.
Так проще? Да. Вот только быстрее ли?

В чем вы меня пытаетесь убедить?
В том что Oracle в принципе удобнее, не спорю удобнее.

Суппер OLTP приложение написанной на блокировочнике с поддержкой всех уровней изоляции будет предсказуемее с точки зрения производительности, и мене затратно по железу.
При прочих равных.

Если говорить о длинных транзакциях вообще можете затронуть еще более веселую тему
(Заметьте не я это начал).
Консистентность на уровне транзакции, а не отдельного стейтмента.
И получите тот же супер-блокировочник снова, с одним уровнем изоляции serializable.
А потом начнутся доказательства того что dbms_lock лучше всех уровней изоляции вместе взятых.

Но это уже без меня.


з.ы. Со всеобщего позволения откланяюсь, дабы не розводить флейм , как просил автор топика.

с уважением, мнение.

з.ы.ы Похоже любое мнение является глупым , если оно не соответствует мнению пользователей Oracle.

Yo.! мнение

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


Похоже у Вас абсолютные проблемы с причинно следственной логикой.

С вашим стилем общения у меня нет ни малейшего желания высказывать какое либо мнение
и коментировать Ваш бред.

softwarer мнениеПохоже что кроме заголовка Вы ничего осилили:
Эта Ваша фраза и использованное Вами выделение убедили меня, что моей изначальной фразы (про связь read consistency и подзапросов) Вы просто не поняли. Ситуация упрощается, в частности, я убедился, что Ваше высказывание о передергивании вызвано исключительно недостаточным знанием.

не важноСледует отметить, что здесь "мнение" право. Не было бы read consistency - не было бы и write consistency.
Read consistency и write consistency - разные понятия. Чтобы проиллюстрировать это, достаточно вспомнить тот факт, что в блокировочнике выполнение select на уровне read committed не обеспечивает read consistency, однако этот режим активно используется и при адекватном подходе не разрушает базу (что было бы неизбежно при нарушении write consistency).

Разумеется, это связанные понятия - так же, как связаны вообще любые частные концепции в рамках одной реализации, одного решения общей задачи. Мини-откаты обеспечивают write consistency, однако с read consistency они связаны не более, чем с какой-либо другой из основных концепций.

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

Какими методами это достигается, зависит СУБД. Каждая имеет свои достоинства и недостатки.
Идеальных нет.

Если бы в требованиях не стояло 1000 транзакций в секунду, я бы остановился на oracle,
Без всяких намеков.

Давайте закончим это обсуждение.