ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Различия в работе версионных механизмов в Oracle и Yukon
151 сообщений из 151, показаны все 7 страниц
  все  
Различия в работе версионных механизмов в Oracle и Yukon
    #32967730
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
Можно выделить следующие моменты :

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 программист вздумает воплотить примеры Кайта в жизнь, то он на следующий-же день вылетит с работы по причине профессиональной непригодности.
...
Рейтинг: 0 / 0
18.03.2005, 11:32
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32967807
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
funikovyuri
Участник
Приведенный выше пример можно найти в книжках для самых маленьких по программированию, и решается такая ситуация сменой последовательности обновления, никакая взаимоблокировка не наступит.

Это как? И чем именно не понравился пример? Он не приводит к deadlock?
...
Рейтинг: 0 / 0
18.03.2005, 12:00
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32967839
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
если мы сначала попытаемся вместо 5 строки обновить 1 строку, то вторая транзакция повиснет на блокировке и не сможет наложить блокировку на 5 строку, тем самым взаимоблокировка не наступит
...
Рейтинг: 0 / 0
18.03.2005, 12:11
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32967878
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
StalkerS
Лично я не вижу смысла беседовать с человеком, который как минимум не умеет читать.
...
Рейтинг: 0 / 0
18.03.2005, 12:25
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32967970
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
StalkerS
1. В Yukon используется принципиально другая система хранения версионных данных. Вместо сегментов отката применяется системная база TempDB. В
результате не может появиться ошибка типа ORA-01555 snapshot too old, так как данные отката не затираются новыми данными, как это происходит в
Оракл.


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

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


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


автор

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


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

Эскалация блокировок - баг или фича?
http://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 задачах, поэтому разводить зоопарк смысла маловато.
...
Рейтинг: 0 / 0
18.03.2005, 12:50
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968057
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
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 вынес оракл со всех первых позиций
...
Рейтинг: 0 / 0
18.03.2005, 13:14
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968067
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
StalkerSВ частности, там математически обосновывается полезность эсколации при длинных транзакциях. Существует такое понятие как Data
Вы вляпываетесь прямо в мой любимый пример.

Чуть более века назад существовало строгое математическое доказательство того, что реактивная ракета не может выйти на околоземную орбиту. Кстати, абсолютно верное и остающееся до сих пор таковым. Однако, некто Циолковский таки добился того, что мы и не вспоминаем об этом доказательстве..
...
Рейтинг: 0 / 0
18.03.2005, 13:17
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968131
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
>а в Yukon я могу TempDB размазать по нескольким дискам или посадить на рейд

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

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

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

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

оракла небыло на олимпе пол год-полтора за лет 10 :) к стате я не понял а что 10ка вдруг стала блокировочником или как ? почему версионник бьет блокировочник на его же поле OLPT ? за счет чего ?
...
Рейтинг: 0 / 0
18.03.2005, 13:33
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968144
Alex.Czech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex.Czech
Гость
2StalkerS В Юкон версионный механизм может (сможет :) )работать в 2 режимах - READ COMMITTED SNAPSHOT ON/OFF. ON логически выглядит абсолютно аналогично работе Оракла, OFF это нечто другое
...
Рейтинг: 0 / 0
18.03.2005, 13:36
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968147
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
softwarer
Вы вляпываетесь прямо в мой любимый пример.


а я кстати, и не говорю об абсолютной истиности математических выводов. Но вот только если вы утверждаете обратное, то просьба приложить свои математические выводы и доказательства. Кто вам мешает стать вторым Циолковским ? Докажите, что эсколация плохо, напишите книгу, может получите Нобелевскую премию, а я за вам порадуюсь. Но пока вы все это будете писать, я пожалуй буду пользоваться уже существующими теоремами.
...
Рейтинг: 0 / 0
18.03.2005, 13:37
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968154
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
автор
результате не может появиться ошибка типа 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 смотрит в ту сторону. Чего же тут можно сказать нового?

Потом, дома прочту остальное повнимательнее, что Вы написали.
...
Рейтинг: 0 / 0
18.03.2005, 13:40
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968156
Dooma
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dooma
Гость
Yo!!оракла небыло на олимпе пол год-полтора за лет 10 :) к стате я не понял а что 10ка вдруг стала блокировочником или как ? почему версионник бьет блокировочник на его же поле OLPT ? за счет чего ?В ожидании Youkon, всех давно уже отметелил DB2. Кстати то же блокировочник ;)
...
Рейтинг: 0 / 0
18.03.2005, 13:41
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968164
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
>В ожидании Youkon, всех давно уже отметелил DB2. Кстати то же блокировочник ;)

где ? на одинаковом железе tpc-c разница в 4-10%, а в sap оракл впереди.
...
Рейтинг: 0 / 0
18.03.2005, 13:44
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968165
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
StalkerSа я кстати, и не говорю об абсолютной истиности математических выводов.
Я тоже. Я говорю о применимости этих выводов - это ключевой вопрос математики, который обычно выпадает при поверхностном знакомстве с предметом.

StalkerSНо вот только если вы утверждаете обратное, то просьба приложить свои математические выводы и доказательства.
Пока - незачем. Судя по Вашему изложению Кайта, Вы не умеете читать и понимать написанное (есть другой вариант - умеете, но осознанно передергиваете). В обоих случаях я не вижу смысла Вас переубеждать.
...
Рейтинг: 0 / 0
18.03.2005, 13:45
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968166
Dooma
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dooma
Гость
Yo!!, если Yukon обзовут Yo!kon, он вам больше понравится?
...
Рейтинг: 0 / 0
18.03.2005, 13:45
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968182
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
Yo!!
смешно да :) вы прочитали док-во, спросили и до сих пор не поняли о чем речь ? вам же вроде объяснили что к длине транзакции эскалация никоим боком, а теперь еще раз, что там чего доказывает. :)

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

Когда версионность включена, read committed автоматически превращается в read committed with snapshot (по терминологии майкрософт). Кроме того, есть вполне настоящий уровень snapshot, практически полный аналог serializable в Оракл
...
Рейтинг: 0 / 0
18.03.2005, 13:48
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968206
Dooma
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dooma
Гость
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 кластере почти в три раза тормознутее ;)
...
Рейтинг: 0 / 0
18.03.2005, 13:55
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968208
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
vadiminfo
и при адкватном указании этого параметра ORA-01555 snapshot too old скорей всего не может появиться

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

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

на этом и порешим
...
Рейтинг: 0 / 0
18.03.2005, 13:56
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968242
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
Dooma
1 место TPC-C by Performance - IBM eServer p5 595 64p - IBM DB2 UDB 8.2
а Oracle тарахтя на HP кластере почти в три раза тормознутее ;)

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

2StalkerS
ОК, с эскалацией замяли, так что по остальным пунктам ?
...
Рейтинг: 0 / 0
18.03.2005, 14:04
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968318
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
StalkerS

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


Так то оно так. Но, возможно, лучше маловероятная ошибка ORA-01555, чем грязное чтение или блокировака читающим, пишущего, тем более с несравненно большей вероятностью.
...
Рейтинг: 0 / 0
18.03.2005, 14:31
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968337
Alex.Czech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex.Czech
Гость
2StallkerS Похоже, вы действительно либо не умеете читать, либо не хотите вчитываться :( Я говорю про другое - помимо включения/выключения возможности использовать isolation level snapshot есть еще один параметр - вот он и влияет превращается ли read committed автоматически в read committed with snapshot или нет. По умолчанию оно off
...
Рейтинг: 0 / 0
18.03.2005, 14:35
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968372
Alex.Czech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex.Czech
Гость
Еще один момент - я проводил элементарное тестирование этого самого режима read snapshot для простых OLTP-запросов типа SELECT ... FROM table1 WHERE id = @id (правда, в бете 1, в бете 2 все руки не доходят) и обнаружил, что эти самые запросы замедлялись примерно на 40-50% (!)
...
Рейтинг: 0 / 0
18.03.2005, 14:45
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968400
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Alex.Czech и обнаружил, что эти самые запросы замедлялись примерно на 40-50% (!)
Я бы вообще ожидал существенных тормозов от такой реализации; "копирование старой записи" - дорогая операция. Кроме того, недешевым будет и поиск нужной версии.

В самом худшем случае - может идти "копирование старой записи" при запросе, для обеспечения повторяемости при следующих чтениях (что вроде бы входит в snapshot).
...
Рейтинг: 0 / 0
18.03.2005, 14:50
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968456
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
serg99
Участник
StalkerS
Когда версионность включена, read committed автоматически превращается в read committed with snapshot (по терминологии майкрософт). Кроме того, есть вполне настоящий уровень snapshot, практически полный аналог serializable в Оракл

В этой связи один вопрос. Уровень изоляции обозначаемый в некоторых СУБД как SnapShot, в Oracle обозван Serializable. При этом данный уровень изоляции, насколько я понимаю, в общем случае не обеспечивает сериализуемости транзакций. Собственно не хочется обсуждать почему Oracle использует вводящее в заблуждение название, однако интересно насколько наличие настоящей сериализуемости облегчило бы жизнь разработчикам. Или если перефразировать вопрос, то насколько часто отсутствие сериализуемости приводит к дополнительным усилиям и проблемам в разработке (например из-за необходимости "ручной" блокировки через select for update и т.п.)?
...
Рейтинг: 0 / 0
18.03.2005, 15:02
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968486
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
serg99в Oracle обозван Serializable. При этом данный уровень изоляции, насколько я понимаю, в общем случае не обеспечивает сериализуемости транзакций.
В смысле? Можете конкретизировать, что имеете в виду?

serg99то насколько часто отсутствие сериализуемости приводит к дополнительным усилиям и проблемам в разработке (например из-за необходимости "ручной" блокировки через select for update и т.п.)?
Хм. Если говорить про Oracle - а select for update вроде как оттуда - то нинасколько. Не представляю себе блокировки на уровне строк, которая исправит что-то, что недорабатывает serializable. Блокировка на уровне таблицы - может и есть какой-то момент, когда помогла бы, но не уверен. Но мне такую за всю жизнь пришлось использовать единственный раз, и не из-за уровней изоляции.
...
Рейтинг: 0 / 0
18.03.2005, 15:09
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968511
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
serg99
в Oracle обозван Serializable

Не только в Оракле он так обозван, но и насколько помню - это вообще стандартизованное название.
...
Рейтинг: 0 / 0
18.03.2005, 15:16
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968573
Dooma
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dooma
Гость
softwarerВ смысле? Можете конкретизировать, что имеете в виду?
Сотни раз уже тема мялась. Он имеетв виду:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
-- для всех транзакций устанавливаем isolation level в serializable.
create table a(i int)

-- transaction 1:
delete a where i in ( 1 , 2 ) 
insert into a (i) values ( 1 ); 

-- transaction 2:
delete a where i in ( 1 , 2 ) 
insert into a (i) values ( 2 ); 
commit; 

-- transaction 1:
commit;

В oracle, после таких упражнений, в таблице "a" окажется две записи, что ни коим образом не удовлетворяет определению serializable.

Нет в oracle честного serializable. Тогда как в Yukon для подобного случая при isolation level snapshot будет выведена ошибка с откатом, что более правильно.
...
Рейтинг: 0 / 0
18.03.2005, 15:37
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968629
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
DoomaСотни раз уже тема мялась. Он имеетв виду:
Не возражаю. Но иногда в таких ситуациях случается услышать что-то новое..

DoomaВ oracle, после таких упражнений, в таблице "a" окажется две записи,
Отметим - только в том случае, если до того ни одной из таких записей в таблице не было. А тогда пример оказывается.. малоосмысленным, чтобы не сказать "бессмысленным".

Doomaчто ни коим образом не удовлетворяет определению serializable.
Нет в oracle честного serializable.
"Честного" в Oracle действительно не так много. В Oracle в фаворе "практичное".

DoomaТогда как в Yukon для подобного случая при isolation level snapshot будет выведена ошибка с откатом, что более правильно.
Можете набросать механику - как именно это будет происходить? Собственно, интересуют два аспекта: есть ли теоретическая возможность подобной ошибки (если действия выполняются одновременно) и какова стоимость такой сериализации.
...
Рейтинг: 0 / 0
18.03.2005, 15:56
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968759
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
www.fun4me.narod.ru
Участник
softwarerОтметим - только в том случае, если до того ни одной из таких записей в таблице не было. А тогда пример оказывается.. малоосмысленным, чтобы не сказать "бессмысленным".


Не скажите.

После коммита транзакций должны выполняться условия :-

Транзакция 1:
Запись i=2 не существует
Запись i=1 существует

Транзакция 2:
Запись i=1 не существует
Запись i=2 существует

Это - логика транзакций. И установка serializable не позволяет эту логику реализовать.
...
Рейтинг: 0 / 0
18.03.2005, 16:35
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968766
Фотография www.fun4me.narod.ru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
www.fun4me.narod.ru
Участник
Поскольку условия выхода из транзакций противоречивы - одна из них должна быть отменена с соответствующей ошибкой.
...
Рейтинг: 0 / 0
18.03.2005, 16:37
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968797
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
www.fun4me.narod.ruНе скажите.
Для реализации этого условия существует адекватный механизм (unique function-based index). Если разработчик БД не желает вешать constraint - хм, как обычно, принимает на себя ответственность за последствия.
...
Рейтинг: 0 / 0
18.03.2005, 16:46
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968805
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
www.fun4me.narod.ruПоскольку условия выхода из транзакций противоречивы - одна из них должна быть отменена с соответствующей ошибкой.
Кстати, не должна. Откатывать транзакцию в момент commit-а - худший из возможных вариантов, но в вашем подходе неизбежный. В моем же случае - будет обычное исключение, которое может быть обработано и в итоге транзакция завершится штатно.
...
Рейтинг: 0 / 0
18.03.2005, 16:48
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32968834
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
опять по 5 кругу - mvc, ecalation, сириализибле ... ну никакой фантазии у народа :)

по стандарту - был стандарт 92, в нем описывались только феномины и подогнан был стандарт под блокировочники (их было больше). оракл честно соответствует ansi sql 92. потом в был sql99 вот туда добавили критерий упорядоченности. но к тому моменту все включая МС сказали что сдандарт гавно и в фтопку его.

http://www.osp.ru/dbms/1996/02/45.htm
...
Рейтинг: 0 / 0
18.03.2005, 16:55
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969162
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
vadiminfo
Так то оно так. Но, возможно, лучше маловероятная ошибка ORA-01555, чем грязное чтение или блокировака читающим, пишущего,

А при чем здесь грязное чтение и блокировки ? Грязное чтение вообще можно использовать только в особых случаях, блокировки - так я вам говорю о том, что версионность тоже будет включаться только когда нужна, т.е. когда доп. нагрузка из-за версионности компенсирует блокировки.

Alex.Czech
2StallkerS Похоже, вы действительно либо не умеете читать, либо не хотите вчитываться

Да, я не умею читать

Alex.Czech
Еще один момент - я проводил элементарное тестирование
...
и обнаружил, что эти самые запросы замедлялись примерно на 40-50% (!)

Не ломайте комедию. Тесты на производительность в принципе бессмыслено проводить на бета-версиях. Кроме того, вы что, ожидали что версионные запросы начнут работать быстрее блокировочных ? Использование версионности подразумевает правильную настройку TempDB, если вы еще об этом не в курсе, советую посетить сайт microsoft, прежде чем развешивать указанные вами цифры на всех углах.
...
Рейтинг: 0 / 0
18.03.2005, 19:10
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969203
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
StalkerS
А при чем здесь грязное чтение и блокировки ? ... так я вам говорю о том, что версионность тоже будет включаться только когда нужна,

При том, что в Оракле они исключены. А када включится версионность в Юниконе, тада посмотрим будет или нет там появляться что-то типа ORA-01555. А нужна она скорее всего всегда. А там где не нужна, там скорее всего одна транзакция на одну таблу. Не знаю что это такое. Возможно однопользовательская БД на домашнем компе?
Кроме того, как она включится? Ведь у блокировочника журнал транзакций, а у версионника журнал повторного выполнения. Тогда у Юникона будут оба вида журналов или он будет все равно с журналом транзакций будет париться в версионном варианте?

2 Dooma

Много мучался с Вашим примером, но он выдает неизменно одну запись i = 2. Две если только Delete во второй транзакции не выполнять.

Но Вы правы SERIALZABLE не означает последовательный график транзакций. Есть другой пример у Кайта, который это показывает. Но означает ли SERIALZABLE такой график в SQL92?
Вроде как такой уровень просто исключает: грязное чтение, неповторяемость при чтении и чтение фантомов.
Или у Вас есть инфа, что последовательный график, т.е. как будто транзакции выполнялись последовательно? Я что-то не нашел.
...
Рейтинг: 0 / 0
18.03.2005, 20:00
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969220
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
>Не ломайте комедию. Тесты на производительность в принципе бессмыслено проводить на бета-версиях.

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

http://www.eweek.com/article2/0,1759,1776031,00.asp
...
Рейтинг: 0 / 0
18.03.2005, 20:25
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969237
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
vadiminfo
А када включится версионность в Юниконе, тада посмотрим будет или нет там появляться что-то типа ORA-01555

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

Нет
vadiminfo
А там где не нужна, там скорее всего одна транзакция на одну таблу

Она не нужна в тех задачах, когда число пишуших транзакции гораздо больше читающих.
vadiminfo
Ведь у блокировочника журнал транзакций, а у версионника журнал повторного выполнения.

Насколько понял, это - фактически одно и то-же
...
Рейтинг: 0 / 0
18.03.2005, 20:41
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969239
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
Yo!!
а они только после 3-й бэты будут оптимизацией заниматся.

кто, чем и когда будет заниматься, решать все равно не нам с вами. Мне не хочется разводить флейм по поводу тестов системы, которая еще не зарелизина. Предметно это можно будет рассматривать, только когда выйдут официальные результаты.
...
Рейтинг: 0 / 0
18.03.2005, 20:47
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969283
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
StalkerS
вы невнимательно читали мой первый пост. Версионные записи удерживаются до того, как зафиксируется старейшая заинтересованная транзакция, таким образом подобного типа ошибки исключены.


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


StalkerS
Нет

Хорошо. Вам не нужна, а мне не помешает.

StalkerS
Она не нужна в тех задачах, когда число пишуших транзакции гораздо больше читающих.

Так случается, что пишушие тоже почитывают.

StalkerS
Насколько понял, это - фактически одно и то-же

