Можно выделить следующие моменты :

1. В Yukon используется принципиально другая система хранения версионных данных. Вместо сегментов отката применяется системная база TempDB. В
результате не может появиться ошибка типа ORA-01555 snapshot too old, так как данные отката не затираются новыми данными, как это происходит в
Оракл.

2. Так как информация о блокировках в Оракл расположена в специальной системной области блока, то если количество транзакций накладывающих
блокировки превысит значение MAXTRANS, то новая транзакция окажется заблокированной, так как для нее просто не хватит слотов.

3. По причине отсутствия в Оракл менеджера блокировок, сервер никогда не прибегает к эсколации блокировок. И хотя для Оракл данная проблема
имеет меньшее значение, чем для Yukon (в связи с тем, что информация о блокировках в Оракл храниться непосредственно в блоках данных, то не
требуется выделять дополнительное место для хранения такой информации, память под блокировку выделена сразу при создании блока), тем не менее
эскалация нужна в определенных ситуациях и ему. В ситуациях, когда множество транзакций сражаются между собой за право наложения блокировок, возникает так называемый "data contention". В этих ситуациях для повышения производительности следует эскалировать блокировки.
Кроме того, существует также граф блокировок, который отвечает за разрешение deadlock ситуаций, и ресурсы на поддержку и анализ этого графа
напрямую зависят от числа блокировок. В любом случае, в Оракл надо производить еще и очистку блоков от установленных старыми транзакциями
блокировок.

4. Наконец, в Yukon версионностью можно просто не пользоваться. Данная возможность включается и отключается на уровне базы данных, что очень
удобно. Для задач, которым нужна версионность, можно использовать версионность, там где лучше блокировочный подход - можно работать без всякой версионности. Более того, ее можно включать/отключать для одной и той-же базы в разное время, и делать это можно как с помощью клиентских
приложений, так и напрямую на сервере, не внося никаких изменений в клиентов. То есть например, днем работаем в блокировочном режиме, вечером, когда нагрузка спадает, включаем версионность и запускаем тяжелые отчеты. Интересно также то, что при включенной версионности любую транзакцию все равно можно запустить в блокировочном режиме, указав соответствующий хинт.
Версионный подход лучше использовать в ситуациях, когда преобладают операции чтения, так как не возникает блокировок писателей, а блокировочный - когда преобладают операции записи, так как в версионнике писатели все равно висят на блокировках, ожидая друг друга, но при этом еще и плодят массу версий, которые никто не собирается читать. Если-же включить уровень serializable (в Yukon называется snapshot), то ситуация становиться еще тоскливее, так как теперь вместо того что-бы ждать, транзакции начинают откатываться назад, тем самым еще сильнее снижая
производительность.



Оfftopic : Что-бы лучше понять, как работает Оракл, я прочитал некоторые разделы книги "Оracle для профессионалов. Архитектура и основные
особенности" Тома Кайта, и теперь хочу высказать несколько нелицеприятных слов в адрес автора.
Книга начинается с замечательных рассуждений о том, что к каждой СУБД требуется свой подход, и что работает в одной системе, не работает в
другой. Однако дальше он забывает об этом, и начинает писать совершенно возмутительные вещи.

На странице 170, обьясняя работу уровня read committed, на примере блокировочного подхода показаны блокировки, и сделан поразительный вывод о таких системах (цитата): "Это одна из причин появления у многих разработчиков плохой привычки фиксировать результаты в середине транзакции".
Такие заявления можно назвать по крайней мере бредом. Далее сделан вывод о преимуществе Оракла, так как там можно фиксировать транзакции в
зависимости от бизнес-требований, и не обращать внимания на потребления ресурсов блокировками. Это впрочем, не помешало ему в следующей главе
заявить, что транзакции в Оракл все равно надо делать как можно короче, что-бы избежать появления ошибки snapshot too old.

На странице 172, при разборе уровня repeatable read, приведен следующий пример работы блокировочного механизма, приводящий к deadlock:

Транзакция Т1 | Транзакция Т2

