Yo.!!принципиальные различия оракла и mssql2k
http://oraclemind.blogspot.com/2005/04/oracle-vs-mssql2k.html
только начал читать, довольно интересно, однако мне непонятен, например, этот кусочек:
автор...
К стате на самом деле, обе реализации (Yukon'овский snapshot и oracle multiversion) это не чистые версионники, а с элементами блокировочника ну и в результате у нас получаются вот такие

Преимущества оракловой версионности.

Читающие запросы не блокируют пишущие, и наоборот.
Уменьшатся вероятность возникновения взаимоблокировок.
Есть возможность выполнять большие согласованные чтения, не предусмотренные структурой базы (ad-hoc queries), без риска сильного падения производительности остальных запросов.
Можно выполнять согласованные агрегатные запросы без повышения уровня изоляции.

Во что обходится версионность.

Пишущие транзакции обязаны создавать копию записи в хранилище версий, даже если на данный момент нет читающих запросов, которым нужна эта запись.
Читающие версионные запросы выполняются тем дольше, чем старее транзакция, из-за необходимости спускаться по цепочке ссылок к нужной версии данных. Это также порождает дополнительную нагрузку на процессор и память.
Часть пишущих транзакций при snapshot-уровне изоляции может быть отменена из-за конфликта версий при изменении данных. Эти же преимущества версионности (вместе с тем, во что это обходится) один в один есть и в MSSQL2005. Так что будет правильнее не передергивать и убрать слово, выделенное жирным.

Yo.!!а стоп, там не поэтому было выделено, этот кусок был честно сп*%жен с http://rsdn.ru/article/db/yukonvers.xml но там было еще пару миносовых пунктов mssql2005 которые к ораклу отношения не имеют.не вопрос, давайте сравним с оригиналом:
авторПреимущества версионности.

Читающие запросы не блокируют пишущие, и наоборот.
Уменьшатся вероятность возникновения взаимоблокировок.
Есть возможность выполнять большие согласованные чтения, не предусмотренные структурой базы (ad-hoc queries), без риска сильного падения производительности остальных запросов.
Можно выполнять согласованные агрегатные запросы без повышения уровня изоляции.

Во что обходится версионность.

Пишущие транзакции обязаны создавать копию записи в хранилище версий, даже если на данный момент нет читающих запросов, которым нужна эта запись.
Под хранилища версий, которые расположены в tempdb, необходимо дополнительное место. Причем его может потребоваться довольно много (при наличии длинных версионных транзакций и большом количестве изменений).
Длина каждой записи увеличивается на 14 байт.
Читающие версионные запросы выполняются тем дольше, чем старее транзакция, из-за необходимости спускаться по цепочке ссылок к нужной версии данных. Это также порождает дополнительную нагрузку на процессор и память.
Часть пишущих транзакций при snapshot-уровне изоляции может быть отменена из-за конфликта версий при изменении данных. Помимо того что во второй части исчезли 2 пункта, связанные с tempdb и длиной строки, связанные с конкретикой реализации версионности в MSSQL2005, откуда-то появилось то самое жирное слово, которого не было в оригинале. А MSSQL2005 пропал вообще.

хорошо, смотрим еще раз: автор...К стате на самом деле, обе реализации (Yukon'овский snapshot и oracle multiversion) это не чистые версионники, а с элементами блокировочника ну и в результате у нас получаются вот такие

Преимущества оракловой версионности...Черным по белому написано сравнение MSSQL2005 и Oracle. Мне непонятно здесь словосочетание "в результате". Откуда такой вывод?

Yo.!! segunЧерным по белому написано сравнение MSSQL2005 и Oracle. Мне непонятно здесь словосочетание "в результате". Откуда такой вывод?
есть теория, ее реализации немного (а местами много) различаются, у оракловой такие минусы, у юконовской минусов чуть больше, у меня в тексте говорилось именно об оракловой реализации, что я и попытался подчеркнуть, т.к. например у теоритической версионностей тоже минусов поболее будет. ну а "в результате" просто слово-связка выдернутых из разных источников текстов :) можно конечно переформулировать, но имхо смысл итак ясен.Уважаемый Yo.!! Почему вы считаете что "у юконовской минусов чуть больше"?

Yo.!! segunУважаемый Yo.!! Почему вы считаете что "у юконовской минусов чуть больше"?
segunПомимо того что во второй части исчезли 2 пункта, связанные с tempdb и длиной строки, связанные с конкретикой реализации версионности в MSSQL2005имхо вы себе правильно ответили, основной минус конечно - tempdb, я честно говоря слабо себе нормальную нагрузку на такой реализации ...На эту тему и
Yo.!!МС скопировала именно оракловую реалзацию. есть интересная статья My first look into row versioning на сайте http://www.scalabilityexperts.com в которой гораздо более корректно описаны часть особенностей реализации версионного механизма в MS SQL 2005 и Oracle, причем, в отличие от вас, без далекоидущих выводов. В частности автор пишет:
My first look into row versioningMicrosoft has measured the tempdb IO rate using production SAP workload as well as TPCC, and the increase is very reasonable. It has not become an issue at all. Я так понимаю, раз вы в состоянии сравнивать реализацию версионности в Oracle и MSSQL 2005 и делать публичные выводы без волшебного слова ИМХО, то вы хорошо представляете особенности этой реализации, в частности в MSSQL 2005?
Если это так, вам не составит труда ответить, например, на вопрос: что происходит с индексами, когда на уровне БД устанавливается один из типов версионности и в БД идут операции изменения и удаления данных?

авторК стате на самом деле, обе реализации (Yukon'овский snapshot и oracle multiversion) несколько отличаются от теоритического версионника, т.к. у пишуших транзакций присутствуют элементы блокировочника. Итак, если опустить минусы реализации mssql2005

Преимущества версионности (оракловой реализации).
Читающие запросы не блокируют пишущие, и наоборот.
Уменьшатся вероятность возникновения взаимоблокировок.
Есть возможность выполнять большие согласованные чтения, не предусмотренные структурой базы (ad-hoc queries), без риска сильного падения производительности остальных запросов.
Можно выполнять согласованные агрегатные запросы без повышения уровня изоляции.
Во что обходится версионность.

Пишущие транзакции обязаны создавать копию записи в хранилище версий, даже если на данный момент нет читающих запросов, которым нужна эта запись.
Читающие версионные запросы выполняются тем дольше, чем старее транзакция, из-за необходимости спускаться по цепочке ссылок к нужной версии данных. Это также порождает дополнительную нагрузку на процессор и память.
Часть пишущих транзакций при snapshot-уровне изоляции может быть отменена из-за конфликта версий при изменении данных.Yo.!!, не обижайтесь, но ведь полный бред написан!
1. вы взяли кусок из статьи по MSSQL 2005
2. вставили его дословно по свой блог и выдаете за преимущества оракловой реализации версионности.
3. причем, если у вас с логикой все нормально (а я в этом не сомневаюсь), то

авторИтак, если опустить минусы реализации mssql2005

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

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

Не стоит выдавать желаемое за действительное, от этого, в первую очередь, страдают остальные ваши аргументы и снижается доверие к той инфомации которую вы предоставляете.
И не стоит таскать каштаны из огня чужими руками (это я про кусок статьи которую вы тиснули и развернули на 180 градусов).

авторвы похоже не поняли - в тесте сравнивается блокировочник mssql2k и ораклОпять же, например:
Не стоит приводить ссылки на версию MSSQL 2000, в то время как там давно находится материал по MSSQL 2005.
Не стоит сравнивать цену с тем, что уже не продается (я про MSSQL 2000). А если сравниваете, говорите всю инфу, а не вырванный кусок. Вы наверняка же знаете о редакции MSSQL 2000 WE, которая стоила дешевле Standart One, но об этом вы деликатно промолчали.

И не стоит сравнивать что-то с чем-то не зная достаточно хорошо и то и другое, иначе есть риск отвечать на вопросы на которые не знаете ответа.
Либо пишите ИМХО.

авторalter database set allow_snapshot_isolation on разрешает использовать
на базе set transaction isolation level snapshot
то есть, разрешает использовать версионность.
Или я не так понял?
да, эта инструкция разрешает использовать версионность на уровне транзакций . А для того чтобы ей воспользоваться на клиенте нужно дополнительно указать set transaction isolation level snapshot . Если не указать, то версионность на уровне транзакций на клиенте использоваться не будет, хотя cервер исправно будет создавать версии строк при операциях update/delete.

другой тип версионности - это версионность на уровне инструкций , который включается командой alter database set READ_COMMITTED_SNAPSHOT ON . Сервер также будет создавать версии строк при операциях update/delete. В этом случае для того чтобы ей воспользоваться на клиенте никакие set transaction isolation level.. задавать не нужно.

DoomaТот который включается по alter database set read_committed_snapshot on и работает на уровне изоляции READ COMMITTED по поведению (не по реализации, конечно) ближе к Оракловому, т.е допускает фантомы.небольшая поправка: он не допускает фантомов, потому что работает только с закоммиченными данными, актуальными на момент старта инструкции.
Еще одно отличие от уровня Read Committed -он не накладывает блокировки на чтение при операциях SELECT.

2 Dooma:
без индекса на i в таблице A, вторая транзакция ждет завершения первой.
После завершения первой транзакции отрабатывает вторая и в A остается двойка.

Не понял, как при включенной версионности получить незакоммиченные данные первой транзакции во-второй транзакции (без использования nolock)?