А я раньше думал, что это фактически не совсем одно и то-же. Может заблуждался. Надо еще раз почитать про них. Ведь если одно и тоже, то как они обходились до сих пор (пока не перешли из блокировочников в версионники) без сегментов отката? Ведь одних только журналов повторного выполнения не дростаточно для восстановления? Не до конца ясно.
...
Рейтинг: 0 / 0
18.03.2005, 22:07
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969293
Alex.Czech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex.Czech
Гость
2vadiminfo. У MS SQL undo и redo информация хранятся в одном файле (transaction log). В каком виде и как - не спрашивайте, я не помню деталей, можно почитать книгу Inside SQL Server, там все достаточно хорошо описано
...
Рейтинг: 0 / 0
18.03.2005, 22:18
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969303
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
serg99
Участник
vadiminfoНо Вы правы SERIALZABLE не означает последовательный график транзакций. Есть другой пример у Кайта, который это показывает. Но означает ли SERIALZABLE такой график в SQL92?
Вроде как такой уровень просто исключает: грязное чтение, неповторяемость при чтении и чтение фантомов.
Или у Вас есть инфа, что последовательный график, т.е. как будто транзакции выполнялись последовательно? Я что-то не нашел.

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

В стандарте же качество изоляции определяется отсутствием одного из феноменов
-Dirty Read
-Read Commited
-Repeatable Read
-Phantoms

Однако отсутствие всех этих феноменов (как в режиме Snapshot) автоматически не означает что транзакции являются сериализуемыми. То есть в данном случае Оракл вольно или невольно своим названием serializable вместо snapshot вводит народ в заблуждение.

Скажем в нижнем примере при каждом чтении целочисленного атрибута 1 затем следует его увеличение на единицу и запись.

Код: plaintext
1.
Trans1              Start Read1 Write1 Commit
Trans2     Start                                          Read1 Write1 Commit
Интересно что при изоляции Read Commited этот сценарий является сериализуемым, то есть сводится к последовательному выполнению транзакций и после выполнения их обоих значение атрибута увеличивается на 2.

В то же время при уровне snapshot (serializable в Оракл) сценарий становится наоборот не сериализуемым. При этом так как Транзакция2 началась раньше, она видит только старое значение атрибута и в итоге после выполнения обоих транзакций атрибут увеличивается на 1 вместо правильных 2 (как было бы при их последовательном выполнении). То есть нарушается логическая правильность состояния БД после выполнения транзакций.

Интересно воспринимаются ли подобные эффекты как проблема, или на практике об этом никто не задумывается?
...
Рейтинг: 0 / 0
18.03.2005, 22:25
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969326
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
2 Alex.Czech
Но я про то и говорю: transaction log - журнал транзакций. Это для блокировочника. Там все про транзакции завершенные и не завершенные - то что ему нужно для восстановления. У версионника Оракла redo.log - журнал повторного выполнения. Там тока инфа про завершенные транзакции, которые он повторно выполнит, если точно не известно что изменения зафиксированы в БД на диске (т.е. изменения после контрольной точки, а undo он возьмет просто из сегментов отката или табл пространств отката просто блоки до изменений). Значит разница есть между журналами транзакций и журналами повторного выполнения?
...
Рейтинг: 0 / 0
18.03.2005, 22:56
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969332
Alex.Czech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex.Czech
Гость
Разница в том, что у Оракла это два разных журнала, и запись туда ведется независимо, а у MSSQL один, и там инфа хранится вместе, по-моему она даже переплетена... сейчас я поищу книжку, она у меня лежит где-то в электронном виде
...
Рейтинг: 0 / 0
18.03.2005, 23:07
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969334
Alex.Czech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex.Czech
Гость
The transaction log records all changes made to the database and stores enough information to allow any changes to be undone (rolled back) or redone (rolled forward) in the event of a system failure or if it is told to do so by the application (in the case of a rollback command). Physically, the transaction log is a set of files associated with a database at the time the database is created or altered. Modules that perform database updates write log entries that exactly describe the changes made. Each log entry is labeled with a log sequence number (LSN) that is guaranteed to be unique. All log entries that are part of the same transaction are linked together so that all parts of a transaction can be easily located for both undo activities (as with a rollback) and redo activities (during system recovery).
...
Рейтинг: 0 / 0
18.03.2005, 23:10
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969342
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
2 serg99

>Интересно воспринимаются ли подобные эффекты как проблема, или на практике об этом никто не задумывается?

На практике однозначно задумываются и прменяют либо оптимистические блокировки либо писсемистические.

Мне кажется, что в Вашем примере возникает, та ситуация про которую говорил www.fun4me.narod.ru. И я считаю, что тразакция 2 (правда я read1 мысленно подвинул к start) должна быть отменена. Т.е. юзер должен получить любимое - "запись изменена другим пользователем" (оптимистическая блокировка) или он должен был заблокировать транзакцию после чтения. Иначе мы доиграимся. Все-таки второй юзер хотел увеличить только на 1, то что прочитал, а оно вдруг изменилось на 2?! Опять уточняю, что read1 мысленно подвинул к start у второй транзакции для типичности. Или Вы намерено сделали между ними разрыв, чтобы непонятней было какую из них нужно все-таки отменить?
...
Рейтинг: 0 / 0
18.03.2005, 23:41
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969352
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
2 Alex.Czech
Ну про журнал транзакций для блокировочников Вы пишите то, что я про них и думал. Я читал про них в общей литре по БД, где описывается упрощенная архитектура СУБД на примере блокировочника.
Что до оракла ту него только журнал повторного выполнения, хотя и реализован в виде нескольких файлов. Как минимум двух, но типично из трех. Ну, еще могут быть включены архивные журналы повторного выполнения. Ими защищены и undo сегменты. Но это не журналы, а копии блоков данных до начала изменения. Отсюда собственно и термин многоверсионность - несколько версий данных. Эти андо используются не только для чтенеия на уровне READ COMMITED, но и для отмены незавершенных транзакций при восстановлении после сбоев. Об этом кстати есть тоже в общей литре по БД.
...
Рейтинг: 0 / 0
18.03.2005, 23:59
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969369
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
serg99
Участник
vadiminfoМне кажется, что в Вашем примере возникает, та ситуация про которую говорил www.fun4me.narod.ru. И я считаю, что тразакция 2 (правда я read1 мысленно подвинул к start) должна быть отменена. Т.е. юзер должен получить любимое - "запись изменена другим пользователем" (оптимистическая блокировка) или он должен был заблокировать транзакцию после чтения. Иначе мы доиграимся. Все-таки второй юзер хотел увеличить только на 1, то что прочитал, а оно вдруг изменилось на 2?! Опять уточняю, что read1 мысленно подвинул к start у второй транзакции для типичности. Или Вы намерено сделали между ними разрыв, чтобы непонятней было какую из них нужно все-таки отменить?

Я специально сделал разрыв. То есть инкремент атрибута может происходить в разных транзакциях и/или разных приложениях и/или разных клиентах, а планировщик ОС сервера может по разному планировать нити исполнения разных транзакций. То есть вполне возможно как в приведенном примере, что транзакция_1 ПОЛНОСТЬЮ завершится ДО того как с атрибутом начнет работать транзакция_2 начатая раньше. А так как в версионниках при snapshot транзакция начинается как правило с создания локальной копии TIP, то транзакция_2 вообще не видит транзакцию_1 даже когда та закоммитится. В данном случае так же не нарушается правило, что одновременно может существовать только одна незакоммиченная версия записи, при этом транзакция_1 "при жизни" не знает наперед что будет делать транзакция_2.

То есть получается, что для борьбы с этим феноменом нужно вручную в начале транзакции блокировать ресурс который транзакция собирается или может изменить, чего можно было бы избежать если бы СУБД поддерживала настоящую сериализуемость транзакций.
...
Рейтинг: 0 / 0
19.03.2005, 00:59
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969380
Alex.Czech
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex.Czech
Гость
2vadiminfo. Я в курсе как оно у Оракла, спасибо :) Насчет того как будет работать Yukon с транзакшн логом - так же как и раньше видимо. Поживем-увидим
...
Рейтинг: 0 / 0
19.03.2005, 01:54
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969423
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
vadiminfo
Если много записей удерживать бесконечно долго, то вылезет другая более худшая ошибка

Это уже является проблемой правильного проектирования базы, а никак не проблем в работе сервера. Кроме того, использование отдельного места для хранения версий как раз более устойчиво к такого рода ошибкам, так как TempDB будет самостоятельно расти, а rollback сегменты придется сразу задавать очень большого размера, расходуя понапрасну память.
vadiminfo
Хорошо. Вам не нужна, а мне не помешает.

Странный ответ. Вы базы что, для личного пользования делаете ?
vadiminfo
Так случается, что пишушие тоже почитывают

Так я говорю о процентном отношении пишуших и читающих
vadiminfo
Эти андо используются не только для чтенеия на уровне READ COMMITED, но и для отмены незавершенных транзакций при восстановлении после сбоев

В SQL-Server лог транзакций используется для отката транзакций в случае выполнения команды rollback или возникновения ошибки, восстановления всех незавершенных транзакций в случае аварийного перезапуска сервера, восстановления базы в случае отказа винтов вплоть до момента отказа. Но необходимые данные содержаться в самом журнале.
Принципиальная разница Оракла в том, что у него журналы повторного выполнения используются только для восстановления после сбоя, а простой откат транзакции выполняется по информации из сегментов отката. Т.е. при изменении данных, в Оракле генерируется новые блоки сегментов отката и данные журнала повторного выполнения, а в SQL-Server - все данные о транзакции отправляются в журнал
...
Рейтинг: 0 / 0
19.03.2005, 07:42
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969606
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
2 serg99
Я воспроизвел Ваш пример. При попытке добавленя 1 в транзакции 2 получили сообщение об ошибке ORA-08177 can't serialize access for this transaction
А в литре по БД пояснение, что в этом случае в приложеннии должно быть предусмотрено повторное выполнение этой транзакции. Т.е. получается последовательный график транзакций. Т.е. не всегда надо в ручную вначале транзакции блокировать никакой ресурс. Достаточно установить ISOLATION_LEVEL = SERIALIZABLE. Я использовал update. А тут видно, что нюансы начинаются с инсертами. Поскольку до инсетра в пустой БД еще ничего не было, наверное. Буду смотреть этот вопрос дальше.

2 Dooma
Я извиняюсь, вчера не заметил, что девелопер настроен коммитить любую операцию, поэтому и не получалось.



StalkerS
Это уже является проблемой правильного проектирования базы, а никак не проблем в работе сервера.

Вы идtализируете проектирование базы. Ну хорошо ORA-01555 - результат того, что система не до конца правильно спроетирована. Не учли ситуации, не все просчитали, наделали ошибок в ХП. Ну их наделают и в Юконе. Или нет?

StalkerS

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

Но я говорил Вам о том, что, начиная с Оракле 9 можно явно задать время, которое нельязя перезаписывать блоки отката. Ну и тоже будет расти. Там есть понятие табличных пространств отката, а не только сегментов отката. Вы можете использовать и то и другое. При использовании табличных пространст можете написать время.


StalkerS
Странный ответ. Вы базы что, для личного пользования делаете ?


Исключительно не для личного, потому так и говорю - если есть версионность ее предпочту однозначно? и не буду замарачиваться. Потому что нужны слишком серьезные доводы, чтобы ее не применять, а пока я знаю только один - СУБД в принципе не поддерживает версионности. Ну, может быть система для одного пользователя, тогда тоже не имеет особого значения.

StalkerS
Так я говорю о процентном отношении пишуших и читающих

Так я говорю о том, что кроме инсерта все пишущие можно считать и читающими. Т.е. они читают, а тока потом удаляют или обновляют. Им же нужно значть что удалять и что обнавлять? Потому делят часто на только читающие и все остальные.



StalkerS
Принципиальная разница Оракла в том

Так я Вам и говорил именно про эту разницу. Т.е. про разницу между журналами тразакций и повторного выполнения. А Вы, вроде, говорили, что нет разницы. Добавлю, что использует эти данные сегментов отката не только для воостановления, но для обеспечения уровня изоляции READ COMMITED. Т.е. собственно для своей многоверсионности. Т.е. для двух целей использует сегменты отката. Потому и спарашивал Вас, что SQL-Server будет по прежнему пользоваться журналами транзакций в многоверсионном режиме? Не будет использовать эти блоки старой версии? Вроде, на первый взгляд, как-то не оптимально получается тогда.
...
Рейтинг: 0 / 0
19.03.2005, 14:41
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969690
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
vadiminfo
Вы идtализируете проектирование базы. Ну хорошо ORA-01555 - результат того, что система не до конца правильно спроетирована. Не учли ситуации, не все просчитали, наделали ошибок в ХП. Ну их наделают и в Юконе. Или нет?
...
При использовании табличных пространст можете написать время.

Принципиальное отличие в том, что как-бы криво я ни писал процедуры, нужная версионная информация всегда будет доступна. В то-же время, как-бы качественно ни писали вы свои процедуры, всегда есть вероятность напороться на ORA-01555.
Почувствуйте разницу ! (из рекламы не помню чего, наверно пива ;)
vadiminfo
Потому что нужны слишком серьезные доводы, чтобы ее не применять, а пока я знаю только один - СУБД в принципе не поддерживает версионности.

Разумеется вы будете работать только с версионностью, так как Оракл только с ней и работает ;)
В то-же время в Yukon версионностью будут пользоваться только в определенных ситуациях из-за наличия вполне очевидных причин.
Вот угадайте с трех раз, какая процедура будет работать быстрее для оператора обновления:

блокировочный подход :

1) Находим запись
2) Ставим эксклюзивную блокировку
3) Меняем запись
4) Снимаем блокировку

версионный подход:

1) Находим запись
2) Ставим эксклюзивную блокировку
3) Создаем версию записи
4) Меняем запись
5) Снимаем блокировку
6) Если нет заинтересованных транзакций, то удаляем версию

Поэтому, версионный подход будет нужен только там, где задержки читающих транзакций создают серьезные помехи в работе.
А сейчас разберемся, что такое читающие транзакции, так как судя по
vadiminfo
Так я говорю о том, что кроме инсерта все пишущие можно считать и читающими. Т.е. они читают, а тока потом удаляют или обновляют

вы не совсем это понимаете.

Читающая транзакция - это такая транзакция, которая возращает набор данных. Например

Код: plaintext
select ProgrammerName from CoolProgrammers where City = 'Ekaterinburg'

Такой запрос, в однопользовательской среде сразу вернет набор строк, включая строку 'StalkerS' ;)

В многопользовательской среде, то, что произойдет, зависит от ряда условий.
Например, нажравшись пива, я решил сменить свой ник:

Код: plaintext
update CoolProgrammers set ProgrammerName = 'BeerMan' where ProgrammerName = 'StalkerS'

Так вот в блокировочнике, если попытаться получить все имена во время выполнения апдейта, то вы повисните на блокировке до тех пор, пока транзакция не будет закоммичена, и только после этого получите резалтсет, но уже с именем 'BeerMan'.
В версионнике вы получите резалтсет сразу, но с именем 'StalkerS'.
Поэтому, если вдруг все программисты Екатеринбурга в один момент захотят изменить свои ники, а вы хотите получить список всех имен, вам придется ждать неопределенное время. В версионнике вы сразу получите старые версии их имен, но ценой некоторого падения производительности, так как теперь на каждое изменяемое имя система будет делать версию.

Теперь определяемся, что мы хотим от системы. Если к данной таблице каждый день идут десятки тысяч запросов от заграничных работодателей, то мы не хотим их заставлять ждать, и включаем версионность.
Если-же за границей никогда не слышали такого слова как "Екатеринбург" и нет никаких обращений к таблице, то мы лучше включим блокировочный режим, купим пива и начнем менять свои ники не опасаясь замедления в работе базы.
vadiminfo
Т.е. про разницу между журналами тразакций и повторного выполнения. А Вы, вроде, говорили, что нет разницы.

Да виноват, наверно я в самом деле не умею читать, так как вначале от меня ускользнула такая важная деталь. Я привык к тому, что журнал транзакций отвечает за все, и встретив журналы повторного выполнения, автоматически решил, что они используются так-же.
Ну а в Yukon с журналом вряд-ли случаться грандиозные перемены, наверняка все останется по старинке.
...
Рейтинг: 0 / 0
19.03.2005, 17:38
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969713
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
авторПринципиальное отличие в том, что как-бы криво я ни писал процедуры, нужная версионная информация всегда будет доступна. В то-же время, как-бы качественно ни писали вы свои процедуры, всегда есть вероятность напороться на ORA-01555.
Почувствуйте разницу ! (из рекламы не помню чего, наверно пива ;)

судя по всему уйти от обсуждения некоторых личвных качеств некотрых участников обсуждения нам все таки неудастся ;)
ув StalkerS давайте все таки напряжемся и попытаемся понять зачем оракл затерает данные ?
почему он предпочитает откатить 1 транзакцию с ORA-01555 ? зачем это лишнее ограничение безразмерного роста сегмента отката ? что было бы если сегмет отката рос бесконечно ?
да это просто дыра для DOS атак, в сиквеле получается любой юзер может вызвать остановку всего инстанса, просто сделать бесконечный цикл который переполняет tempdb.
...
Рейтинг: 0 / 0
19.03.2005, 18:10
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969714
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
да, насчет версионности, еще вариант : работадатели обращаются с запросами только по ночам, поэтому днем работаем как блокировочник, а на ночь включаем версионность
...
Рейтинг: 0 / 0
19.03.2005, 18:12
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969722
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
Yo!!
судя по всему уйти от обсуждения некоторых личвных качеств некотрых участников обсуждения нам все таки неудастся ;)

да, вы правы, сдержаться сложно, но я стараюсь !
Yo!!
ув StalkerS давайте все таки напряжемся и попытаемся понять зачем оракл затерает данные ?

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

Если-же вам хочется напрягаться и думать, то советую подумать над такими вещами :

1) При версионности TempDB необходимо оптимизировать на производительность, значит садить на рейд например.
2) Версионность юзается только тогда, когда нужно

удачи!
...
Рейтинг: 0 / 0
19.03.2005, 18:24
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969734
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
2StalkerS

какая производительность ? еще раз ORA-01555 это защита от остановки всего истанса. т.е. у сиквела просто баг раз такой защиты нет. наверника в следующем релизе в sql2010 им это прийдется сделать тоже самое.
...
Рейтинг: 0 / 0
19.03.2005, 18:38
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969736
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Не корысти ради (c) но влезу с точки зрения реализации версионности в IB\FB, с которой я немного знаком, да и, насколько я в курсе, реализация в Yukon'е много ближе к IB чем к ORACLE.

StalkerSВот угадайте с трех раз, какая процедура будет работать быстрее для оператора обновления:

блокировочный подход :

1) Находим запись
2) Ставим эксклюзивную блокировку
3) Меняем запись
4) Снимаем блокировкуБлокировка снимается только после COMMIT\ROLLBACK, т.е. ещё поживет некоторое время

StalkerSверсионный подход:

1) Находим запись
2) Ставим эксклюзивную блокировкуТут есть блокировка, но не такая, как у блокировочника - это блокировка не записи (логического объекта), а физической страницы от одновременного изменения в другом процессе.

StalkerS3) Создаем версию записи
4) Меняем запись
5) Снимаем блокировкуБлокировка снимается сразу, не дожидаясь окончания тр-ции. Т.е. время её действия очень мало

StalkerS6) Если нет заинтересованных транзакций, то удаляем версию
Нет, не так. Тр-ция, создавшая версию, никогда не удаляет оригинальную, т.к. может откатиться. Мусор будет удалён позже, кем-то другим.

Отсюда можно заключить, что блокировочник вынужден запоминать много блокировок одновременно и действуют они достаточно долго - дольше, чем происходит собственно обновление записи, но у него не остаётся мусорных версий.
Версионник управляет значительно меньшим кол-вом блокировок одновременно и живут они очень недолго. Зато приходится чистить мусор. При многопользовательской работе версионник однозначно будет меньше простаивать на блокировках и общая пропускная способность у него будет выше.
...
Рейтинг: 0 / 0
19.03.2005, 18:39
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969777
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Markelenkov
Участник
StalkerSблокировочный подход :

1) Находим запись
2) Ставим эксклюзивную блокировку
3) Меняем запись
4) Снимаем блокировку

версионный подход:

1) Находим запись
2) Ставим эксклюзивную блокировку
3) Создаем версию записи
4) Меняем запись
5) Снимаем блокировку
6) Если нет заинтересованных транзакций, то удаляем версию
Я не буду комментировать знание автором Oracle :)

У меня есть 2 вопроса к автору:
1. Как считает автор, есть ли разница (и велика ли она, если есть) в стоимости (скорости) установки и снятия блокировки с записи в первом и втором случаях?
2. Предположим, в блокировочнике требуется выполнить транзакцию, скажем, из 5 вставок, 5 обновлений и 5 удалений строк. Предположим, на пятом удалении получена ошибка и требуется откатить все изменения, выполненные в данной транзакции. Где будет брать блокировочник старые версии данных?
...
Рейтинг: 0 / 0
19.03.2005, 20:06
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969778
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
serg99
Участник
vadiminfo Я воспроизвел Ваш пример. При попытке добавленя 1 в транзакции 2 получили сообщение об ошибке ORA-08177 can't serialize access for this transaction
А транзакция_1 к этому времени уже была закоммичена? Интересно кстати если во второй транзакции не читать атрибут, а просто сразу записать какую нибудь константу, то то же будет ORA-08177?

vadiminfoА в литре по БД пояснение, что в этом случае в приложеннии должно быть предусмотрено повторное выполнение этой транзакции. Т.е. получается последовательный график транзакций. Т.е. не всегда надо в ручную вначале транзакции блокировать никакой ресурс. Достаточно установить ISOLATION_LEVEL = SERIALIZABLE.
В этом как раз и проблема. Вы говорите серверу "сериализуй мои транзакции", а он вместо того что бы этим заниматься говорит Вам "сам сериализуй". И получается программисту в любом случае нужно самому заботиться о сериализованности своих транзакций, предусматривая в приложении либо предварительную блокировку ресурсов в транзакции, либо повтор (возможно многократный) транзакции в случае конфликтов.

То есть получается что СУБД сама по себе не обеспечивает уровень изоляции транзакций соответсвующий "честной" сериализуемости. Хотя пользователь задавая ISOLATION_LEVEL = SERIALIZABLE ожидает именно этого.
...
Рейтинг: 0 / 0
19.03.2005, 20:13
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969830
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
2 StalkerS
Про ORA-01555. Я же и грил Вам - давайте посмотрим что будет у Юникона. Вы думаете что версионность такая халява? И что Оракл не мог сделать сохранение версий на столько на сколько может Юникон. Значит есть причины. Потому и не могу пока почуствовать разницу. Мож у Вас там вылезет какой-нибудь сюрприз. Разве так не бывало?
Добавлю только что в 9 ни разу не натыкался еще на ORA-01555. Писал почему. Надеюсь, Вы прочли. Там по умолчанию ставится 3600 сек. 6 часов.



Про Ваш пример с блокировочным подходом и версионный подход Вам ответили более компетентные специалисты, чем я. Поэтому тратить время на разборы не буду. Давайте решим так: Вы будете пользоваться и тем и тем, а я только версионностью пользовался бы и в Юниконе, если бы на деле она оказалась не хуже, чем в Оракле. В противном случае я бы пользовался толтько блокировочностью в Юниконе.
Пока продолжаю считать, что версионнасть такая как в Оракле исключает грязное чтение раз, и не позволяет заблокировать читающему пишущего. А блокировочник только одно из этих одновременно может делать. Кроме того, в Оракле не возможна эскалация блокировок.
Что касается производительности, то главное не в процессе обновления, а в процессе чтения для него. Так как Вам про блокировки в нем сказали, а остальные и основные тормоза при чтении с диска. Есть, конечно, и др события которых ждут сессии. Но главные те две, по крайней мере в этой теме.
Но не только потому что я Ораклист. Хотя не без этого. В литре читал подобные мысли.

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

Я тоже попью с Вами пивка, но включу с Вашего позволения версионность. В частности, чтобы не беспокоиться вообще ни о чем, включая и заграницу.
Что-то мне говорит, что если у Юникона версионность будет не хуже, чем у Оракла, то и Вы через какое-то время навсегда забудете про блокировочники.
...
Рейтинг: 0 / 0
19.03.2005, 21:54
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969865
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
serg99
А транзакция_1 к этому времени уже была закоммичена? Интересно кстати если во второй транзакции не читать атрибут, а просто сразу записать какую нибудь константу, то то же будет ORA-08177?

К сожалению, я все потер - покупал сегодня комп и закрутился. Потом вернусь еще к этим примерам. Но стараля закомитить. Более того следил за тем, чтобы в словаре БД транзакция изчезла и осталась только та первая.
Но надо бы повторить.
Но не понял что значит не читать атрибут? Ведь он читает запись. А атрибут только меняет. Просто в Вашем пример I = I+1, а Вы хотите I = Const? Мне пока кажется, что это ничего не должно изменить. Напишите в командах что Вы имеет в виду, вдруг я не совсем так Вас понял.



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

Насколько я понял Вашего коллегу в MS SQL выдается тоже ошибка.
Вот я писал Вам про оптимистическую блокировку. Там однозначно приложение запоминает данные после чтенися. Меняет их в приложении. Потом перед записью еще раз читает и сранивает. Если видит изменение, то выдант сообщение "Запись изменена другим пользователем". Это классика. И делает это не сервер.
На ошибку можно вообще по разному среагировать. Можно повторить транзакцию молча, а можно предупредить и дать возможность юзеру принять решение.

Кстати все утро прорыля в литре. Нашел, что этот уровень блокировки просто запрещает грязное чтение,..., фантомы. Но не нашел, что он реально должен обеспечивать последовательный график.
Более того, вот вычитал, что последовательный график не гарантирует, что результаты применения всех вариантов последовательного выполнения заданного набора транзакций будут одинаковы.
Т.е. получается, что не все можно просто так поручить СУБД и пить пивко.
Должен быть разумный копромис наверное.
...
Рейтинг: 0 / 0
19.03.2005, 22:22
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969942
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
serg99
Участник
vadiminfoК сожалению, я все потер - покупал сегодня комп и закрутился. Потом вернусь еще к этим примерам. Но стараля закомитить. Более того следил за тем, чтобы в словаре БД транзакция изчезла и осталась только та первая.
Но надо бы повторить.
Но не понял что значит не читать атрибут? Ведь он читает запись. А атрибут только меняет. Просто в Вашем пример I = I+1, а Вы хотите I = Const? Мне пока кажется, что это ничего не должно изменить. Напишите в командах что Вы имеет в виду, вдруг я не совсем так Вас понял.
Да, сразу писать во второй транзакции константу и каждую транзакцию исполнять по отдельному коннекту.

Код: plaintext
1.
Trans1              Start Read1 Write1 Commit
Trans2     Start                                          Write1 Commit

Просто хотелось посмотреть насколько "умным" в Оракле является обнаружитель несериализуемости.

vadiminfo Насколько я понял Вашего коллегу в MS SQL выдается тоже ошибка.
Возможно. Насколько я понимаю "по честному" в широко распространенных СУБД уровень изоляции "сериализуемость" не реализован.

vadiminfoВот я писал Вам про оптимистическую блокировку. Там однозначно приложение запоминает данные после чтенися. Меняет их в приложении. Потом перед записью еще раз читает и сранивает. Если видит изменение, то выдант сообщение "Запись изменена другим пользователем". Это классика. И делает это не сервер.
На ошибку можно вообще по разному среагировать. Можно повторить транзакцию молча, а можно предупредить и дать возможность юзеру принять решение.
А если именно в то время как он сравнивает, кто то изменил запись? И что хорошего в упомянутой Вами классике, когда проблемы плохой изоляции транзакций на сервере вынуждено брать на себя приложение?

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

vadiminfoБолее того, вот вычитал, что последовательный график не гарантирует, что результаты применения всех вариантов последовательного выполнения заданного набора транзакций будут одинаковы.
Они и не должны быть одинаковы. Но при настоящей сериализуемости при любом варианте результаты всегда будут верными и при этом сервер не будет грузить приложение своими проблемами.

vadiminfoТ.е. получается, что не все можно просто так поручить СУБД и пить пивко. Должен быть разумный копромис наверное.
Беда похоже в том что поручить нельзя потому как СУБД этого не умеет. Если бы умела, то желающие поручить наверное нашлись бы.
...
Рейтинг: 0 / 0
20.03.2005, 02:28
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32969968
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
hvlad
Тут есть блокировка, но не такая, как у блокировочника - это блокировка не записи (логического объекта), а физической страницы

В Yukon блокировка именно записи
hvlad
Блокировка снимается сразу, не дожидаясь окончания тр-ции. Т.е. время её действия очень мало

Как это ? эксклюзивная блокировка не может сняться до окончания транзакции, так как транзакция может откатиться
hvlad
Отсюда можно заключить, что блокировочник вынужден запоминать много блокировок одновременно и действуют они достаточно долго - дольше, чем происходит собственно обновление записи, но у него не остаётся мусорных версий

Блокировочник держит блокировки ровно столько, сколько нужно в интересах транзакции. Если вы внутри транзакции обновляете миллион записей, то блокировка на первой записи будет висет и в тот момент, когда обновляется миллионная.
hvlad
При многопользовательской работе версионник однозначно будет меньше простаивать на блокировках и общая пропускная способность у него будет выше

Я уже третью страницу подряд обьясняю, что пропускная способность блокировочника или версионника зависит от ситуации
Markelenkov
Я не буду комментировать знание автором Oracle :)

Все написанное мной относиться только к Yukon. В Оракле я понимаю очень мало
Markelenkov
1. Как считает автор, есть ли разница (и велика ли она, если есть) в стоимости (скорости) установки и снятия блокировки с записи в первом и втором случаях?

Нет, с какой стати ?
Markelenkov
2. Предположим, в блокировочнике требуется выполнить транзакцию, скажем, из 5 вставок, 5 обновлений и 5 удалений строк. Предположим, на пятом удалении получена ошибка и требуется откатить все изменения, выполненные в данной транзакции. Где будет брать блокировочник старые версии данных?

В логе транзакций
vadiminfo
Мож у Вас там вылезет какой-нибудь сюрприз. Разве так не бывало?

Может и вылезет, но другой.
vadiminfo
Добавлю только что в 9 ни разу не натыкался еще на ORA-01555.

Вот вы знаете, я например, еще никогда на deadlock'и не натыкался. Это обстоятельство однако, не мешает ораклистам упоминать об блокировках к месту и не к месту.
vadiminfo
Поэтому тратить время на разборы не буду

Зря
vadiminfo
Давайте решим так: Вы будете пользоваться и тем и тем, а я только версионностью пользовался бы и в Юниконе, если бы на деле она оказалась не хуже, чем в Оракле. В противном случае я бы пользовался толтько блокировочностью в Юниконе.

если-бы разобрались с моим примером, то этого-бы не написали
vadiminfo
Пока продолжаю считать, что версионнасть такая как в Оракле исключает грязное чтение раз, и не позволяет заблокировать читающему пишущего. А блокировочник только одно из этих одновременно может делать. Кроме того, в Оракле не возможна эскалация блокировок.

Вот оно, вредное влияние Кайта ;)
Грязное чтение это не недостаток, а ловкий способ обойти другой недостаток, который вы указали. Другое дело, что пользоваться такой вещью нужно с умом. Собственно, вся версионность для того и нужна, чтобы такого недостатка не стало. Однако включив версионность, получаем другие недостатки.
А то, что отсутствие эсколации - это недостаток Оракла, я уже писал
...
Рейтинг: 0 / 0
20.03.2005, 08:33
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970035
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Markelenkov
Участник
StalkerS Markelenkov
1. Как считает автор, есть ли разница (и велика ли она, если есть) в стоимости (скорости) установки и снятия блокировки с записи в первом и втором случаях?

Нет, с какой стати ?
Понятно. Советую еще раз перечитать Кайта, а также подумать, что быстрее - заменить байт '00'x на '01'x, или вызывать диспетчер блокировок.

StalkerS Markelenkov
2. Предположим, в блокировочнике требуется выполнить транзакцию, скажем, из 5 вставок, 5 обновлений и 5 удалений строк. Предположим, на пятом удалении получена ошибка и требуется откатить все изменения, выполненные в данной транзакции. Где будет брать блокировочник старые версии данных?

В логе транзакций
И чем это принципиально отличается от способа хранения данных отката у Oracle?

P.S. Я прекрасно знаю недостатки, которые присущи версионности хранения данных в Oracle. Если взять главные и охарактеризовать их коротко то это:

1. Необходимость хранения ITL в блоках данных - на каждую 24 байта, минимум 1-2 на блок. То есть, дополнительные расходы памяти. Правда, из них 7 байт (fsc - free space credit) выполняют еще одну полезную функцию, кроме обеспечения механихзма версионности.

2. Необходимость создания cr (consistent read)-буферов - то есть, копируем в свободное место оперативной памяти текущее состояние блока и применяем инф-ию из сегментов отката. Во-первых, операция достаточно ресурсоемкая, во-вторых, может быть достаточно много клонов измененного блока - т.е. расходы оперативной памяти, нагрузка на защелки и т.д.

Собственно говоря, на этом и заканчиваются недостатки реализации версионности в Oracle по сравнению с ее нереализацией блокировочниками. Все остальное в какой-то разной степени есть и там, и там. Достоинства версионного механизма, думаю, доказывать не надо?

P.P.S.
Для того, чтобы оценивать уровень знаний Кайта, а тем более его ругать, нужно сначала свой уровень чуть приподнять над плинтусом. С этим и откланиваюсь...
...
Рейтинг: 0 / 0
20.03.2005, 13:33
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970081
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
StalkerS hvladТут есть блокировка, но не такая, как у блокировочника - это блокировка не записи (логического объекта), а физической страницы
В Yukon блокировка именно записиЭто блокировка дороже, чем блокировка физ.страницы, таких блокировок больше, чем блокировок страниц.
К тому же, я не уверен, что Yukon в версионном режиме создаёт именно блокировки записей и удерживает их до конца тр-ции.

StalkerS hvladБлокировка снимается сразу, не дожидаясь окончания тр-ции. Т.е. время её действия очень мало
Как это ? эксклюзивная блокировка не может сняться до окончания транзакции, так как транзакция может откатитьсяЯ же сказал - это другая блокировка. Она предотвращает доступ к памяти от одновременных модификаций, поэтому снимается сразу же после окончания модификации. Версионнику не нужно держать логические блокировки до окончания тр-ции, т.к. он версионник ;) Поэтому у него даже такого понятия нет, как блокировка записи.

StalkerS hvladОтсюда можно заключить, что блокировочник вынужден запоминать много блокировок одновременно и действуют они достаточно долго - дольше, чем происходит собственно обновление записи, но у него не остаётся мусорных версий
Блокировочник держит блокировки ровно столько, сколько нужно в интересах транзакции. Если вы внутри транзакции обновляете миллион записей, то блокировка на первой записи будет висет и в тот момент, когда обновляется миллионная.А версионник - держит блокировки ровно столько, сколько нужно для модификации страницы при создании версии записи. При обновлении миллиона записей версионник не будет держать одновременно более 1-ой блокировки страницы. Поэтому он и выигрывает при конкурентном доступе у блокировочника.

Всё что я пишу о версионнике, относится к IB\FB, так что ораклистов прошу понимать меня правильно :)
...
Рейтинг: 0 / 0
20.03.2005, 14:54
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970133
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
Markelenkov
Понятно. Советую еще раз перечитать Кайта, а также подумать, что быстрее - заменить байт '00'x на '01'x, или вызывать диспетчер блокировок.

А что именно вам стало понятно ? Еще раз говорю, я описывал Yukon , там установка этих блокировок одинакова в обоих случаях.
Если-же сравнивать, что лучше - диспетчер блокировок или хранение данных в блоках, то кроме указанных вами моментов, существуют и другие, о которых я говорил еще в своем первом посте.
Markelenkov
И чем это принципиально отличается от способа хранения данных отката у Oracle?

Тем, что при изменении данных, в Оракл, помимо генерации данных в сегменте отката, данные генерируются и в журнал повторного выполнения.
Markelenkov
Для того, чтобы оценивать уровень знаний Кайта, а тем более его ругать, нужно сначала свой уровень чуть приподнять над плинтусом

А может, это Кайту перестать демонстрировать недостатки блокировочников на совершенно бессовестных примерах ?
hvlad
Это блокировка дороже, чем блокировка физ.страницы, таких блокировок больше, чем блокировок страниц.

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

есть подозрение, что вы пытаетесь описать уровень snapshot !
...
Рейтинг: 0 / 0
20.03.2005, 16:23
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970183
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
StalkerS hvlad
Это блокировка дороже, чем блокировка физ.страницы, таких блокировок больше, чем блокировок страниц.
зато увеличивает паралелльный доступ. Если начинаются проблемы с ресурсами и пр. - происходит эскалация - так что никаких препятствий !Как долгоживущая блокировка может увеличить параллельность доступа ? Эскалация, насколько мне известно, служит только для уменьшения накладных расходов на поддержку большого числа мелких блокировок. И она никак не способствует увеличению параллельности доступа :)

StalkerS hvladЯ же сказал - это другая блокировка. Она предотвращает доступ к памяти от одновременных модификаций, поэтому снимается сразу же после окончания
есть подозрение, что вы пытаетесь описать уровень snapshot !shapshot есть наиболее естественный способ работы для версионника. Насколько я понял здесь сравниваются именно версионные механизмы работы ? :) К тому же, эксклюзивные блокировки накладываются при апдейтах и удерживаются до конца тр-ции независимо от её уровня изоляции, не так ли ?
...
Рейтинг: 0 / 0
20.03.2005, 17:47
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970208
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
2 serg99
Я еще раз проверил Ваш тот пример, на всякий случай. Все повторилось. Я просил Вас написать в виде инструкций SQL как сделал Dooma. Чтобы я точно понял. Вашу пару Read1 Write1 я интерпретировал как один update, и транзакции делал в разных сессиях. В новом примере у Вас один Write1 - это может быть только insert. Я обращал Ваше внимание, что для демонстрации того, что serializable в Оракле не означает последовательный график транзакций, пока я видел примеры только с инсертами. У Dooma и Кайта.

serg99
Возможно. Насколько я понимаю "по честному" в широко распространенных СУБД уровень изоляции "сериализуемость" не реализован.

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

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


Хорошо, что Вы обратили внимание. На время сравнения перед записью - заблокирует ее.
Насчет "вынуждено" и "плохая изоляция". Существуют несколько моделей транзакций. Кроме блокировок, например, построенные на временных отметках. Их потому и несколько, что каждая обладает какими-то недостатками. Иначе зачем другие, если одна во всех отношения хороша? Есть, например, критика Рел модели представителями ОО за то, что РСУБД ориентированы на короткие транзакции. Там речь об атомарности. Два часа кто-то генерил что-то, а оно все откатило (пропал двухчасовой труд чела).
Хотя дело не в Р модели, а в модели транзакций, так как Р модель не имеет таких ограничений. И есть и в Оракле средства откатывать не всю транзакцию - точки сохранения. И опять приложение "вынуждено" брать на себя, где ставить эту точку. Я говорил Вам свои мысли про разумный компромисс.
Вот Вы говорите, что лучшее из лучшего - последовательное выполнение транзакций. Но даже если бы это было возможно, то разве не пострадала бы идея параллельного доступа? Например, можно допускать только одну сессию. Открывать БД в эксклюзивном режиме. Что получится? Хотя несомненно последовательный график гарантирован.

serg99
Так он и не обеспечивает. В результате допускаются феномены не упоминаемые в стандарте SQL, но так же приводящие к некорректному состоянию БД или к отказам в транзакциях.

Феномены не упоминаемые в стандарте SQL нуждаются еще в исследованиях. И понятие корректности тогда тоже. Так как без стандартов, то что для одного корректно, то другой будет считать некорректным. Стандарт – как бы соглашение какое-то между всеми.
serg99
Они и не должны быть одинаковы. Но при настоящей сериализуемости при любом варианте результаты всегда будут верными и при этом сервер не будет грузить приложение своими проблемами.


Пардон. Я вас не понял. Если есть несколько результатов возможных, то ведь только один может быть верным? А мы даже не знаем какой получим. Т.е. получим потерю данных с большой вероятностью. Возможно, это говорит, что серверу - серверово, а приложению (в общем случае серверной его части) – приложеньево? Т.е. на сегодняшний день, возможно, не все это проблемы сервера.

serg99
Беда похоже в том что поручить нельзя потому как СУБД этого не умеет.

Ну или в том, что задача на оптимум: быстрый параллельный доступ и обеспечение всех требований к транзакциям. Они, наверное, противоречат друг другу.. Я говорил Вам, что парни придумываю разные модели транзакций. Делают на этом диссеры, наверное. Потому и СУБД не умеет, что есть, скорее всего, теор проблемы.

StalkerS
Может и вылезет, но другой.


Так я не говорил что именно этот. Более того, я как бы хотел намекнуть Вам, что этот другой, возможно, худший по частоте или вредоносности. Поэтому, конечно, другой.)

StalkerS
Вот вы знаете, я например, еще никогда на deadlock'и не натыкался. Это обстоятельство однако, не мешает ораклистам упоминать об блокировках к месту и не к месту.


Но поймите правильно. Ораклисты отвыкли от проблем с блокировками. Оракл отучил их. Но иногда им приходится иметь дело с другими СУБД. Где блокировки дают о себе знать к месту и не к месту. Как кости в рыбе, они все время попадаются там. И держут сессии конкретно. Там надо писать процедуры с учетом этого. Вот они и упоминают. А что делать?)

StalkerS
Зря

Ну как я грил - здесь компетенто многие другие разобрали. Во-вторых, я опять полезу Кайта читать, а он у Вас есть. В третьих, я же сказал Вам, что на практике проблемы производительности здесь не встают в Оракле. Полно других, на борьбу с которыми у Оракла многое нацелено. Те же блокировки. Если пишущего держит блокировка читающего, то о чем говорить? Да он прочтет чистые данные. Но пока пишущей ждал, Оракл в аналогичной ситуации все измения данных давно завешил. Что мы будем думать о том, кто быстрей в мелочевке, когда на практике другие реалии по проблемам производительности?

StalkerS
если-бы разобрались с моим примером, то этого-бы не написали


Написал бы. Потому что даже, если предположить что Ваш пример, что-то показывает в пользу блокировочника, есть другие убийственные вещи в пользу версионника: отсутвствие грязного чтения без необходимости блокировать пишущего. Это уже не тока у Кайта признается. И это перевесит тысячи других мелких преимуществ, даже если они есть. Вы же поймите, под блокировки надо писать приложения с их учетом – на логику влияют физические аспекты в болшей степени. А это ухудшает независимость уровней. А Вы говорите - переключу то в версионник, то в блокировочник. Нет придется еще проги переписывать отчасти. Вспомните у Кайта про «плохие привычки». Вы на него зря отрицательно настроились. Он бывший блокировочник и на высоком уровне. Все равно нам с Вами до него далеко. Чего уж там?

StalkerS
Вот оно, вредное влияние Кайта ;)
Грязное чтение это не недостаток, а ловкий способ обойти другой недостаток, который вы указали. Другое дело, что пользоваться такой вещью нужно с умом. Собственно, вся версионность для того и нужна, чтобы такого недостатка не стало. Однако включив версионность, получаем другие недостатки.
А то, что отсутствие эсколации - это недостаток Оракла, я уже писал


По этому вопросу не только Кайта, но еще и всяких толстых книг.
Мы тут с serg99 бьемся над какими-то заоблачными уровнями изоляции, для каких-то фантастических ситуаций в жизни БД оперативной обработки транзакций, а Вы говорите, что грязное чтение не недостаток? Оно же отрицает самае идею изолированности транзакций на корню, и не является недостатком? А тот бесхитростный способ обойти ее, описанный в любой книжке про СУБД, ловким способом? Вы меня разыгрываете? Нарочно сбиваете с толку? Чтобы я потом запутался окончательно?
Не знаю, что за недостаток в отсутствие эскалации блокировок в Оракле, но ее присутствие – там, где она есть недостаток, который перевисит много достоинств. Он просто способен навести ужас на иного разработчика и уже точно на конечного пользователя, и отбить всякую охоту. Он влияет на логику приложений и работу с БД вообще в худшую сторону. Нужно было заблокировать несколько записей, а заблокирована вся табла. Здорово. Не знаю, Вы первый кто мне сказал о ее пользе. В литре ничего подобного не видел. Да и сам термин эскалация подобран не случайно. Он звучит угрожающе. Разве нет?
...
Рейтинг: 0 / 0
20.03.2005, 18:20
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970263
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
serg99
Участник
vadiminfoЯ еще раз проверил Ваш тот пример, на всякий случай. Все повторилось. Я просил Вас написать в виде инструкций SQL как сделал Dooma. Чтобы я точно понял. Вашу пару Read1 Write1 я интерпретировал как один update, и транзакции делал в разных сессиях. В новом примере у Вас один Write1 - это может быть только insert. Я обращал Ваше внимание, что для демонстрации того, что serializable в Оракле не означает последовательный график транзакций, пока я видел примеры только с инсертами. У Dooma и Кайта.Конкретная реализация неважна. Важна последовательность начала транзакций и наличие соответствующих операций по чтению и записи одного и того же объекта данных. Если при одном Write во второй транзакции Oracle так же выдал ошибку, то скорее всего он обнаруживает ошибку сериализации по факту того что при коммите изменения (или непосредственно при создании новой версии) обнаруживается что предыдущая закоммиченная версия порождена транзакцией начавшейся позже. Хотя как раз в данном случае транзакции являются сериализуемыми в варианте t1, t2. То есть СУБД не только не берет на себя заботу об изоляции транзакций, но и перестраховывается в обнаружении конфликтов.

vadiminfo serg99
Возможно. Насколько я понимаю "по честному" в широко распространенных СУБД уровень изоляции "сериализуемость" не реализован.

Да, но почему этот уровень изоляции Вы трактуте как последовательный график? Хде это написано? Я пока не нашел. Я раньше считал, что он имеет практическое значение для больших чтений - чтобы правильный результат получить в отчетах, например. А про последовательный график писал Вам, что он не гарантирует одного результата, т.е. возможна потеря данных.Неодинаковый результат не означает потерю данных. Трактую я этот уровень изоляции исходя из его названия. Таким же образом уровень трактуется в стандарте SQL-2003. Если уровень не обеспечивает сериализуемости, зачем его называть Serializable? Назвали бы по честному Snapshot. Естественно разработчики коммерческих систем иногда из маркетинговых соображений под сериализумым уровнем изоляции понимают любой механизм обеспечивающий отсутствие известных феноменов.

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


Хорошо, что Вы обратили внимание. На время сравнения перед записью - заблокирует ее. А если кто то изменит запись после того как я ее прочитал, но еще не успел заблокировать? Получается нужно сразу читать с блокировкой (что собственно select for update и делает). Но с другой стороны для чего нужны СУБД как не для предоставления пользователю определенных сервисов по манипуляции данными. И если я прошу СУБД защитить мои транзакции от возможного вредоносного влияния со стороны транзакций других пользователей, то почему я должен еще защищаться от этого сам на уровне приложения и вообще думать об этом?


vadiminfoНасчет "вынуждено" и "плохая изоляция". Существуют несколько моделей транзакций. Кроме блокировок, например, построенные на временных отметках. Их потому и несколько, что каждая обладает какими-то недостатками. Иначе зачем другие, если одна во всех отношения хороша? Есть, например, критика Рел модели представителями ОО за то, что РСУБД ориентированы на короткие транзакции. Там речь об атомарности. Два часа кто-то генерил что-то, а оно все откатило (пропал двухчасовой труд чела).
Хотя дело не в Р модели, а в модели транзакций, так как Р модель не имеет таких ограничений. И есть и в Оракле средства откатывать не всю транзакцию - точки сохранения. И опять приложение "вынуждено" брать на себя, где ставить эту точку. Я говорил Вам свои мысли про разумный компромисс.
Вот Вы говорите, что лучшее из лучшего - последовательное выполнение транзакций. Но даже если бы это было возможно, то разве не пострадала бы идея параллельного доступа? Например, можно допускать только одну сессию. Открывать БД в эксклюзивном режиме. Что получится? Хотя несомненно последовательный график гарантирован.
Я не говорил что что то там лучше, потому что при этом мы сразу упремся в критерии лучшести. Настоящая сериализуемость лучше с точки зрения изоляции транзакций и соответственно лучше с точки зрения простоты прикладного ПО и отсутствия трудноуловимых ошибок при работе многопользовательских приложений. Однако это вполне может вести к общему снижению пропускной способности системы. И если для меня быстродействие важнее, а квалификация программистов достаточна, что бы на уровне приложения учесть все возможные проблемы связанные с конкурентным доступом, то я естественно откажусь от сериализуемости в пользу скажем read commited. Я просто о том что если "назвался груздем то полезай в кузов". Объявляешь наличие в СУБД уровня изоляции serializable, так обеспечивай его.

vadiminfoПардон. Я вас не понял. Если есть несколько результатов возможных, то ведь только один может быть верным? А мы даже не знаем какой получим. Т.е. получим потерю данных с большой вероятностью.
Допустим какой нибудь атрибут равен 4. Одна транзакция увеличивает значение атрибута на единицу, а другая умножает его на 2. При последовательности т1, т2 результат будет 10, а при последовательности т2,т1 - 9 и оба результата правильные.

vadiminfoНу или в том, что задача на оптимум: быстрый параллельный доступ и обеспечение всех требований к транзакциям. Они, наверное, противоречат друг другу.. Я говорил Вам, что парни придумываю разные модели транзакций. Делают на этом диссеры, наверное. Потому и СУБД не умеет, что есть, скорее всего, теор проблемы.Наверное плохие дисеры пишут :-). Проблемы конечно и практические и теоретические, но вполне решаемые.
...
Рейтинг: 0 / 0
20.03.2005, 20:50
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970278
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Scott Tiger
Участник
Объясните кретину - ну пусть Юкон в версионном режиме хранит версии данных в TempDB, он же не может хранить их там вечно? Иначе размер TempDB должен быть бесконечным. Значит, должен, просто-таки обязан существовать механизм получения юзером ошибки, аналогичной ORA-01555, т.к. вероятность перезаписи данных в TempDB ограниченного размера - ненулевая. Это раз. Двас - сегменты отката/undo-сегменты в Oracle замечательно растут и сдуваются при необходимости, а в 9i и выше - создаются и удаляются автоматически, равно как и для датафайлов таблеспейсов, задействованных под хранение undo-информации, можно поставить атрибут автоматического их расширения, буде нужно писать или долго держать много старых версий (если подобный функционал поддерживается ОС), а понимания, сколько нужно места, нет. Это не очень круто с точки зрения производительности (процесс будет ждать окончания расширения), да и есть определённые ограничения на размер каждого датафайла, но механизм такой имеется и нормально работает.
...
Рейтинг: 0 / 0
20.03.2005, 21:16
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970286
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Scott TigerОбъясните кретину - ну пусть Юкон в версионном режиме хранит версии данных в TempDB, он же не может хранить их там вечно?Не может, и не будет. Версии становятся ненужными после того, как завершатся все заинтересованные в них тр-ции. После этого их можно удалять.

Scott TigerИначе размер TempDB должен быть бесконечным. Значит, должен, просто-таки обязан существовать механизм получения юзером ошибки, аналогичной ORA-01555, т.к. вероятность перезаписи данных в TempDB ограниченного размера - ненулевая. Это раз.Кто сказал, что TempDB - ограниченного размера ? В пределах дисков - неограниченного :)
...
Рейтинг: 0 / 0
20.03.2005, 21:26
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970294
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Markelenkov
Участник
Scott TigerОбъясните кретину - ну пусть Юкон в версионном режиме хранит версии данных в TempDB, он же не может хранить их там вечно? Иначе размер TempDB должен быть бесконечным. Значит, должен, просто-таки обязан существовать механизм получения юзером ошибки, аналогичной ORA-01555, т.к. вероятность перезаписи данных в TempDB ограниченного размера - ненулевая.
Легко могу предположить, что из маркетинговых соображений не будет такой ошибки. А будет аналог ORA-600 :)

Типа, мы круче, у нас "snapshot too old" не бывает
...
Рейтинг: 0 / 0
20.03.2005, 21:44
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970295
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
hvlad
Как долгоживущая блокировка может увеличить параллельность доступа ? Эскалация, насколько мне известно, служит только для уменьшения накладных расходов на поддержку большого числа мелких блокировок. И она никак не способствует увеличению параллельности доступа :)

Внимательно прочитайте мой первый пост, и несколько следующих. Там очень доступно написано про эскалацию
hvlad
shapshot есть наиболее естественный способ работы для версионника. Насколько я понял здесь сравниваются именно версионные механизмы работы ? :) К тому же, эксклюзивные блокировки накладываются при апдейтах и удерживаются до конца тр-ции независимо от её уровня изоляции, не так ли ?

вначале, речь шла о сравнении работы механизмов Oracle и Yukon. При уровне snapshot транзакция не висит на блокировках, она просто меняет данные и все. Однако, если при попытке сохранить данные выясняется, что данные уже успел кто-то изменить, то транзакция откатывается, что гораздо дороже, чем если-бы она ждала на блокировке, как и происходит в Yukon и Oracle.
vadiminfo
Те же блокировки. Если пишущего держит блокировка читающего, то о чем говорить? Да он прочтет чистые данные.

Ладно, я уже понял, что вы не никак не хотите читать мои ответы. Жаль
vadiminfo
А Вы говорите - переключу то в версионник, то в блокировочник. Нет придется еще проги переписывать отчасти.

Краеугольный момент в том, что клиентские приложения переписывать не надо.
vadiminfo
Вы на него зря отрицательно настроились. Он бывший блокировочник и на высоком уровне. Все равно нам с Вами до него далеко. Чего уж там?

Да, далеко, особенно по части совести.
Что-бы вам стало более понятно, могу привести такой пример. Как вы отреагируете, если я когда-нибудь напишу книгу по базам данных, и в качестве примера плохой работы версионников приведу код, который в цикле фиксирует транзакции, в результате чего работает на порядок медленнее, и постоянно выдает ошибку ORA-01555 ? И сделаю вывод о том, что версионниками лучше не пользоваться, ибо работают медленно и все время лезут ошибки ?
vadiminfo
а Вы говорите, что грязное чтение не недостаток? Оно же отрицает самае идею изолированности транзакций на корню, и не является недостатком?

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

Я вам могу ответить только то-же, что сказал hvlad'у, прочитайте внимательно первые посты данного топика
...
Рейтинг: 0 / 0
20.03.2005, 21:45
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970308
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
StalkerSВнимательно прочитайте мой первый пост, и несколько следующих. Там очень доступно написано про эскалацию
Если речь о "Concurrency Control and Recovery in Database Systems", то у меня нет этого заочно уважаемого труда, и поэтому я не могу сказать, что там всё очень доступно. Если вы предоставите ссылки на упоминаемую теорему, то я хотя бы смогу понять - в каком контексте она применима.
Судя по реакции участников обсуждения (и по моему опыту, и опираясь на здравый смысл) - эскалация блокировок всё-таки та соломинка, без которой блокировочник не смог бы выжить в море конкурентных запросов

hvladshapshot есть наиболее естественный способ работы для версионника. Насколько я понял здесь сравниваются именно версионные механизмы работы ? :) К тому же, эксклюзивные блокировки накладываются при апдейтах и удерживаются до конца тр-ции независимо от её уровня изоляции, не так ли ?
вначале, речь шла о сравнении работы механизмов Oracle и Yukon. При уровне snapshot транзакция не висит на блокировках, она просто меняет данные и все. Однако, если при попытке сохранить данные выясняется, что данные уже успел кто-то изменить, то транзакция откатывается, что гораздо дороже, чем если-бы она ждала на блокировке, как и происходит в Yukon и Oracle.
[/quot]Нет. Тр-ция не откатывается. Отменяется текущий statement. Это две большие разницы.

Честно говоря, я вмешался в этот топик, т.к. увидел ваше недостаточное понимание механизма работы версионности. О чём мы спорим сейчас - я уже не понимаю, впрочем это часто бывает :)
...
Рейтинг: 0 / 0
20.03.2005, 22:28
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970373
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
serg99
Конкретная реализация неважна.

Важна для начала конкретная. А уже ее разультаты можно как-то трактовать.
Мне не ясно, что дает отсутсвие read в первой транзакции. Это инсетрт, который вообще никак не пересекается с апдэйтом второй транзакции? Или что?

serg99
Трактую я этот уровень изоляции исходя из его названия. Таким же образом уровень трактуется в стандарте SQL-2003.

Это интересно. Постараюсь узнать что-нибудь про это.

serg99
И если я прошу СУБД защитить мои транзакции от возможного вредоносного влияния со стороны транзакций других пользователей, то почему я должен еще защищаться от этого сам на уровне приложения и вообще думать об этом?

Нет в мире ничего совершенного. Почему комп вообще не читает наши мысли и не пишет сам прогг? Наверное потому, что как тока он научится, у нас пропадут эти мысли. Шутк.

serg99
Допустим какой нибудь атрибут равен 4. Одна транзакция увеличивает значение атрибута на единицу, а другая умножает его на 2. При последовательности т1, т2 результат будет 10, а при последовательности т2,т1 - 9 и оба результата правильные.

Допустим это Ваш счет в банке. Вы ожидали, что там будет 10 тыс баксов, но транзакции выполнились в последовательности т2,т1. И там стало вместо этого 9 тыс. Вы по прежнему будете считать этот результат тоже правильным?
Ну, тогда я не знаю.

StalkerS
Ладно, я уже понял, что вы не никак не хотите читать мои ответы. Жаль

Но Вы тоже на мои не обращаете внимания.

StalkerS
Краеугольный момент в том, что клиентские приложения переписывать не надо.

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


StalkerS
Что-бы вам стало более понятно, могу привести такой пример. Как вы отреагируете, если я когда-нибудь напишу книгу по базам данных, и в качестве примера плохой работы версионников приведу код, который в цикле фиксирует транзакции, в результате чего работает на порядок медленнее, и постоянно выдает ошибку ORA-01555 ? И сделаю вывод о том, что версионниками лучше не пользоваться, ибо работают медленно и все время лезут ошибки ?


Буду проверять так или нет. Обращаться к разным источникам. Но буду считать, что такое мнение есть в литре. У меня чисто прагматический интерес - что-то узнать. В том числе и про недостатки Оракла. Уверен, что полно критики Оракла.
Если Вы ошибетесь, то Вы можете снизить доверие к Вашему труду. Это Ваш выбор. Тогда может он вообще не будет известен.

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

Вопрос в том, стали бы они пользоваться этим недостатком, если бы им можно было бы не пользоваться, не подвешивая систему (как в версионнике).
Что еще за приблизительные данные? Насколько приблизительные? Грязное чтение может сделать эту приблизительность очень маленькой - т.е. выдать прямо противоположный результат, поскольку оно, скорее всего, малопредсказуемо. Не считать же ее погрешность в самом деле? Кроме того, приблизительность для типовых приложений БД - редкая роскошь.

StalkerS
Я вам могу ответить только то-же, что сказал hvlad'у, прочитайте внимательно первые посты данного топика

Прочитал. Во-первых. Если даже какой-то разработчик сочтет нужным заблокировать всю таблу, то такая возможность в Оракле у него есть . Во-вторых Ваш пример не до конца ясен. Ведь если там много транзакций и заблокируются все, в том числе и те, которые можно не блокировать, то вряд ли это улучшит ситуацию. Но и вообще это все пока предположения. Цифры нужно было Вам привести. Для этого нужно экспериментировать с Ораклом. А так это всего лишь предположение, и не совсем очевидное. А пока, кажется, что эскалация блокировок - это все-таки, скорее всего, больше - очень плохое, чем просто плохое. И нужно оно тока в блокировочнике из-за того, что без этого все будет еще хуже. Либо не предсказуемый результат, либо все затормозится из-за непомерных объемов для хранения инфы про все блокировки в таблице блокировок. Всех процедур с этим связанных. Всякие проверки заблокирована запись или нет, и все такое.
...
Рейтинг: 0 / 0
21.03.2005, 02:18
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970433
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторА пока, кажется, что эскалация блокировок - это все-таки, скорее всего, больше - очень плохое, чем просто плохое. И нужно оно тока в блокировочнике из-за того, что без этого все будет еще хуже. Либо не предсказуемый результат, либо все затормозится из-за непомерных объемов для хранения инфы про все блокировки в таблице блокировок. Всех процедур с этим связанных. Всякие проверки заблокирована запись или нет, и все такое.
С учетом того, что у меня в ASA эскалации нет, однако без всяких затрат ресурсов и потери производительности на уровне ROWLOCK спокойно проходят блокировки на десятки миллионов записей, лично мне думается, что эскалация - это частное решение для оптимизации работы механизма блокировок определенной СУБД - MSSQL и блокировочники с другой архитектурой имеют свои способы оптимизировать блокировки. Например в ASA во первых есть явный оператор LOCK TABLE, во вторых все блокировки честно идут на уровне ROWLOCK и впервую очередь они завязываются на уникальные индексы, кроме уровня изоляции SERIALIZABLE - там с целью понижения накладных расходов и большей гарантии правильной работы изоляции блокировки идут на уровне PAGELOCK, что однако все равно не мешает продолжать другим сессиям вставлять новые записи и при наличие граммотно подобранного кластерного ключа снижает вероятность блокировки на этом уровне изоляции не попадающих других записей.
...
Рейтинг: 0 / 0
21.03.2005, 07:43
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970469
Zaxx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Zaxx
Гость
hvlad Версионнику не нужно держать логические блокировки до окончания тр-ции, т.к. он версионник ;) Поэтому у него даже такого понятия нет, как блокировка записи.
...
А версионник - держит блокировки ровно столько, сколько нужно для модификации страницы при создании версии записи. При обновлении миллиона записей версионник не будет держать одновременно более 1-ой блокировки страницы. Поэтому он и выигрывает при конкурентном доступе у блокировочника.

Всё что я пишу о версионнике, относится к IB\FB, так что ораклистов прошу понимать меня правильно :)

Вы таки хотите сказать что IB\FB не блокирует изменённую запись до завершения транзакции ?????????????
...
Рейтинг: 0 / 0
21.03.2005, 08:28
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970622
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ZaxxВы таки хотите сказать что IB\FB не блокирует изменённую запись до завершения транзакции ?????????????Да. Только на время изменения. И не запись, а страницу, на которой она лежит.
Это так сложно для понимания ?
...
Рейтинг: 0 / 0
21.03.2005, 10:25
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970636
Dooma
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dooma
Гость
Всем, кто интересуется версионностью в Yukon, советую почитать статью Версионность в Yukon
Там все доходчиво изложено.
Теоритически, очень не плохо, практически, поживем - увидим.
...
Рейтинг: 0 / 0
21.03.2005, 10:30
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970668
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
DoomaВсем, кто интересуется версионностью в Yukon, советую почитать статью Версионность в Yukon
Там все доходчиво изложено.
Merle, к сожалению, в утверждениях переоценивает общность своих знаний. То, что он рассказывает про MSSQL интересно, но его слова про другие сервера стоит воспринимать аккуратно - достаточно упомянуть, что он однажды отождествил оракловые ROWNUM и ROWID.
...
Рейтинг: 0 / 0
21.03.2005, 10:42
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32970680
Dooma
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dooma
Гость
авторMerle, к сожалению, в утверждениях переоценивает общность своих знаний. То, что он рассказывает про MSSQL интересно, но его слова про другие сервера стоит воспринимать аккуратно - достаточно упомянуть, что он однажды отождествил оракловые ROWNUM и ROWID.Я не знакомый Merle, но слышал, что этот чел общается с разработчиками из MS. Пусть Merle поправит, если что не так.
И в чем в чем, а в MS ему можно доверять. А с Oracle вы и сами в состоянии сравнить.
...
Рейтинг: 0 / 0
21.03.2005, 10:50
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32971382
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
serg99
Участник
vadiminfoВажна для начала конкретная. А уже ее разультаты можно как-то трактовать.
Мне не ясно, что дает отсутсвие read в первой транзакции. Это инсетрт, который вообще никак не пересекается с апдэйтом второй транзакции? Или что?
В моем примере я просил убрать Read не в первой, а во второй транзакции. Тогда транзакции становятся сериализуемыми t1,t2 и "умная" СУБД не выдала бы ошибку "конфликт сериализации".

vadiminfo Допустим это Ваш счет в банке. Вы ожидали, что там будет 10 тыс баксов, но транзакции выполнились в последовательности т2,т1. И там стало вместо этого 9 тыс. Вы по прежнему будете считать этот результат тоже правильным?
Ну, тогда я не знаю.
Я не ожидаю конкретного состояния счета. Я ожидаю что в рамках правил операций с моим счетом его состояние будет правильным. Если кто то удвоил состояние счета (положил 4 тысячи), а потом кто то имеющий право работать со счетом доложил еще 1 тысячу, то на счету будет 9 тысяч и это правильно (в общей сложности положено 5 тысяч). А вот если оба считали состояние счета как 4 тысячи, а второй закоммитился позже первого, то на счету будет 5 тысяч. То есть на счету было 4 тысячи, добавили туда еще 5 тысяч и в результате получилось 5 тысяч. Вот это как раз неправильно (пропали 4 тысячи рублей).
...
Рейтинг: 0 / 0
21.03.2005, 14:32
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32971455
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
hvlad
Нет. Тр-ция не откатывается. Отменяется текущий statement. Это две большие разницы.
... т.к. увидел ваше недостаточное понимание механизма работы версионности

Либо snapshot в Оracle и Yukon отличается от такового в Интербейс, либо это у вас недостаточное понимание механизма ;)
hvlad
Если вы предоставите ссылки на упоминаемую теорему, то я хотя бы смогу понять - в каком контексте она применима.

vadiminfo
Цифры нужно было Вам привести. Для этого нужно экспериментировать с Ораклом. А так это всего лишь предположение

вот вам обоим ссылка на книжку
Там кстати, в конце каждой главы перечислено множество других трудов, гораздо долее монументальных, на которых основана данная книга
vadiminfo
Например, если блокировочник вынуждает часто коммитить, и разбивать логически единую транзакцию на большое количество мелких транзакций, чтобы повысить призводительность

Вот один в один случай, который я привел в первом посте. У Кайта это прочитали, я знаю. Так вот поверьте, что это глупость, никто никогда не станет разбивать транзакцию на куски, ставя под угрозу целостность данных (я имею ввиду адекватных программистов)
vadiminfo
Буду проверять так или нет. Обращаться к разным источникам. Но буду считать, что такое мнение есть в литре

Замечательная позиция. А теперь, почему-бы вам не почитать что-нибудь про mssql, и получить собственную позицию по нему, а не клонированные мысли Кайта ?
vadiminfo
Кроме того, приблизительность для типовых приложений БД - редкая роскошь.

в том числе поймете, что за зверь такой, этот dirty read, и с чем его едят
...
Рейтинг: 0 / 0
21.03.2005, 14:57
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32971499
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
авторТак вот поверьте, что это глупость, никто никогда не станет разбивать транзакцию на куски, ставя под угрозу целостность данных (я имею ввиду адекватных программистов)

извиняюсь, но вам верить - себя неуважать ...

Of course, committing frequently to release locks has a cost. The commit frequency must be a compromise between availability and concurrency of data, and also performance of DB2 applications.
(C) IBM
дальше почитайте 5.1.3 When to Commit?
http://www.redbooks.ibm.com/redbooks/pdfs/sg244725.pdf
...
Рейтинг: 0 / 0
21.03.2005, 15:14
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32971529
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
StalkerS hvlad
Нет. Тр-ция не откатывается. Отменяется текущий statement. Это две большие разницы.
... т.к. увидел ваше недостаточное понимание механизма работы версионности
Либо snapshot в Оracle и Yukon отличается от такового в Интербейс, либо это у вас недостаточное понимание механизма ;)Сервер сам откатывает тр-цию только в 1 случае - физическая невозможность её продолжить (обрыв соединения, катастрофический сбой и т.п.) Если это не так - прощайтесь с таким сервером. MSSQL откатывает именно statement , по крайней мере при конфликте блокировок.

Если вы всегда работаете с неявными тр-циями, это не значит, что между statement и transaction можно поставить знак ==

StalkerS hvladЕсли вы предоставите ссылки на упоминаемую теорему, то я хотя бы смогу понять - в каком контексте она применима.

vadiminfoЦифры нужно было Вам привести. Для этого нужно экспериментировать с Ораклом. А так это всего лишь предположение
вот вам обоим ссылка на книжку Спасибо за ссылку, но ожидать, что я прочту 23M (это в архиве !) на английском за обозримое время (для поддержания этой дискуссии) - по меньшей мере наивно :)
С таким же успехом я могу дать ссылку на исходники IB - там меньше и язык проще

Формулировку теоремы привести можете ?
...
Рейтинг: 0 / 0
21.03.2005, 15:23
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32971769
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
serg99
В моем примере я просил убрать Read не в первой, а во второй транзакции. Тогда транзакции становятся сериализуемыми t1,t2 и "умная" СУБД не выдала бы ошибку "конфликт сериализации".

Почему Вы не хотите написать как это сделал Dooma в инструкциях на стандартном языке? я бы давно уже проверил. А так нужно догадывться и все равно есть риск, что не совсем так понял. Ведь мне писать нужно - не желательно в холостую.

serg99
Я не ожидаю конкретного состояния счета.

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

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

Посморю. Спасибо. Вы уверены, что там есть про пользу Ораклу от эскалации блокировок в некоторых случаях? Никаких других роешений нет?

StalkerS
Вот один в один случай, который я привел в первом посте. У Кайта это прочитали, я знаю. Так вот поверьте, что это глупость, никто никогда не станет разбивать транзакцию на куски, ставя под угрозу целостность данных (я имею ввиду адекватных программистов)

Да у Кайта - это Вы как в воду глядели. Хорошо, но я видел другое. Блокировки их замучали и они делали не так как Вы говорите. Ну пусть они не опытные. Но у нас с Вами Рел модель - одно из ее достоинств - меньшие требования к квалификации.

StalkerS
Замечательная позиция. А теперь, почему-бы вам не почитать что-нибудь про mssql, и получить собственную позицию по нему, а не клонированные мысли Кайта ?

Я на, самом деле, стараюсь читать общие книги по БД. И их у меня больше, чем по Ораклу. Мне важно где находится Оракл по отношению к другим СУБД.
Конкретно по mssql я читал когда-то справки. Правда это был 7. И даже меня иногда приглашали, када что-то долго нее получалось. Потому видел как они работают. Ход их мысли. Как могу, и с Вашей помощью в том числе, стараюсь быть в курсе и про mssql. Без этого форума, например, не знал бы про Юникон вообще в настоящее время. ТО что я не со всем соглашаюсь еще не значит, что я не пытаюсь найти какие-то рациональные зерна для себя.

StalkerS
в том числе поймете, что за зверь такой, этот dirty read, и с чем его едят
Боюсь, что не пойму до тех пор, пока не будет точно установлено, что свойство транзаций - изолированость является необыкновенно вредной идеей.
Пока, однако, все обстоит иначе. И думаю, что если mssql станет истинным версионником (в поздних версиях Юникона), то появятся книжки по mssql, в которых будут говорить - какая гадость это ваше грязное чтение.
...
Рейтинг: 0 / 0
21.03.2005, 16:26
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32971916
Юкон...
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Юкон...
Гость
Я не Юникон - я Юкон!
...
Рейтинг: 0 / 0
21.03.2005, 17:03
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32972381
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
Yo!!
извиняюсь, но вам верить - себя неуважать ...

Это ваше право !
и вообще, при чем здесь DB2
hvlad
Сервер сам откатывает тр-цию только в 1 случае - физическая невозможность её продолжить (обрыв соединения, катастрофический сбой и т.п.) Если это не так - прощайтесь с таким сервером. MSSQL откатывает именно statement, по крайней мере при конфликте блокировок.

не, что-то вы совсем запутались, и других пытаетесь ;)
При уровне изоляции snapshot (Yukon) или serializable (Oracle), транзакции при конфликте версий откатываюся.
Если-же стоит уровень read committed, то изменяющая транзакция будет ждать на блокировке, пока другая изменяющая транзакция не зафиксируется.
hvlad
Спасибо за ссылку, но ожидать, что я прочту 23M (это в архиве !) на английском за обозримое время (для поддержания этой дискуссии) - по меньшей мере наивно :)

во-первых, все читать совершенно не обязательно (особенно про recovery)
во-вторых, английский язык полезно знать ;)
в-третьих, вот здесь все разжевано по-русски и в гораздо меньшем обьеме
vadiminfo
Посморю. Спасибо. Вы уверены, что там есть про пользу Ораклу от эскалации блокировок в некоторых случаях? Никаких других роешений нет?

