Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7   вперед  Ctrl      все
 Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
Можно выделить следующие моменты :

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 программист вздумает воплотить примеры Кайта в жизнь, то он на следующий-же день вылетит с работы по причине профессиональной непригодности.
18 мар 05, 11:32    [1396967]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
Приведенный выше пример можно найти в книжках для самых маленьких по программированию, и решается такая ситуация сменой последовательности обновления, никакая взаимоблокировка не наступит.

Это как? И чем именно не понравился пример? Он не приводит к deadlock?
18 мар 05, 12:00    [1397082]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
если мы сначала попытаемся вместо 5 строки обновить 1 строку, то вторая транзакция повиснет на блокировке и не сможет наложить блокировку на 5 строку, тем самым взаимоблокировка не наступит
18 мар 05, 12:11    [1397126]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
StalkerS

Лично я не вижу смысла беседовать с человеком, который как минимум не умеет читать.
18 мар 05, 12:25    [1397171]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Yo!!
Guest
StalkerS

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


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

автор

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


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


автор


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


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

Эскалация блокировок - баг или фича?
https://www.sql.ru/forum/actualthread.aspx?tid=71533&pg=-1

Вывод от IBM:
Lock escalation. For many tablespaces, it’s also probably advisable to turn off lock escalation. SAP’s cluster table interface can read cluster tables without causing a problem with lock escalation; however, with other ERPs, lock escalation is one of the biggest contributors to poor performance.

http://www.db2mag.com/db_area/archives/1999/q2/99sp_yevich.shtml


автор

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


тесты TPC-C и SAP показывают что версинный механизм оракла не медленеей на olpt задачах, поэтому разводить зоопарк смысла маловато.
18 мар 05, 12:50    [1397310]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
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 вынес оракл со всех первых позиций
18 мар 05, 13:14    [1397442]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
StalkerS
В частности, там математически обосновывается полезность эсколации при длинных транзакциях. Существует такое понятие как Data

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

Чуть более века назад существовало строгое математическое доказательство того, что реактивная ракета не может выйти на околоземную орбиту. Кстати, абсолютно верное и остающееся до сих пор таковым. Однако, некто Циолковский таки добился того, что мы и не вспоминаем об этом доказательстве..
18 мар 05, 13:17    [1397458]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Yo!!
Guest
>а в Yukon я могу TempDB размазать по нескольким дискам или посадить на рейд

от того что ты уское место поделишь на несколько еще более узких, он шире не станет.

>В частности, там математически обосновывается полезность эсколации при длинных транзакциях.

http://rsdn.ru/Forum/Default.aspx?group=db
смешно да :) вы прочитали док-во, спросили и до сих пор не поняли о чем речь ? вам же вроде объяснили что к длине транзакции эскалация никоим боком, а теперь еще раз, что там чего доказывает. :)

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

оракла небыло на олимпе пол год-полтора за лет 10 :) к стате я не понял а что 10ка вдруг стала блокировочником или как ? почему версионник бьет блокировочник на его же поле OLPT ? за счет чего ?
18 мар 05, 13:33    [1397561]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Alex.Czech
Guest
2StalkerS В Юкон версионный механизм может (сможет :) )работать в 2 режимах - READ COMMITTED SNAPSHOT ON/OFF. ON логически выглядит абсолютно аналогично работе Оракла, OFF это нечто другое
18 мар 05, 13:36    [1397581]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
softwarer

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


а я кстати, и не говорю об абсолютной истиности математических выводов. Но вот только если вы утверждаете обратное, то просьба приложить свои математические выводы и доказательства. Кто вам мешает стать вторым Циолковским ? Докажите, что эсколация плохо, напишите книгу, может получите Нобелевскую премию, а я за вам порадуюсь. Но пока вы все это будете писать, я пожалуй буду пользоваться уже существующими теоремами.
18 мар 05, 13:37    [1397585]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
автор

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


Я Вам скажу больше. В 9 Оракле есть возможность явно прописать время, которое должны блоки сохраняться в табличном пространстве отката-, и при адкватном указании этого параметра ORA-01555 snapshot too old скорей всего не может появиться. В 8 при првильном указании размера сегмента отката и их кол-ве.

Насчет многоверсионности Вы упростили. Кроме той модели версионности, что Вы говорили, Оракл с 9 версии поддерживает и version-enable one or more user tables in the database. Больше того, это вообще общие идеи в технологих БД.
Так что тут Вы не все еще учли. Дела с версионностью, которая теперь нужна многим, еще хуже обстоят, чем Вы думали. Даже MS SQL смотрит в ту сторону. Чего же тут можно сказать нового?

Потом, дома прочту остальное повнимательнее, что Вы написали.
18 мар 05, 13:40    [1397602]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Dooma
Guest
Yo!!
оракла небыло на олимпе пол год-полтора за лет 10 :) к стате я не понял а что 10ка вдруг стала блокировочником или как ? почему версионник бьет блокировочник на его же поле OLPT ? за счет чего ?
В ожидании Youkon, всех давно уже отметелил DB2. Кстати то же блокировочник ;)
18 мар 05, 13:41    [1397604]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Yo!!
Guest
>В ожидании Youkon, всех давно уже отметелил DB2. Кстати то же блокировочник ;)

где ? на одинаковом железе tpc-c разница в 4-10%, а в sap оракл впереди.
18 мар 05, 13:44    [1397615]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
StalkerS
а я кстати, и не говорю об абсолютной истиности математических выводов.

Я тоже. Я говорю о применимости этих выводов - это ключевой вопрос математики, который обычно выпадает при поверхностном знакомстве с предметом.

