Zhora
Реальность - это OLTP+DSS(OLAP) на одном (!) сервере. Кто-то пишет, кто-то
читает, так что такие бенчмарки (чисто OLTP) особого смысла не имеют,
а вот поиметь блокировку (+ inconsistent result) между readers и writers и ждать ее конца без snapshot isolation гораздо реальнее.

вам наверное сюды например, и вообще к документации по программированию на mssql

Yo!
похоже прийдется в сотый раз тыкать носом в MSDN

Еще один герой умственного труда. Yo!, а почему вы изучаете принципы работы SQL Server по документации для разработки приложений на .NET ? Может пойдем например в раздел именно для сервера БД, и почитаем там например вот это:

msdn
When to Use Snapshot Isolation

Snapshot isolation provides transaction-level read consistency. A data snapshot is taken when the snapshot transaction starts, and remains consistent for the duration of the transaction. Use snapshot isolation when:

-Optimistic concurrency control is desired.

-Probability is low that a transaction would have to be rolled back because of an update conflict.

-An application needs to generate reports based on long-running, multi-statement queries that must have point-in-time consistency.

как видим, уж для OLTP снапшот не сильно походит. Уже сколько раз говорили, в каких случаях лучше версионность, а когда блокировочность (есть хоть такое слово-то ? ), сколько можно повторяться ?
Про deadlock'и там рядом написано, как надо программировать, что-бы свести их почти на нет. Хотя конечно, можно решить вопрос кардинально, и использовать только версионность.
Еще можно застрелиться, таким образом кардинально решив все свои жизненные проблемы. Только вы Yo!, если будете стреляться, то берите что-нибудь массивное, двухстволку например, что-бы мимо мозга не промахнуться

Yo!
хм .. причем тут MSSQL ? для тех кто не понял - речь идет о механизмах разруливания конкурентных транзакций

для тех, кто не понял - речь идет о механизмах разруливания конкурентных транзакций в MS SQL Server 2005. Значит и доки надо читать по этому продукту.
Yo!
или ты решил, что snapshot обязан юзать оптимистик локинг и повелся на update conflict

msdn SQL Server 2005
Transactions running under snapshot isolation take an optimistic approach to data modification by not acquiring locks on data until the data is to be modified. The selection of rows to update is done without acquiring locks. When a data row meets the update criteria, the snapshot transaction verifies that the data row has not been modified by a concurrent transaction that committed after the snapshot transaction began. If the data row has been modified outside of the snapshot transaction, an update conflict occurs and the snapshot transaction is terminated. The update conflict is handled by the Database Engine and there is no way to disable the update conflict detection.

Yo!
а вот с этого места по подробней шо говоришь ты там видишь ?

я вот не пойму, специально что-ли притворяетесь идиотом, или случайно получается ? Может надо напомнить, что из себя OLTP представляет ? Это Yo!, когда транзакции в основном меняют данные. А снапшот Yo!, откатывается, если встречает конфликт обновления. Хотя основные проблемы-то возникают все-таки не столько из-за откатов, сколько из-за банальной траты ресурсов на версии

в качестве бонуса - отрывок из статьи про версионность в mssql2005
rsdn.ru
Может показаться, что класс задач, для которых реально нужна версионность, достаточно узок. С одной стороны, использование версионности имеет смысл, если в блокировочнике конфликт читающих и пишущих запросов начинает оказывать заметное влияние на производительность. Но с другой стороны, при дальнейшем увеличении нагрузки, производительность версионного механизма довольно быстро начнет снижаться из-за частых обновлений по причине больших накладных расходов на поддержку версионности, она ведь тоже обходится не даром.


вообще Yo!, зачем вы здесь только тратите свое время ?
Yo!
"наблюдаю над штабом зеленый объект"

тем более - зачем вы тратите здесь свое время и свой иcкрометный юмор ?

Yo!
дык все верно, оракл эфективно использует ресурсы, от того и лидер

Вы начинаете напоминать нашего начальника отдела по работе с персоналом. Ему говоришь одно - он слышит другое. Это уже называется неадекватной реакцией.
Я ведь уже говорил, что именно мы здесь обсуждаем, и Оракл в это не входит.
Я конечно знаю ваше маниакальное желание сравнивать оракл со всем подряд, но лично я в этой ветке заниматься этим не намерен.
Yo!
так еще раз спрашиваю, Microsoft звиздит и пишет лажу на MSDN ?

Вы привели ссылку на документ для разработчиков клиентов для БД на .NET . Если воспринимать предложение "SQL Server 2005

introduces a new snapshot isolation level to enhance concurrency for OLTP applications" буквально и как "для всех олтп баз",

то это безусловно лажа.
Если-же читать доки конкретно по mssql, то можно прочитать например вот это:
"Enable read committed isolation using row versioning when:
-Reader/writer blocking occurs to the point that concurrency benefits outweigh increased overhead of creating and managing row

versions"
Выводы сделать сами в состоянии ? Или надо на русский язык перевести для доступности ?

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

различной степени подробности. Наверно посчитали, что среднестатический разработчик .NET мало парит в тонкостях уровней

изоляции, и подобного обьяснения введения версионности, без уточнения, что OLTP базы бывают разные, вполне достаточно. Хотя

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

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

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

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

где по закрытию периода агргированые данные переносятся в архив, а в оперативные журналы опять же данные только добавляются ;)

и что дальше ? Какую глубокую мысль вы хотели этим донести ? То, что базы олтп разные бывают ? Нашли чем удивить. Может вам в

сотый раз повторить, что для одной OLTP базы будет необходима версионность, а для другой - режим блокировок ? И даже больше,

для одной и той-же базы в один период времени может быть нужна блокировочность (днем: активный внос информации, мало чтения),

а в другой - версионность (вечер: составление больших отчетов, немногочисленный внос информации). Только вас ведь все равно ни

в чем не убедить, так что даже и пытаться не буду.
Надоедает спорить, особенно когда приходиться по 100 раз одно и то-же повторять.

softwarer
Я в принципе готов поверить, что мелкософтовский snapshot не подходит для OLTP, но не затруднит ли Вас объяснить, каким образом это следует из написанного здесь?


-Probability is low that a transaction would have to be rolled back because of an update conflict.
а теперь не затруднит-ли вас сказать, согласны-ли вы с тем, что с увеличением update'ов в БД, эта самая probability начинает уверенно возрастать ?
Кстати, если вы вдруг намереваетесь наподобие Yo! вцепится в формулировку, то обращаю ваше внимание, что "не сильно подходит" и "сильно не подходит" несколько отличаются Просто этот фактор никак не способствует выбору снапшота, хотя и не является основным (опять-таки с оговорками - возможна ситуация, когда эти откаты таки выкатяться на первое место, оставив ресурсопожирательство позади).
Yo!
на самом деле мы обсуждаем фразу оракла, которую МС просто скопировала чуток поменяв слова местами, сохранив смысл. и в оригинале фраза эта предназначена далеко не для для разработчиков клиентов.

Да, наверняка с очередного творения Кайта скопировано. Его замечательные мысли, что версионность это просто рай божий по сравнению с адом блокировок, я прекрасно помню
Yo!
я кончаю от таких слов

лучше-бы вы Yo! кончили в этот форум флудить