посмотрите вышеуказанную ссылку, хотя там все на примере mssql
vadiminfo
Да у Кайта - это Вы как в воду глядели.

не в воду, а в книгу Кайта ;)
vadiminfo
Блокировки их замучали и они делали не так как Вы говорите. Ну пусть они не опытные. Но у нас с Вами Рел модель - одно из ее достоинств - меньшие требования к квалификации.

Это где вы такое достоинство выкопали ?
Конечно, если посадить студента-двоечника проектировать финансовую систему банка, то такой банк долго не проживет.
С другой стороны, конечно, все мы начинали с азов, и продолжаем узнавать что-то каждый день. Поэтому всегда возможны крайности, например использование транзакций там где не надо (берут и заворачивают огромную ХП в транзакцию, в результате чего deadlock'ки плодяться как тараканы), или указанный выше пример с разрубанием действительно нужной транзакции на части, в результате чего дэдлоки изчезают, зато дебет начинает не сходиться с кредитом. Но сервер в этом обвинять все-таки нельзя !
vadiminfo
ТО что я не со всем соглашаюсь еще не значит, что я не пытаюсь найти какие-то рациональные зерна для себя.

аналогично
vadiminfo
то появятся книжки по mssql, в которых будут говорить - какая гадость это ваше грязное чтение.

с появлением версионности, использование грязного чтения и в самом деле должно скатиться практически к нулю, так как немногим сложнее можно получить полностью согласованную картину. Тем не менее, не забывайте, что не все работают в банках, и далеко не все отчеты требуют точных цифр.
...
Рейтинг: 0 / 0
21.03.2005, 21:28
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32972641
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
StalkerS
не, что-то вы совсем запутались, и других пытаетесь ;)
При уровне изоляции snapshot (Yukon) или serializable (Oracle), транзакции при конфликте версий откатываюся.
Если-же стоит уровень read committed, то изменяющая транзакция будет ждать на блокировке, пока другая изменяющая транзакция не зафиксируется.


Не знаю как в Юконе, а в Oracle идет нормальный exception. Это означает, что окатывается только ОПЕРАТОР, вызвавший ошибку. Конечно программист может обработать исключение по разному, но то что ПРОГРАММИСТ вызовет rollback при обработке исключения, не означает что Oracle при возникновении ошибки откатывает всю транзакцию.

Так-что это Вы слегка запутались
...
Рейтинг: 0 / 0
22.03.2005, 08:05
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32972738
Zaxx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Zaxx
Гость
Вы таки хотите сказать что IB\FB не блокирует изменённую запись до завершения транзакции ?????????????

hvlad Да. Только на время изменения. И не запись, а страницу, на которой она лежит.
Это так сложно для понимания ?

Понять это действительно сложно, ибо :

1. Без блокировки изменённой записи при коммитите уже позно разруливать чьи изменения нужно принимать. Чьи изменения ,по вашему, нужно принимать при коммите ??? Первого или последнего изменившего запись ?? А что делать тому кто пролетел ?

2. Берём FB1.5... в одной сессии говорим
Код: plaintext
update org set notes='ГЫ' WHERE CLIENT_UID='54d8ad103b004ba0a7f7121ceb5d9fad'
не коммитим.

Берём вторую сесиию : говорим
Код: plaintext
update org set notes='ГЫ' WHERE CLIENT_UID='54d8ad103b004ba0a7f7121ceb5d9fad'
и получаем :
Код: plaintext
1.
Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
lock conflict on no wait transaction. deadlock. update conflicts with concurrent update.

Это то что вы называете "нет блокировок" ?????????????????
...
Рейтинг: 0 / 0
22.03.2005, 09:29
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32972870
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
StalkerS hvlad
Сервер сам откатывает тр-цию только в 1 случае - физическая невозможность её продолжить (обрыв соединения, катастрофический сбой и т.п.) Если это не так - прощайтесь с таким сервером. MSSQL откатывает именно statement, по крайней мере при конфликте блокировок.
не, что-то вы совсем запутались, и других пытаетесь ;)
При уровне изоляции snapshot (Yukon) или serializable (Oracle), транзакции при конфликте версий откатываюся.
Если-же стоит уровень read committed, то изменяющая транзакция будет ждать на блокировке, пока другая изменяющая транзакция не зафиксируетсяДуэль, дуэль
Итак, следственный эксперимент:

Сессия №1
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
select @@version

use tempdb

create table t (id int)
insert into t values ( 1 )

set lock_timeout  1000 
set transaction isolation level serializable

begin tran
insert into t values ( 2 )
update t set id = - 1  where id =  1 

select * from t

Её результаты
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
Microsoft SQL Server   2000  -  8 . 00 . 760  (Intel X86) 
	Dec  17   2002   14 : 22 : 05  
	Copyright (c)  1988 - 2003  Microsoft Corporation
	Standard Edition on Windows NT  5 . 0  (Build  2195 : Service Pack  4 )


( 1  row(s) affected)


( 1  row(s) affected)


( 1  row(s) affected)


( 1  row(s) affected)

id          
----------- 
         - 1  
           2  

( 2  row(s) affected)

Здесь таблица t заблокирована

Сессися №2
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
use tempdb

create table t2 (id int)

set lock_timeout  1000 
set transaction isolation level serializable

begin tran
insert into t2 values ( 1000 ) -- (1)

insert into t values ( 3 )
update t set id = - 2  where id =  2  -- (2)

select * from t
select * from t2
commit

По вашим словам, оператор (2) должен откатить всю тр-цию, в том числе оператор (1). Смотрим результаты
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
( 1  row(s) affected)

Server: Msg  1222 , Level  16 , State  54 , Line  1 
Lock request time out period exceeded.
Server: Msg  1222 , Level  16 , State  54 , Line  1 
Lock request time out period exceeded.
Server: Msg  1222 , Level  16 , State  54 , Line  1 
Lock request time out period exceeded.
id          
----------- 
        1000  

( 1  row(s) affected)
Итак - 3 попытки доступа к заблокированной таблице t отвергнуты, но запись в t2 спокойно вставлена и тр-ция фиксирована.

Ась ?

Можете повторить на Юконе или на Оракле, дарю

StalkerS hvlad
Спасибо за ссылку, но ожидать, что я прочту 23M (это в архиве !) на английском за обозримое время (для поддержания этой дискуссии) - по меньшей мере наивно :)

во-первых, все читать совершенно не обязательно (особенно про recovery)
во-вторых, английский язык полезно знать ;)
в-третьих, вот здесь все разжевано по-русски и в гораздо меньшем обьемеВо-первых, я не собираюсь качать кучу неизвестно чего, неизвестно для чего, уж извините.
Во-вторых, с английским на этом уровне я проблем не испытаваю, спасибо за совет
В третьих - я схожу туда... чуть позже :)
...
Рейтинг: 0 / 0
22.03.2005, 10:22
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32972894
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
Gluk (Kazan)
Так-что это Вы слегка запутались

Про Оракл утверждать не буду, но вот что написано про такие транзакции в статье про версионность в Yukon (ссылка есть выше)
Получается, serializable в Oracle не полный эквивалент snapshot

///////////////////
Все это очень хорошо работает при читающих запросах, однако при записи могут возникать конфликты. Если при выполнении обновления snapshot-транзакция доберется до записи, заблокированной другой транзакцией, то, возникнет конфликт версий. Если блокирующая транзакция успешно фиксируется, в чистом версионнике snapshot-транзакция откатывается, поскольку если она изменит данные более «молодой» транзакции и продолжит работу, вполне возможен феномен утерянного обновления. Сместить эти транзакции друг относительно друга во времени и считать snapshot-транзакцию более «молодой» тоже не получится, так как блокирующая транзакция могла добавить записи, удовлетворяющие условию выборки snapshot-транзакции, а значит, все snapshot-запросы должны были эти записи увидеть. То есть snapshot-транзакция все равно должна выполниться заново, с более поздней временной меткой, чтобы увидеть все изменения, внесенные блокирующей транзакцией.
//////////////////////
...
Рейтинг: 0 / 0
22.03.2005, 10:33
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32972904
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
2 hvlad
с вашим ответом разберусь вечером, а то обед кончается, а нада еще поесть ;)
...
Рейтинг: 0 / 0
22.03.2005, 10:35
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32972906
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ZaxxВы таки хотите сказать что IB\FB не блокирует изменённую запись до завершения транзакции ?????????????Сколько раз мне это повторить ? Столько, сколько знаков вопроса ?


Zaxx hvlad Да. Только на время изменения. И не запись, а страницу, на которой она лежит.
Это так сложно для понимания ?

Понять это действительно сложно, ибо :

1. Без блокировки изменённой записи при коммитите уже позно разруливать чьи изменения нужно принимать.
Чьи изменения ,по вашему, нужно принимать при коммите ??? Первого или последнего изменившего запись ?? А что делать тому кто пролетел ? Может быть только одна активная (незакоммиченная) версия записи. Вторая попытка создать версию будет или ждать завершения первой тр-ции,
или отвалится сразу с сообщением lock conflict (см. ниже ;) - это зависит от режима wait\no_wait второй тр-ции.

Zaxx2. Берём FB1.5... в одной сессии говорим
Код: plaintext
update org set notes='ГЫ' WHERE CLIENT_UID='54d8ad103b004ba0a7f7121ceb5d9fad'
не коммитим.

Берём вторую сесиию : говорим
Код: plaintext
update org set notes='ГЫ' WHERE CLIENT_UID='54d8ad103b004ba0a7f7121ceb5d9fad'
и получаем :
Код: plaintext
1.
2.
3.
4.
Unsuccessful execution caused by system error that does not preclude successful execution of 
subsequent statements.
lock conflict on no wait transaction. 
deadlock. 
update conflicts with concurrent update.

Это то что вы называете "нет блокировок" ?????????????????А где тут про блокировки, причём записей ? Здесь сказано о конфликте обновления, что полностью согласуется с моими словами выше.

А может вам в FAQ сходить ? Здесь этого навалом
...
Рейтинг: 0 / 0
22.03.2005, 10:35
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32972913
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
Все принимаем на веру ? А самому проверить не судьба ???
Вы поняли автора слишком буквально Как правило, особенно начинающие разработчики, реагируют на подобный exception откатом транзакции. Но при чем тут Oracle и Yukon ??? Кстати, выше приведен пример работы Юкона если я не ошибаюсь :)
...
Рейтинг: 0 / 0
22.03.2005, 10:37
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32972922
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
StalkerSПро Оракл утверждать не буду, но вот что написано про такие транзакции в статье про версионность в Yukon (ссылка есть выше)
StalkerS...Если блокирующая транзакция успешно фиксируется, в чистом версионнике snapshot- транзакция откатываетсяАвтор статьи должен признать, что имел в виду оператор, а не тр-цию.
...
Рейтинг: 0 / 0
22.03.2005, 10:40
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32972929
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
StalkerS2 hvlad
с вашим ответом разберусь вечером, а то обед кончается, а нада еще поесть ;)У кого обед заканчивается, а у кого завтрак ещё не переварился
...
Рейтинг: 0 / 0
22.03.2005, 10:41
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32973101
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
StalkerS
посмотрите вышеуказанную ссылку, хотя там все на примере mssql

Ссылку посмотрю. Но звучало так, что якобы и Ораклу есть польза от ЭБ. Я про то, что ,возможно, у Оракла для решений проблем, найдутся другие решения, кроме ЭБ. Так как от ЭБ все-таки все еще ожидается много вреда. Т.е. такое лекарство может оказаться хуже болезни.

StalkerS
Это где вы такое достоинство выкопали ?
Конечно, если посадить студента-двоечника проектировать финансовую систему банка, то такой банк долго не проживет.

Ну как это где? Вот за иерархическую или сетевую БД (а возможно и ООСУБД) посадить студента двоечника совсем сложно - банк бы вообще бы не дождался никогда системы.
Вот в чем краегольный камень успеха РМД в плане продвижения на рынке.
А Вы говорите.
...
Рейтинг: 0 / 0
22.03.2005, 11:23
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32973119
Zaxx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Zaxx
Гость
hvladМожет быть только одна активная (незакоммиченная) версия записи. Вторая попытка создать версию будет или ждать завершения первой тр-ции,
или отвалится сразу с сообщением lock conflict (см. ниже ;) - это зависит от режима wait\no_wait второй тр-ции.

Дык это по вашему не блокировка ????

hvladА где тут про блокировки, причём записей ? Здесь сказано о конфликте обновления, что полностью согласуется с моими словами выше.

Дык, а что-же тут блокируетcя ??? Именно запись. Она заблокирована для записи другой сессией. И называется это именно блокировка, а не "конфликт обновления".

Если вы говорите про отсутствие блокировок "по чтению", то во первых надо указывать явно что речь идёт именно о блокировании/неблокировании читателя, а во вторых это (отсутсвие блокировок читателей в версионниках) и ежу понятно (на он он и версионник).
...
Рейтинг: 0 / 0
22.03.2005, 11:28
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32973209
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Zaxx hvladМожет быть только одна активная (незакоммиченная) версия записи. Вторая попытка создать версию будет или ждать завершения первой тр-ции,
или отвалится сразу с сообщением lock conflict (см. ниже ;) - это зависит от режима wait\no_wait второй тр-ции.

Дык это по вашему не блокировка ????Нет. Ни по какому. Это - ожидание завершения конкурирующей тр-ции. Блокировкой записи тут не пахнет, абсолютно. Это может быть похоже на блокировку записи, но это не так, совсем.
Если я в одной тр-ции сделаю апдейт миллиону записей, то у меня не возникнет миллиона блокировок записей. Так понятнее ?

Zaxx hvladА где тут про блокировки, причём записей ? Здесь сказано о конфликте обновления, что полностью согласуется с моими словами выше.

Дык, а что-же тут блокируетcя ??? Именно запись. Она заблокирована для записи другой сессией. И называется это именно блокировка, а не "конфликт обновления"Нет. В IB\FB нет ни понятия, ни механизма блокирования записи (в смысле создания объекта "блокировка записи" и работы с ним). Сколько можно воду в ступе толочь ? Вы читали хоть что-нибудь о MGA ?

ZaxxЕсли вы говорите про отсутствие блокировок "по чтению", то во первых надо указывать явно что речь идёт именно о блокировании/неблокировании читателя, а во вторых это (отсутсвие блокировок читателей в версионниках) и ежу понятно (на он он и версионник).Я говорю только то, что я говорю. Не нужно проводить аналогии с блокировочниками, тем более не корректные.
...
Рейтинг: 0 / 0
22.03.2005, 11:54
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32973266
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
hvladЕсли я в одной тр-ции сделаю апдейт миллиону записей, то у меня не возникнет миллиона блокировок записей. Так понятнее ?
Вы спорите ни о чем. Знаете старую фразу - "если нечто плавает как утка, крякает как утка и несет утиные яйца, значит это утка"?

В Вашем случае возникнет миллион незакоммиченных версий. Причем, сидя в SQL-консоли, отличить их от блокировок будет достаточно трудно - они "крякают как блокировки".
...
Рейтинг: 0 / 0
22.03.2005, 12:11
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32973315
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
softwarer hvladЕсли я в одной тр-ции сделаю апдейт миллиону записей, то у меня не возникнет миллиона блокировок записей. Так понятнее ?Вы спорите ни о чемДа, так бывает :) Больше не буду, тем более что смысла в этом не вижу.

softwarerЗнаете старую фразу - "если нечто плавает как утка, крякает как утка и несет утиные яйца, значит это утка"?А если оно ещё и прыгает, как заяц ? И имеет жабры ?
Метод аналогий как правило ведёт в сторону и нечего не доказывает

softwarerВ Вашем случае возникнет миллион незакоммиченных версий И что ? У блокировочника будет 2 миллиона в transaction log'е - 1М inserted и 1М deleted

softwarerПричем, сидя в SQL-консоли, отличить их от блокировок будет достаточно трудно - они "крякают как блокировки".Они не крякают как блокировки хотя бы потому, что это
1. не блокировки (сколько можно говорить ?)
2. они не жрут память, как миллион блокировок
3. поэтому не нужна их эскалация
...
N. См. п1 :)

дальше спорить лень.

Не вижу смысла убеждать что белое-это белое, а чёрное - это чёрное.
...
Рейтинг: 0 / 0
22.03.2005, 12:27
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32973345
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
hvladА если оно ещё и прыгает, как заяц ? И имеет жабры ?
Значит, оно отличается от X в сфере прыжков. И не отличается в плане плавания.

hvlad
softwarerВ Вашем случае возникнет миллион незакоммиченных версий И что ? У блокировочника будет 2 миллиона в transaction log'е - 1М inserted и 1М deleted
Ну, если считать - у версионника тоже будет миллион старых версий и миллион новых :) Это объективное требование задачи.

hvladОни не крякают как блокировки хотя бы потому, что это
Они крякают как блокировки потому что (синхронизируют доступ).

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

Фактически и Вы, и Ваш оппонент могли бы сказать одну фразу: реализация интербейса опирается на неявные, виртуальные блокировки; версия записи в Interbase играет роль блокировки, а последняя соответственно не существует в виде самостоятельного объекта (опять-таки - как и в оракле). Но вместо этого вы дружно держите более агрессивные позиции по разные стороны этого утверждения.
...
Рейтинг: 0 / 0
22.03.2005, 12:41
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32973367
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
softwarer hvladОни не крякают как блокировки хотя бы потому, что это
Они крякают как блокировки потому что (синхронизируют доступ).Тогда осталось выяснить - а что же такое блокировка ? ;)
Умоляю не делать этого, новый флейм нам не нужен

softwarerТо, о чем Вы говорите - техническая реализацияИменно так.

softwarerФактически и Вы, и Ваш оппонент могли бы сказать одну фразу: реализация интербейса опирается на неявные, виртуальные блокировки; версия записи в Interbase играет роль блокировки, а последняя соответственно не существует в виде самостоятельного объекта (опять-таки - как и в оракле). Но вместо этого вы дружно держите более агрессивные позиции по разные стороны этого утверждения.В принципе, если отойти от технической стороны, то я могу с этим согласиться. Но тогда весь этот топик теряет смысл, т.к. в нём обсуждаются именно технические особенности реализации. Если это не так - я признаю свою ошибку в неверной интерпретации темы беседы и исчезаю ;)
...
Рейтинг: 0 / 0
22.03.2005, 12:47
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32974079
Zaxx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Zaxx
Гость
hvlad В принципе, если отойти от технической стороны, то я могу с этим согласиться. Но тогда весь этот топик теряет смысл, т.к. в нём обсуждаются именно технические особенности реализации.

В топике обсуждаются "Различия в работе версионных механизмов в Oracle и Yukon"...
А блокировки независимо от реализации остаются блокировками...
...
Рейтинг: 0 / 0
22.03.2005, 16:02
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32974287
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ZaxxВ топике обсуждаются "Различия в работе версионных механизмов в Oracle и Yukon"...
А блокировки независимо от реализации остаются блокировками...Это мой последний ответ на этот вопрос - в IB\FB нет блокировок записей
Можете думать что хотите по этому поводу :)

PS Так можно докатиться до того, что IB\FB\Oracle блокировочником обзовут
...
Рейтинг: 0 / 0
22.03.2005, 17:15
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32974456
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Markelenkov
Участник
ZaxxВ топике обсуждаются "Различия в работе версионных механизмов в Oracle и Yukon"...
Гражданам (как и мне), видимо, тяжело обсуждать то, что уже работает не один десяток лет и многократно вылизано, с тем, чего еще нет. Думаю, Юкону в обсуждаемой теме предстоит еще долго напрягаться и портить воздух, чтобы достичь того, что есть в Oracle. Это не наезд, это реальность. Аналогично тому, как после борьбы с лженаукой СССР/Россия в IT находится сами знаете где :(

P.S.
Как пример использования возможностей, предоставляемых версионным механизмом в Oracle:

Предположим, при сильной нагрузке DBWR (фоновый процесс) осуществляет запись "грязного" (измененного) блока (страницы в терминах MS SQL) на диск - то есть, в ОС выдана команда на физическую запись (возможно, целой группы блоков), но блок еще не записан. И в этот момент пользовательскому процессу нужно модифицировать этот блок. Так вот, в Oracle 8i и выше пользовательский процесс не ждет окончания I/O, а клонирует в памяти этот блок и работает с ним, делая его текущим (current). Исходный же блок конвертируется в cr (consistent read)-блок и может использоваться как обычный cr-блок для согласованного чтения.

Когда Юкон научится делать подобные вещи, тогда он дорастет в этой области до Oracle и можно будет что-то сравнивать.

Поэтому смешно, когда автор вопроса, ничего не смысля в версионном механизме Oracle, пытается его сравнивать с тем, чего еще нет - с Юконом. И еще пытается доказать, что в Oracle это работает дерьмово.
...
Рейтинг: 0 / 0
22.03.2005, 18:01
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32974838
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
hvlad
По вашим словам, оператор (2) должен откатить всю тр-цию, в том числе оператор (1). Смотрим результаты
...
Итак - 3 попытки доступа к заблокированной таблице t отвергнуты, но запись в t2 спокойно вставлена и тр-ция фиксирована.
Ась ?

т.е. вы мне продемонстрировали, что транзакция в mssql2000 откатывает только один оператор, а остальные фиксирует ?
;)
Не хочется очернять ваше торжество, но этот эффект можно достигнуть и более простыми телодвижениями:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
create table test (f int primary key)
go

set transaction isolation level serializable
begin tran
insert into test values ( 1 )
insert into test values ( 1 )
insert into test values ( 2 )
commit

результат :
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
( 1  row(s) affected)

Server: Msg  2627 , Level  14 , State  1 , Line  1 
Violation of PRIMARY KEY constraint 'PK__test__34B3CB38'. Cannot insert duplicate key in object 'test'.
The statement has been terminated.

( 1  row(s) affected)

Я писал про Yukon, и его уровень изоляции транзакций snapshot, а это немного разные вещи.
vadiminfo
Так как от ЭБ все-таки все еще ожидается много вреда

не все лекарства одинаково полезны для всех органов, однако это никого не смущает ;)
...
Рейтинг: 0 / 0
22.03.2005, 21:29
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32974876
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
StalkerSЯ писал про Yukon, и его уровень изоляции транзакций snapshot, а это немного разные вещиНе нужно придумывать, если есть под рукой Юкон - просто проверьте.
...
Рейтинг: 0 / 0
22.03.2005, 22:04
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32975006
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
Oops!... I Did It Again :)

мс в очередной раз перенесла релиз, уже даже я не рад.
http://www.eweek.com/article2/0,1759,1777755,00.asp
...
Рейтинг: 0 / 0
23.03.2005, 01:29
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32976300
Dooma
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dooma
Гость
MarkelenkovЮкону в обсуждаемой теме предстоит еще долго напрягаться и портить воздух, чтобы достичь того, что есть в Oracle. Это не наезд, это реальность.Свежо питание, да сериться с трудом :)
В nVidia то же думали о своей непобедимости, пока ATI не напряглись. Intel то же царствовал на ПК, а теперь я пожалуй Athlon64 предпочту. Рынок - вещь переменчивая, а быть упертым болваном и кричать Oracle это круто, потому что ... - себя не уважать.

Посмотрим ;)
...
Рейтинг: 0 / 0
23.03.2005, 14:38
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32976546
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Dooma
В nVidia то же думали о своей непобедимости, пока ATI не напряглись. Intel то же царствовал на ПК, а теперь я пожалуй Athlon64 предпочту. Рынок - вещь переменчивая, а быть упертым болваном и кричать Oracle это круто, потому что ... - себя не уважать.

Я тут покупал комп приятельнице, чтобы все игры шустро крутились и все такое. Перерыл весь инет вывирая производителей - в результате купил nVidia - видюху и пень Intel.
Ну, кричать, что Оракл круто не буду, но, надеюсь, он еще подержится в лидерах. И инфа на этом формуме способствует все еще таким надеждам.
...
Рейтинг: 0 / 0
23.03.2005, 15:28
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32977159
Dooma
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dooma
Гость
авторЯ тут покупал комп приятельнице, чтобы все игры шустро крутились и все такое. Перерыл весь инет вывирая производителей - в результате купил nVidia - видюху и пень IntelИ напрасно. С AMD сэкономили бы по деньгам при той же производительности.
авторНу, кричать, что Оракл круто не буду, но, надеюсь, он еще подержится в лидерах. И инфа на этом формуме способствует все еще таким надеждам.Флейм на форуме - на объективность не тянет.
А то я скажу, что меня он склоняет, что скоро везде останется один большой MS, а все остальные сдохнут :) И по новой :)
...
Рейтинг: 0 / 0
23.03.2005, 18:41
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32977203
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
Dooma
Markelenkov
Юкону в обсуждаемой теме предстоит еще долго напрягаться и портить воздух, чтобы достичь того, что есть в Oracle. Это не наезд, это реальность.

Свежо питание, да сериться с трудом :)

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

Я не буду разводить флейм по поводу лидерства и подобной ерунды, но скажу, что видимо в отличие от многих здесь, мне совершенно не хочется, что-бы в мире СУБД когда-либо появился неоспоримый лидер, неважно кто. Так-же я рад развитию Linux'a и прочей юниксовщины, потому-что, не будь у microsoft конкуренции, мы-бы сейчас жили с системами типа Win 3.1. Я думаю, не стоит обьяснять почему ;)
...
Рейтинг: 0 / 0
23.03.2005, 19:22
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32977206
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
StalkerSТак-же я рад развитию Linux'a и прочей юниксовщины, потому-что, не будь у microsoft конкуренции, мы-бы сейчас жили с системами типа Win 3.1. Я думаю, не стоит обьяснять почему ;)
Безусловно. Собственно, в виндах довольно мало идей, которые не позаимоствованы из юниксов :)
...
Рейтинг: 0 / 0
23.03.2005, 19:25
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32977274
Фотография Markelenkov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Markelenkov
Участник
StalkerS Dooma
Markelenkov
Юкону в обсуждаемой теме предстоит еще долго напрягаться и портить воздух, чтобы достичь того, что есть в Oracle. Это не наезд, это реальность.

Свежо питание, да сериться с трудом :)

Отвечать на такие придурковатые выпадки, все равно что рубить головы драконам - чем больше рубишь, тем больше их становиться, да еще дурней. Так что я вам не советую с этим связываться, много людей приходит сюда лечить свой комплекс неполноценности, тем самым мешая другим людям, которые здесь по делу. На месте модераторов я-бы выкорчевывал такие топики с корнем и удалением ников, и это относиться не только к ораклистам, полно таких-же дураков среди программеров mssql.
Уважаемый, под "обсуждаемой темой" я имел ввиду "Различия в работе версионных механизмов в Oracle и Yukon". Это все равно, как сравнивать игру ученика 1-го класса музыкальной школы и выпускника Гнесинки - разные весовые категории. Это не означает, что MS SQL во всем хуже/лучше Oracle, просто в поддержке версионности он еще в грудном возрасте. При этом в чем-то другом Oracle по сравнению с MS SQL грудничок. Соглашаться или нет с такими доводами - дело каждого. Жизнь рассудит, будущее покажет :)

P.S. Рад, что такие кавалеристы не попадают в модераторы :)
P.P.S. Чтобы было легче, могу сказать, что в MS SQL я полный дуб, придурок и профан. Потому и не сужу о его достоинствах/недостатках после прочтения пары глав из популярной книжки и не ругаю автора, хоть и несколько попсового, но грамотного.

Кстати, учить русский язык никогда не поздно.
...
Рейтинг: 0 / 0
23.03.2005, 20:21
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #32977388
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
StalkerS
Я не буду разводить флейм по поводу лидерства и подобной ерунды, но скажу, что видимо в отличие от многих здесь, мне совершенно не хочется, что-бы в мире СУБД когда-либо появился неоспоримый лидер, неважно кто. Так-же я рад развитию Linux'a и прочей юниксовщины, потому-что, не будь у microsoft конкуренции, мы-бы сейчас жили с системами типа Win 3.1. Я думаю, не стоит обьяснять почему ;)

С этим трудно не согласиться. Но они должны в конкурентной борьбе за лидерство совершенствовать СУБД. Я имел ввиду это. Т.е. чтобы эти СУБД боролись не 10 или 20 место, а за 1.
...
Рейтинг: 0 / 0
24.03.2005, 00:09
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33137297
Silver
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Silver
Гость
;) Меня особенно умилила возможность перепрыгивать "на ходу" с блокировочника на версионник! Эта ж какая "архинужная" и "архиполезная" ВЕСЧЪ!!! Особливо памятуя что клиентское приложение о подобных чудесах может не ведать ни сном, ни духом. %)
...
Рейтинг: 0 / 0
28.06.2005, 05:21
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33137907
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
segun
Участник
Silver;) Меня особенно умилила возможность перепрыгивать "на ходу" с блокировочника на версионник! Эта ж какая "архинужная" и "архиполезная" ВЕСЧЪ!!! Особливо памятуя что клиентское приложение о подобных чудесах может не ведать ни сном, ни духом. %)Клиентским приложениям об этом необязательно знать. Знают - хорошо, не знают - это не помешает воспользоваться данной функциональностью, хотя есть и нюансы конечно. Возможность выбора между оптимальной производительностью системы и оптимальной доступностью информации - это большой плюс. Хотя данная функциональность наверняка не будет использоваться в каждом проекте, но в тех проектах где возникнет необходимость в подобной настройке, ее можно будет использовать.
Прежде чем делать поспешные выводы, почитайте пож-ста хотя бы только эту статью: SQL Server 2005 Beta 2 Snapshot Isolation . Надеюсь, многое станет более понятным и не таким смешным.
...
Рейтинг: 0 / 0
28.06.2005, 12:08
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33139399
с127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
с127
Гость
Silver;) Меня особенно умилила возможность перепрыгивать "на ходу" с блокировочника на версионник! Эта ж какая "архинужная" и "архиполезная" ВЕСЧЪ!!! Особливо памятуя что клиентское приложение о подобных чудесах может не ведать ни сном, ни духом. %)

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

segunПрежде чем делать поспешные выводы, почитайте пож-ста хотя бы только эту статью: SQL Server 2005 Beta 2 Snapshot Isolation . Надеюсь, многое станет более понятным и не таким смешным.

Стало только смешнее. Например: " In recent versions (starting with Oracle 9i) Oracle have introduced a technology similar to that used in SQL Server 2005 called "Automatic Undo Management Mode"—this new method is incompatible with the previous manual method and will require code changes if USE ROLLBACK SEGMENT statements have been used". Складывается впечатление что в МССКЛ сервере это уже давно, а в оракле 9и появилось только-только, хотя на самом деле 9и уже года четыре как на рынке, десятка на подходе, а МССКЛ все еще в бета версии и неизвестно когда появится, вообще пора переименовывать в МССКЛ-2006.

Или вот: "The implementation of optimistic concurrency differs widely between SQL Server 2005 and Oracle—the SQL Server implementation is designed to be more controllable by the database administrator (it can be enabled & disabled on command, as illustrated in the previous scenario) and also to be more manageable". Это после того как тут сторонники МССКЛ-я до хрипоты доказывали, что сервер все оптимизирует и контролирует гораздо лучше администратора, а настройки сервера никому не нужны и только отвлекают настоящего гуру от работы.

Но читаем дальше о том как же этот контроль осуществляется: "—there are a wealth of Windows System Monitor performance counters and virtual tables accessible through system functions that can help detect and decipher what is happening with the database.". Еще одно революционное достижение: виндовз монитор, системные процедуры и таблицы позволяют разобраться в чем проблема. Типа у оракла все как-то не так или что? В чем новизна-то и где обещанное в первом предложении превосходство над ораклом?

А дальше идет вообще смешное сравнение мелкософта и оракла, где неотягощенного опытом и знаниями администратора МССКЛ-я пугают фразами вроде: "Can require complex configuration of ROLLBACK SEGMENTS". Это об оракле.

МССКЛ- совсем другое дело, никаких сложностей, радостный и светящийся внутренним светом ДБА решает все проблемы легикими движениями мыши: "Version store is held in memory and TempDB. The dba must ensure that TempDB is optimized for increased i/o bandwidth based on the version store workload—TempDB database size must also be monitored (especially if the application has long running transactions), SQL Server has supported dba-friendly percentage and absolute database and log autogrow settings for many releases , but these are obviously constrained by the physical availability of disk space."

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

Вообще в статье простые и очевидные вещи излагаются с таким умным видом и таким ворохом лишних деталей что складывается впечатление что речь идет не о чем-то известном, давным-давно используемых в оракле, постгрескл-е и даже файерберде, а чем-то совершенно новом, впервые появившемся только благодаря благодетелю нашему мелкософту в МССКЛ2005. Точнее еще не появившемся, поскольку релиза все еще нет, но уже вот-вот, может быть, еще чуть-чуть, но уже совсем немного и настанет счастье.

О том что и в файерберде есть версионность автор статьи предусмотрительно предпочел умолчать, заявив, что из коммерческих продуктов это только оракл ("The second camp implemented a non-standard transaction isolation model with optimistic concurrency based on retaining a view of the data as of the start of the transaction— the only commercial system in this camp was Oracle "). И правильно, какая же это революция если даже бесплатный мелкий файерберд давно это все умеет.

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

Короче для тех кто ничего кроме мелкософта не видел статья возможно и в самом деле полезная, а для остальных - ничего нового.


А вот и первые ласточки революционного версионно-блокировочного механизма:
DDL Statements NOT Allowed Within Snapshot Isolation

Certain statements are not allowed within a transaction running under Snapshot Isolation because of their disruptive potential on the snapshot copies of the data:

* CREATE INDEX
* CREATE XML INDEX
* ALTER INDEX
* ALTER TABLE
* DROP INDEX
.....
Хотите подправить инедкс или таблицу - извольте выключить Snapshot Isolation.

И как бедняга оракл с таким справляется, ведь у него-же версионность выключить нельзя.
...
Рейтинг: 0 / 0
29.06.2005, 05:44
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33139454
alex-ls
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alex-ls
Участник
Может тогда обсудить ORACLE 11 против Yukon, чтобы еще интереснее было?
...
Рейтинг: 0 / 0
29.06.2005, 08:34
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33139794
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
nkulikov
Гость
Самое смешное в том что 90% денег на нашей планете переводятся со счета на счет, даже не через реляционные БД....
...
Рейтинг: 0 / 0
29.06.2005, 11:08
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33139843
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
замечательно
...statements are not allowed within a transaction running under Snapshot Isolation
Не выключить Snapshot Isolation, а вне транзакции. Это несколько разные вещи.
Между тем, согласен, что написано слишком пафосно... Впрочем писали ведь какие-нить маркетологи. Они этим деньги зарабатывают.
...
Рейтинг: 0 / 0
29.06.2005, 11:22
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33141513
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
До прочтения поста с127 я даже не подозревал, что можно плакать и смеяться одновременно. Очередной спец по Ораклу углядел потрясающие ляпы в Yukon.

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

>>подумашь пол-транзакции версионная, пол-транзакции блокировочная

>>The dba must ensure that TempDB is optimized for increased i/o bandwidth based on the version store workload
>>...
>>а какая разница что подправлять, и мониторить ролбек сегмент или темпДБ?

>>Хотите подправить инедкс или таблицу - извольте выключить Snapshot Isolation.

>>Стало только смешнее. Например: "In recent versions (starting with Oracle 9i) Oracle have introduced a technology similar to
>>that used in SQL Server 2005 called "Automatic Undo Management Mode"—this new method is incompatible with the previous manual
>>method... Складывается впечатление что в МССКЛ сервере это уже давно, а в оракле 9и появилось только-только...

У меня вообще такое чувство, что глубокоуважаемый с127 перевел статью переводчиком типа Magic Goody. Хотя все равно непонятно, откуда взялись все то, о чем он там понаписал. Ведь Magic Goody не может сам придумать перевод, если не знает как перевести !!! (хотя хер его знает, может новые версии Magic Goody так и поступают, вводя тем самым несчастных с127 в заблуждение)
...
Рейтинг: 0 / 0
29.06.2005, 21:05
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33141715
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
AAronзамечательно
...statements are not allowed within a transaction running under Snapshot Isolation
Не выключить Snapshot Isolation, а вне транзакции. Это несколько разные вещи.


Дело в том что перечисленные операции (alter table, alter index, ...) относятся к DDL и никогда в транзакции не входили. Если речь идет именно о транзакции, то в этой иноформации нет смысла, зачем говорить что они не входят в транзакцию в снапшот-уровне изоляции если они не входят ни в какую транзакцию ни при каком уровне изоляции. Или в Юконе на каких-то уровнях изоляции можно откатить alter table? Т.е. по-моему как раз чтоб выполнить например alter index нужно выключить снапшот изоляцию, как я и написал, другого объяснения прочитанному я не вижу. Может я ошибаюсь.