читаем 1 строку |
читаем 2 строку | меняем 5 строку -> ставим на нее эксклюзивную блокировку
читаем 3 строку | пытаемся поменять 1 строку -> висим на блокировке
читаем 4 строку |
пытаемся читать 5 строку -> deadlock

Далее цитата : "сеансы чтения и записи данных могут взаимно блокировать друг друга, и часто так и происходит"

За такие слова, хочется взять уважаемого господина Кайта и постучать его головой об стенку. Если-бы он удосужился хотя-бы одним глазом заглянуть в документацию по SQL Server, он бы увидел, что одним из фундаментальных требований при программировании под SQL Server является правильная последовательность операций. Приведенный выше пример можно найти в книжках для самых маленьких по программированию, и решается такая ситуация сменой последовательности обновления, никакая взаимоблокировка не наступит.

Собственно, таких примеров довольно много.
В книгах например, Роберта Вьейра по mssql, вы не найдете ни одного негативного выпада в сторону других СУБД. У Кайта-же, буквально на
каждой странице написано об ужасах блокировочных систем, да еще не по разу.
Поэтому нет ничего удивительного, что когда новичек в мире СУБД начинает читать Кайта, у него складывается впечатление, что Оракл является чем-то вроде божества. А потом на сайтах по всему интернету начинает литься грязь на mssql, так как люди видимо вполне искренне полагают, что это правда, ведь "так написано у Кайта" ! Им даже не приходит в голову, что если T-SQL программист вздумает воплотить примеры Кайта в жизнь, то он на следующий-же день вылетит с работы по причине профессиональной непригодности.

если мы сначала попытаемся вместо 5 строки обновить 1 строку, то вторая транзакция повиснет на блокировке и не сможет наложить блокировку на 5 строку, тем самым взаимоблокировка не наступит

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

а в Yukon я могу TempDB размазать по нескольким дискам или посадить на рейд

Yo!
эскалкация необходима сиквелу только для того чтоб хоть как-то функционировать при больших нагрузках

прежде чем делать такие заявления, неплохо-бы почитать теорию. Если вы откроете работу "Concurrency Control and Recovery in Database Systems" Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman то найдете там много интересного. В частности, там математически обосновывается полезность эсколации при длинных транзакциях. Существует такое понятие как Data contention, когда множество транзакций соревнуются между собой за блокировки. Так вот математически выведено, что делая грануляцию более грубой, в случае длинных транзакций вы получите прирост производительности.
Yo!
тесты TPC-C и SAP показывают что версинный механизм оракла не медленеей

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

softwarer
Вы вляпываетесь прямо в мой любимый пример.


а я кстати, и не говорю об абсолютной истиности математических выводов. Но вот только если вы утверждаете обратное, то просьба приложить свои математические выводы и доказательства. Кто вам мешает стать вторым Циолковским ? Докажите, что эсколация плохо, напишите книгу, может получите Нобелевскую премию, а я за вам порадуюсь. Но пока вы все это будете писать, я пожалуй буду пользоваться уже существующими теоремами.

Yo!!
смешно да :) вы прочитали док-во, спросили и до сих пор не поняли о чем речь ? вам же вроде объяснили что к длине транзакции эскалация никоим боком, а теперь еще раз, что там чего доказывает. :)

да, именно по наводке Merle с его статьей. Только после этого я все-таки скачал эту книжку и почитал. Кроме того, мы здесь обсуждаем базы данных, а не мое тупоумие. А вопрос я задавал до того, как прочитал книжку
Alex
2StalkerS В Юкон версионный механизм может (сможет :) )работать в 2 режимах - READ COMMITTED SNAPSHOT ON/OFF

Когда версионность включена, read committed автоматически превращается в read committed with snapshot (по терминологии майкрософт). Кроме того, есть вполне настоящий уровень snapshot, практически полный аналог serializable в Оракл

vadiminfo
и при адкватном указании этого параметра ORA-01555 snapshot too old скорей всего не может появиться

я рад за оракл, но полагаю, что существует разница между "маловероятно" и "невозможно в принципе"

softwarer
Судя по Вашему изложению Кайта, Вы не умеете читать и понимать написанное

на этом и порешим