powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Различия в работе версионных механизмов в Oracle и Yukon
25 сообщений из 151, страница 4 из 7
Различия в работе версионных механизмов в Oracle и Yukon
    #32970469
Zaxx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hvlad Версионнику не нужно держать логические блокировки до окончания тр-ции, т.к. он версионник ;) Поэтому у него даже такого понятия нет, как блокировка записи.
...
А версионник - держит блокировки ровно столько, сколько нужно для модификации страницы при создании версии записи. При обновлении миллиона записей версионник не будет держать одновременно более 1-ой блокировки страницы. Поэтому он и выигрывает при конкурентном доступе у блокировочника.

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

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

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

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

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

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

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

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

в том числе поймете, что за зверь такой, этот dirty read, и с чем его едят
...
Рейтинг: 0 / 0
Различия в работе версионных механизмов в Oracle и Yukon
    #32971499
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
Различия в работе версионных механизмов в Oracle и Yukon
    #32971529
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerS hvlad
Нет. Тр-ция не откатывается. Отменяется текущий statement. Это две большие разницы.
... т.к. увидел ваше недостаточное понимание механизма работы версионности
Либо snapshot в Оracle и Yukon отличается от такового в Интербейс, либо это у вас недостаточное понимание механизма ;)Сервер сам откатывает тр-цию только в 1 случае - физическая невозможность её продолжить (обрыв соединения, катастрофический сбой и т.п.) Если это не так - прощайтесь с таким сервером. MSSQL откатывает именно statement , по крайней мере при конфликте блокировок.

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

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

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

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

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

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

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

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

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

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

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

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

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

StalkerS
в том числе поймете, что за зверь такой, этот dirty read, и с чем его едят
Боюсь, что не пойму до тех пор, пока не будет точно установлено, что свойство транзаций - изолированость является необыкновенно вредной идеей.
Пока, однако, все обстоит иначе. И думаю, что если mssql станет истинным версионником (в поздних версиях Юникона), то появятся книжки по mssql, в которых будут говорить - какая гадость это ваше грязное чтение.
...
Рейтинг: 0 / 0
Различия в работе версионных механизмов в Oracle и Yukon
    #32971916
Юкон...
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я не Юникон - я Юкон!
...
Рейтинг: 0 / 0
Различия в работе версионных механизмов в Oracle и Yukon
    #32972381
Фотография 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
Различия в работе версионных механизмов в Oracle и Yukon
    #32972641
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerS
не, что-то вы совсем запутались, и других пытаетесь ;)
При уровне изоляции snapshot (Yukon) или serializable (Oracle), транзакции при конфликте версий откатываюся.
Если-же стоит уровень read committed, то изменяющая транзакция будет ждать на блокировке, пока другая изменяющая транзакция не зафиксируется.


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

Так-что это Вы слегка запутались
...
Рейтинг: 0 / 0
Различия в работе версионных механизмов в Oracle и Yukon
    #32972738
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
Различия в работе версионных механизмов в Oracle и Yukon
    #32972870
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
Различия в работе версионных механизмов в Oracle и Yukon
    #32972894
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gluk (Kazan)
Так-что это Вы слегка запутались

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

///////////////////
Все это очень хорошо работает при читающих запросах, однако при записи могут возникать конфликты. Если при выполнении обновления snapshot-транзакция доберется до записи, заблокированной другой транзакцией, то, возникнет конфликт версий. Если блокирующая транзакция успешно фиксируется, в чистом версионнике snapshot-транзакция откатывается, поскольку если она изменит данные более «молодой» транзакции и продолжит работу, вполне возможен феномен утерянного обновления. Сместить эти транзакции друг относительно друга во времени и считать snapshot-транзакцию более «молодой» тоже не получится, так как блокирующая транзакция могла добавить записи, удовлетворяющие условию выборки snapshot-транзакции, а значит, все snapshot-запросы должны были эти записи увидеть. То есть snapshot-транзакция все равно должна выполниться заново, с более поздней временной меткой, чтобы увидеть все изменения, внесенные блокирующей транзакцией.
//////////////////////
...
Рейтинг: 0 / 0
Различия в работе версионных механизмов в Oracle и Yukon
    #32972904
Фотография StalkerS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 hvlad
с вашим ответом разберусь вечером, а то обед кончается, а нада еще поесть ;)
...
Рейтинг: 0 / 0
Различия в работе версионных механизмов в Oracle и Yukon
    #32972906
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
Различия в работе версионных механизмов в Oracle и Yukon
    #32972913
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Все принимаем на веру ? А самому проверить не судьба ???
Вы поняли автора слишком буквально Как правило, особенно начинающие разработчики, реагируют на подобный exception откатом транзакции. Но при чем тут Oracle и Yukon ??? Кстати, выше приведен пример работы Юкона если я не ошибаюсь :)
...
Рейтинг: 0 / 0
Различия в работе версионных механизмов в Oracle и Yukon
    #32972922
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerSПро Оракл утверждать не буду, но вот что написано про такие транзакции в статье про версионность в Yukon (ссылка есть выше)
StalkerS...Если блокирующая транзакция успешно фиксируется, в чистом версионнике snapshot- транзакция откатываетсяАвтор статьи должен признать, что имел в виду оператор, а не тр-цию.
...
Рейтинг: 0 / 0
Различия в работе версионных механизмов в Oracle и Yukon
    #32972929
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerS2 hvlad
с вашим ответом разберусь вечером, а то обед кончается, а нада еще поесть ;)У кого обед заканчивается, а у кого завтрак ещё не переварился
...
Рейтинг: 0 / 0
Различия в работе версионных механизмов в Oracle и Yukon
    #32973101
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
StalkerS
посмотрите вышеуказанную ссылку, хотя там все на примере mssql

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

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

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

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

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

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

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

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

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

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

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

В Вашем случае возникнет миллион незакоммиченных версий. Причем, сидя в SQL-консоли, отличить их от блокировок будет достаточно трудно - они "крякают как блокировки".
...
Рейтинг: 0 / 0
25 сообщений из 151, страница 4 из 7
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Различия в работе версионных механизмов в Oracle и Yukon
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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