AAron
Между тем, согласен, что написано слишком пафосно... Впрочем писали ведь какие-нить маркетологи. Они этим деньги зарабатывают.

Все что я написал есть ответ на утверждение segun-а что после прочтения этой статьи многое прояснится и не будет таким смешным. Я и ответил, что стало только смешнее. Не нужно давать ссылки на такие статьи, хотя другие по продуктам микрософта наверное найти сложно.

А так я с Вами согласен.


StalkerSДо прочтения поста с127 я даже не подозревал, что можно плакать и смеяться одновременно. Очередной спец по Ораклу углядел потрясающие ляпы в Yukon.

Плохо читали, видать сильно плакали, так нельзя, поберегите себя. Где это в моем посте обсуждаются ляпы в Юконе?

StalkerS
>>подумашь пол-транзакции версионная, пол-транзакции блокировочная


Это была шутка. Если присмотритесь, то увидите что это ответ не segun-у, а Silver-у на шутливый пост.

Читайте внимательно, а главное ДУМАЙТЕ хотябы изредка. Полезная штука.
...
Рейтинг: 0 / 0
30.06.2005, 04:22
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33141717
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
Ззабыл сказать.

AAronзамечательно
...statements are not allowed within a transaction running under Snapshot Isolation
Не выключить Snapshot Isolation, а вне транзакции.

По-видимому у Вас опечатка, не вне транзакции, а внутри транзакции.
...
Рейтинг: 0 / 0
30.06.2005, 04:33
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33141807
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
авторДело в том что перечисленные операции (alter table, alter index, ...) относятся к DDL и никогда в транзакции не входили. Если речь идет именно о транзакции, то в этой иноформации нет смысла, зачем говорить что они не входят в транзакцию в снапшот-уровне изоляции если они не входят ни в какую транзакцию ни при каком уровне изоляции. Или в Юконе на каких-то уровнях изоляции можно откатить alter table?

да можно у них откатить и ddl и alter, и полно лапухов которые так и делают, а потом чешут репу с вопросом чего это у него теперь однопользовательская система получилась.
...
Рейтинг: 0 / 0
30.06.2005, 09:14
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33142958
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
Именно, DDL могут быть обрамлены транзакцией и соотвественно откачены либо закоммичены. Пример приводить не надо, надеюсь ? Юкона под рукой нет, поэтому я не могу проверить как он поведет при наличии в снапшот транзакции DDL.
...
Рейтинг: 0 / 0
30.06.2005, 15:05
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33143845
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
StalkerS
Участник
c127
Это была шутка. Если присмотритесь, то увидите что это ответ не segun-у, а Silver-у на шутливый пост.

Читайте внимательно, а главное ДУМАЙТЕ хотябы изредка. Полезная штука.

да-уж, насмешили. Все остальное тоже шутка ? А то до меня юмор по вечерам плохо доходит

и кстати, я бы на вашем месте не давал советов, которым вы сами не следуете
...
Рейтинг: 0 / 0
30.06.2005, 19:55
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33144074
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
AAronИменно, DDL могут быть обрамлены транзакцией и соотвественно откачены либо закоммичены. Пример приводить не надо, надеюсь ?

Как раз надо. Приведите пример alter table drop column с последующим откатом. Это еще одна новая фича Юкона или в МССКЛ2000 такое тоже бывает?



StalkerSА то до меня юмор по вечерам плохо доходит

Тренируйтесь чаще.

А вот и упражнение. Ответьте где это я говорил что углядел лыпы в Юконе (StalkerS: "Очередной спец по Ораклу углядел потрясающие ляпы в Yukon.").
...
Рейтинг: 0 / 0
01.07.2005, 05:11
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33144342
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
c127 AAronИменно, DDL могут быть обрамлены транзакцией и соотвественно откачены либо закоммичены. Пример приводить не надо, надеюсь ?

Как раз надо. Приведите пример alter table drop column с последующим откатом. Это еще одна новая фича Юкона или в МССКЛ2000 такое тоже бывает?


Трудно поверить что MS может то что не может Оракл? :)
Да можно и пример. Причем это было уже и в 6.5 (правда там drop column не было)
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
create table a(i int, b int)
go

insert a select  1 , 2 
begin tran
alter table a drop column b 
go

select * from a
go
rollback tran

select * from a
go
drop table a

Но единственно где это(DDL в транзакции) реально было полезно - можно было создавать временные таблицы в триггерах. А т.к. в 2000 появились таблицы-переменные, то пользы от такой возможности немного. Но она есть.
...
Рейтинг: 0 / 0
01.07.2005, 10:20
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33144367
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
Это не единственная область применения. Мне сейчас по ходу нового проекта приходится активно использовать конструкцию "select ... into _new_table_". Правда пока вне транзакций.

Правда у меня Юкона все равно нет сейчас, может кто из присутствующих проделает опыт на нем при Snapshot изоляции?
...
Рейтинг: 0 / 0
01.07.2005, 10:30
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33146231
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
SergSuper
Трудно поверить что MS может то что не может Оракл? :)


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

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

SergSuper
Да можно и пример. Причем это было уже и в 6.5 (правда там drop column не было)


Раз эту штуку можно проделать в МССКЛ-е 6.5 то ее наверняка можно проделать и в сайбейзе АСЕ. Нужно посмотреть.


AAronЭто не единственная область применения. Мне сейчас по ходу нового проекта приходится активно использовать конструкцию "select ... into _new_table_". Правда пока вне транзакций.


Не убедительно, к тому же ничего особенного, такие штуки сайбейз АСА тоже позволяет делать.
[ WITH temporary-views ]
SELECT [ ALL | DISTINCT ] [ row-limitation ] select-list
[ INTO { hostvar-list | variable-list | table-name } ]
....
INTO table-name This clause is used to create a table and fill it with data.
If the table name starts # then it is created as a temporary table. Otherwise, the table is created as a permanent base table.

Но вроде бы в АСА постоянные таблицы в транзакцию не входят, т.е. откатить нельзя, а вопрос был по транзакциям. Никогда не приходилось использовать эту фичу. По-моему использование ДДЛ в рабочих частях программ есть дурной тон, тут это как-то обсуждалось, работает медленно, плохо контролируется, проблемы с ограничением прав доступа и т.д. Наверное единственное исключение это временные таблицы.
...
Рейтинг: 0 / 0
02.07.2005, 08:50
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33146391
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
2 c127

DDL в транзакциях в разных СУБД уже обсуждались полгода назад
/topic/157503
...
Рейтинг: 0 / 0
02.07.2005, 16:07
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33146624
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
ЛП2 c127

DDL в транзакциях в разных СУБД уже обсуждались полгода назад
/topic/157503

Ну да, хотя я имел в виду другой топик, этот я раньше не видел. Кстати там можно прочитать что, как и предполагалось, сайбейз АСЕ тоже умеет откатывать ДДЛ в транзакциях. Версионник ПостгреСКЛ тоже умеет, хотя у него все транзакции версионные по определению. Но вот беда, он не коммерческий, поэтому по замыслу автора статьи его учитывать не нужно.
...
Рейтинг: 0 / 0
02.07.2005, 22:12
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33146646
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
c127Версионник ПостгреСКЛ тоже умеет, хотя у него все транзакции версионные по определению. Но вот беда, он не коммерческий, поэтому по замыслу автора статьи его учитывать не нужно.
Гммм... пардон, не понял?
Речь про тот топик на который я дал ссылку, или про какой-то другой?
Если про тот, то почему по замыслу автора его не надо учитывать?
gardenmanВозник вопрос, в каких базах данных кроме DB2 возможен DDL внутри транзакции? Для Oracle - понятно - всякий DDL вызовет коммит, который приведет к завершению транзакции. Sybase ASE - просто не позволяет DDL внутри транзакции. А как в остальных базах, ASA,MSSQL,POSTGRES и пр? для примера на DB2:
и ответ
...
Рейтинг: 0 / 0
02.07.2005, 22:34
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33146648
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
Эээ... пардон, не разобрался сразу - какой автор какой штатьи имелся в виду.
Вопрос снят.
...
Рейтинг: 0 / 0
02.07.2005, 22:39
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33149241
AlTk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlTk
Участник
c127
Я о такой штуке никогда не слышал и никогда не встречал ситуацию когда такое могло бы хоть как-нибудь помочь.

вообще говоря, полезная штука в случае если необходимо выполнить реструктуризацию БД, находящейся за несколько сот километров.
...
Рейтинг: 0 / 0
05.07.2005, 09:29
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33151337
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
AlTk c127
Я о такой штуке никогда не слышал и никогда не встречал ситуацию когда такое могло бы хоть как-нибудь помочь.

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

По-прежнему не вижу полезности. С точки зрения администрирования нет разницы находится ли СКЛ сервер в соседней комнате или на другом континенте. Но даже если принять тезис о полезности, то мы тут выяснили ничего нового мелкософт опять не придумал, эту якобы полезную штуку умеют делать даже бесплатные СКЛ сервера и по понятным причинам Сайбейз АСЕ тоже умеет.
...
Рейтинг: 0 / 0
06.07.2005, 04:09
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33151530
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
c127 AlTk c127
Я о такой штуке никогда не слышал и никогда не встречал ситуацию когда такое могло бы хоть как-нибудь помочь.

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

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

А я например не вижу полезности в битмап индексах. Наверное вещь полезная, но я никогда их не использовал (даже слабо представляю что это такое) и на любой Ваш аргумент их полезности тоже отвечу что можно сделать как-то по-другому.
Так что не надо уподобляться ярому фанату MS SQL :)

Есть возможность - и хорошо, а кто её придумал - дело десятое.
...
Рейтинг: 0 / 0
06.07.2005, 10:02
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33151547
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
c127
По-прежнему не вижу полезности. С точки зрения администрирования нет разницы находится ли СКЛ сервер в соседней комнате или на другом континенте. Но даже если принять тезис о полезности, то мы тут выяснили ничего нового мелкософт опять не придумал, эту якобы полезную штуку умеют делать даже бесплатные СКЛ сервера и по понятным причинам Сайбейз АСЕ тоже умеет.

интересно что с этой фичей будет делать mssql и другие когда дорастут до отслеживания зависимостей. и еще например у нас такой код

begin
create table a (b int) ;
insert into a (10,20) ;
end ;

во время компиляции таблички нет и ф правильно понимаю, что сиквел такое пропустит ?
...
Рейтинг: 0 / 0
06.07.2005, 10:11
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33151588
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
сиквел выполнит этот код без проблем.
...
Рейтинг: 0 / 0
06.07.2005, 10:31
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33151641
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
а вообще сиквел пытается проверяет правильность самих команд (существование полей, таблиц и т.п. ) или только синтаксис ?
...
Рейтинг: 0 / 0
06.07.2005, 10:53
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33151648
4321
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
4321
Участник
Yo!!
интересно что с этой фичей будет делать mssql и другие когда дорастут до отслеживания зависимостей. и еще например у нас такой код

begin
create table a (b int) ;
insert into a (10,20) ;
end ;

во время компиляции таблички нет и ф правильно понимаю, что сиквел такое пропустит ?
ну в Постгре придецца со второй строкой прокрутить динамо:
EXECUTE 'insert into a (10,20) ;'
, т.к. оно в откомпиленном виде oid таблички держит (в связи с чем обычные, не динамо, инструкции каацца нормально съедят ренейм тейбл, не требуя).

мне этафича была интересна в вариации:

дроп индекс;
дроп ключ; -- (если нет связанных ключей/процедур -т.к. пк тоже - оид)
инсерт/апдейт много-много записей;
криэйт ключ;
криэйт индекс;

процедурка заполняла некие служебные таблички (в последствии не запущалась - заполнялось триггерами, но могла работать в кач-ве репейра - если наблудил в триггерах). Скорость вставки с дропом увеличивалась раз в 10. Вся транзакция - раз в 5 (перестроение индексов, знаете ли). Я предполагал (и запускал) по возможности при отсутствии иных пользователей.
Т.ч. что будет при активных иных юзерах - сказать не могу.
...
Рейтинг: 0 / 0
06.07.2005, 10:55
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33152064
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
Ну вообще-то такой код не выполнится:
Код: plaintext
1.
2.
3.
begin 
create table a (b int) ;
insert into a ( 10 , 20 ) ;
end
Invalid object name 'а'

Но это можно разнести в разные пакеты, но в одной транзакции.

А что понимается под отслеживанием зависимостей ?



Yo!! а вообще сиквел пытается проверяет правильность самих команд (существование полей, таблиц и т.п. ) или только синтаксис ?
Если таблица есть то проверяется её поля, если её нет - ничего не проверяется. В 4 и 6.5 выдавались предупреждения, анализировалось создание временных таблиц в процедуре и проверялись их поля. С 7-й версии с проверками стало похуже.
...
Рейтинг: 0 / 0
06.07.2005, 13:07
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33152185
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
SergSuperНу вообще-то такой код не выполнится:
Код: plaintext
1.
2.
3.
begin 
create table a (b int) ;
insert into a ( 10 , 20 ) ;
end
Invalid object name 'а'
а на котором стейтменте ?

SergSuper
Но это можно разнести в разные пакеты, но в одной транзакции.

А что понимается под отслеживанием зависимостей ?

а чо такое пакеты в сиквеле ?
зависимости это когда ты делаешь drop table у тебя помечаются как инвалидные все процедуры/пакеты где упоминалась эта табличка.


SergSuper
Если таблица есть то проверяется её поля, если её нет - ничего не проверяется. В 4 и 6.5 выдавались предупреждения, анализировалось создание временных таблиц в процедуре и проверялись их поля. С 7-й версии с проверками стало похуже.

непонял а что в случае если была таблица с одними полями, а в коде alter ? т.е. проверку нада не по текущей таблицы а по alterу из кода, который еще и может откатится ??
...
Рейтинг: 0 / 0
06.07.2005, 13:50
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33152237
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
Если исправить ошибки, например так
Код: plaintext
1.
2.
3.
4.
begin
create table a (b int)
insert into a values ( 10 )
insert into a values ( 20 )
end
, то скрипт выполняется без проблем. Никаких ошибок нет.

Проверял на версии SQL Server 2000, а не Юкон.

Пакеты - это последовательность команд. В SQL Server нет состояний объекта - валидный/невалидный, как это сделано в Оракле.
...
Рейтинг: 0 / 0
06.07.2005, 14:06
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33152292
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
2AAron

вы нас не поняли :) еще раз:

была табличка a (b int);
мы запускаем:

alter table a (b char(1)) ;
insert into a values ('a') ;

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

короче, лет через 6 посмотрим как сиквел будет из этой ситуевины выкручиватся.
...
Рейтинг: 0 / 0
06.07.2005, 14:24
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33152294
AlTk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlTk
Участник
c127
По-прежнему не вижу полезности. С точки зрения администрирования нет разницы находится ли СКЛ сервер в соседней комнате или на другом континенте. Но даже если принять тезис о полезности, то мы тут выяснили ничего нового мелкософт опять не придумал, эту якобы полезную штуку умеют делать даже ...
речь вроде бы не про новое, а про полезное.
про "несколько сот километров" вы слишком буквально поняли. с точки зрения администрирования нет разницы если между этими серверами есть связь.
бывают места, где не то, что связи нет, а куда в некоторое время года можно только на вертолете добраться, и скрипт с обновлением БД с оказией пилоту передают. я, думаю, лишняя надежность очень полезной окажется.
...
Рейтинг: 0 / 0
06.07.2005, 14:25
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33152425
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
2 Yo!!
Во-первых, насчет того скриптика я был не прав - он выполняется.
Во-вторых мне вообще непонятно что значит сиквел занимается проверками наличия полей у существуещей таблицы
Вот такой скриптик. Надеюсь не должно смущыть что таблица и процедура временные, на постоянных тоже самое.
go - это как раз граница между пакетами
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
create table #t(i int)
go

create proc #p @i int
as 
if @i= 1  alter table #t add b int
insert #t values ( 10 )

go

exec #p  0   -- 1
exec #p  1   -- 2
drop table #t -- 3
exec #p  1   -- 4

drop proc #p  --  5

1-й шаг выполниться без ошибок и запись вставится
2-й шаг вывалится с ошибкой на инсерте: несоответсвие количества полей при вставке(Insert Error: Column name or number of supplied values does not match table definition), т.к. поле добавится
На 3-м шаге мы удаляем таблицу - увы, это делается спокойно и без предупреждений
На 4-м шаге процедура запуститься и на алтере вылетит ошибка: такой таблицы нет (Cannot alter table '#t' because this table does not exist)

А как это будет в Оракле?
...
Рейтинг: 0 / 0
06.07.2005, 15:13
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33152472
Yo!!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!!
Гость
>А как это будет в Оракле?

правильно - никак. DDL в процедурах использовать нельзя.

можно использовать динамический sql + автономные транзакции (чтоб DDL транзакцию не закомитил), тогда это будет то же самое что у вас, но за это обычно отрывают яйца (динамический sql оракл уже не контролирует).
...
Рейтинг: 0 / 0
06.07.2005, 15:29
| Ответить | Цитировать | Написать  
Различия в работе версионных механизмов в Oracle и Yukon
    #33153358
с127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
с127
Гость
SergSuper

А я например не вижу полезности в битмап индексах. Наверное вещь полезная, но я никогда их не использовал (даже слабо представляю что это такое) и на любой Ваш аргумент их полезности тоже отвечу что можно сделать как-то по-другому.
Так что не надо уподобляться ярому фанату MS SQL :)

Есть возможность - и хорошо, а кто её придумал - дело десятое.

Я тоже не вижу полезности в битмап индексах, а вот хеш индексы совсем другое дело.

Я готов признать полезность ДДЛ в транзакциях. Но мы начали спор с того что в снапшот транзакциях Юкона это очень нужное и полезное свойство не поддерживается , если верить автору статьи. Так что давайте признаем что либо это свойство не очень полезно (это моя точка зрения, но я не настаиваю), либо в Юконе действительно имеет место большая недоработка.
...
Рейтинг: 0 / 0
07.07.2005, 00:02
| Ответить | Цитировать | Написать  
151 сообщений из 151, показаны все 7 страниц
  все  
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Различия в работе версионных механизмов в Oracle и Yukon
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]