StalkerS
Но вот только если вы утверждаете обратное, то просьба приложить свои математические выводы и доказательства.

Пока - незачем. Судя по Вашему изложению Кайта, Вы не умеете читать и понимать написанное (есть другой вариант - умеете, но осознанно передергиваете). В обоих случаях я не вижу смысла Вас переубеждать.
18 мар 05, 13:45    [1397618]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Dooma
Guest
Yo!!, если Yukon обзовут Yo!kon, он вам больше понравится?
18 мар 05, 13:45    [1397620]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
Yo!!

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

да, именно по наводке Merle с его статьей. Только после этого я все-таки скачал эту книжку и почитал. Кроме того, мы здесь обсуждаем базы данных, а не мое тупоумие. А вопрос я задавал до того, как прочитал книжку
Alex

2StalkerS В Юкон версионный механизм может (сможет :) )работать в 2 режимах - READ COMMITTED SNAPSHOT ON/OFF

Когда версионность включена, read committed автоматически превращается в read committed with snapshot (по терминологии майкрософт). Кроме того, есть вполне настоящий уровень snapshot, практически полный аналог serializable в Оракл
18 мар 05, 13:48    [1397642]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Dooma
Guest
Yo!
где ? на одинаковом железе tpc-c разница в 4-10%, а в sap оракл впереди.
Все хочу вас спросить: Вы не из тех кто ездит на зубиле с синими писалками и спойлером на крытых литых дисках и считают, что они обладатели супер-гоночного авто?
На одинаковом железе-операционке не совсем корректно, а то глядишь под win их всех MS сделает ;)
1 место TPC-C by Performance - IBM eServer p5 595 64p - IBM DB2 UDB 8.2
а Oracle тарахтя на HP кластере почти в три раза тормознутее ;)
18 мар 05, 13:55    [1397677]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
vadiminfo

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

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

softwarer

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

на этом и порешим
18 мар 05, 13:56    [1397681]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Yo!!
Guest
Dooma

1 место TPC-C by Performance - IBM eServer p5 595 64p - IBM DB2 UDB 8.2
а Oracle тарахтя на HP кластере почти в три раза тормознутее ;)


еще бы 128 процесорных ядра, еслиб он был медленее дб2 такое не опубликовало. а виндовс на такую машинку нестаят ...

2StalkerS
ОК, с эскалацией замяли, так что по остальным пунктам ?
18 мар 05, 14:04    [1397725]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
StalkerS


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


Так то оно так. Но, возможно, лучше маловероятная ошибка ORA-01555, чем грязное чтение или блокировака читающим, пишущего, тем более с несравненно большей вероятностью.
18 мар 05, 14:31    [1397841]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Alex.Czech
Guest
2StallkerS Похоже, вы действительно либо не умеете читать, либо не хотите вчитываться :( Я говорю про другое - помимо включения/выключения возможности использовать isolation level snapshot есть еще один параметр - вот он и влияет превращается ли read committed автоматически в read committed with snapshot или нет. По умолчанию оно off
18 мар 05, 14:35    [1397871]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Alex.Czech
Guest
Еще один момент - я проводил элементарное тестирование этого самого режима read snapshot для простых OLTP-запросов типа SELECT ... FROM table1 WHERE id = @id (правда, в бете 1, в бете 2 все руки не доходят) и обнаружил, что эти самые запросы замедлялись примерно на 40-50% (!)
18 мар 05, 14:45    [1397926]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
Alex.Czech
и обнаружил, что эти самые запросы замедлялись примерно на 40-50% (!)

Я бы вообще ожидал существенных тормозов от такой реализации; "копирование старой записи" - дорогая операция. Кроме того, недешевым будет и поиск нужной версии.

В самом худшем случае - может идти "копирование старой записи" при запросе, для обеспечения повторяемости при следующих чтениях (что вроде бы входит в snapshot).
18 мар 05, 14:50    [1397958]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
serg99
Member

Откуда:
Сообщений: 422
StalkerS

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


В этой связи один вопрос. Уровень изоляции обозначаемый в некоторых СУБД как SnapShot, в Oracle обозван Serializable. При этом данный уровень изоляции, насколько я понимаю, в общем случае не обеспечивает сериализуемости транзакций. Собственно не хочется обсуждать почему Oracle использует вводящее в заблуждение название, однако интересно насколько наличие настоящей сериализуемости облегчило бы жизнь разработчикам. Или если перефразировать вопрос, то насколько часто отсутствие сериализуемости приводит к дополнительным усилиям и проблемам в разработке (например из-за необходимости "ручной" блокировки через select for update и т.п.)?
18 мар 05, 15:02    [1398029]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
serg99
в Oracle обозван Serializable. При этом данный уровень изоляции, насколько я понимаю, в общем случае не обеспечивает сериализуемости транзакций.

В смысле? Можете конкретизировать, что имеете в виду?

serg99
то насколько часто отсутствие сериализуемости приводит к дополнительным усилиям и проблемам в разработке (например из-за необходимости "ручной" блокировки через select for update и т.п.)?

Хм. Если говорить про Oracle - а select for update вроде как оттуда - то нинасколько. Не представляю себе блокировки на уровне строк, которая исправит что-то, что недорабатывает serializable. Блокировка на уровне таблицы - может и есть какой-то момент, когда помогла бы, но не уверен. Но мне такую за всю жизнь пришлось использовать единственный раз, и не из-за уровней изоляции.
18 мар 05, 15:09    [1398079]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить