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

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


Вы таки хотите сказать что IB\FB не блокирует изменённую запись до завершения транзакции ?????????????
21 мар 05, 08:28    [1400847]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
Zaxx
Вы таки хотите сказать что IB\FB не блокирует изменённую запись до завершения транзакции ?????????????
Да. Только на время изменения. И не запись, а страницу, на которой она лежит.
Это так сложно для понимания ?
21 мар 05, 10:25    [1401115]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Dooma
Guest
Всем, кто интересуется версионностью в Yukon, советую почитать статью Версионность в Yukon
Там все доходчиво изложено.
Теоритически, очень не плохо, практически, поживем - увидим.
21 мар 05, 10:30    [1401134]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
Dooma
Всем, кто интересуется версионностью в Yukon, советую почитать статью Версионность в Yukon
Там все доходчиво изложено.

Merle, к сожалению, в утверждениях переоценивает общность своих знаний. То, что он рассказывает про MSSQL интересно, но его слова про другие сервера стоит воспринимать аккуратно - достаточно упомянуть, что он однажды отождествил оракловые ROWNUM и ROWID.
21 мар 05, 10:42    [1401179]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Dooma
Guest
автор
Merle, к сожалению, в утверждениях переоценивает общность своих знаний. То, что он рассказывает про MSSQL интересно, но его слова про другие сервера стоит воспринимать аккуратно - достаточно упомянуть, что он однажды отождествил оракловые ROWNUM и ROWID.
Я не знакомый Merle, но слышал, что этот чел общается с разработчиками из MS. Пусть Merle поправит, если что не так.
И в чем в чем, а в MS ему можно доверять. А с Oracle вы и сами в состоянии сравнить.
21 мар 05, 10:50    [1401198]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
serg99
Member

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

В моем примере я просил убрать Read не в первой, а во второй транзакции. Тогда транзакции становятся сериализуемыми t1,t2 и "умная" СУБД не выдала бы ошибку "конфликт сериализации".

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

Я не ожидаю конкретного состояния счета. Я ожидаю что в рамках правил операций с моим счетом его состояние будет правильным. Если кто то удвоил состояние счета (положил 4 тысячи), а потом кто то имеющий право работать со счетом доложил еще 1 тысячу, то на счету будет 9 тысяч и это правильно (в общей сложности положено 5 тысяч). А вот если оба считали состояние счета как 4 тысячи, а второй закоммитился позже первого, то на счету будет 5 тысяч. То есть на счету было 4 тысячи, добавили туда еще 5 тысяч и в результате получилось 5 тысяч. Вот это как раз неправильно (пропали 4 тысячи рублей).
21 мар 05, 14:32    [1402128]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

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

Нет. Тр-ция не откатывается. Отменяется текущий statement. Это две большие разницы.
... т.к. увидел ваше недостаточное понимание механизма работы версионности

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

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

vadiminfo

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

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

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

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

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

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

Кроме того, приблизительность для типовых приложений БД - редкая роскошь.

в том числе поймете, что за зверь такой, этот dirty read, и с чем его едят
21 мар 05, 14:57    [1402241]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Yo!!
Guest
автор
Так вот поверьте, что это глупость, никто никогда не станет разбивать транзакцию на куски, ставя под угрозу целостность данных (я имею ввиду адекватных программистов)


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

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
21 мар 05, 15:14    [1402317]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
StalkerS
hvlad

Нет. Тр-ция не откатывается. Отменяется текущий statement. Это две большие разницы.
... т.к. увидел ваше недостаточное понимание механизма работы версионности
Либо snapshot в Оracle и Yukon отличается от такового в Интербейс, либо это у вас недостаточное понимание механизма ;)
Сервер сам откатывает тр-цию только в 1 случае - физическая невозможность её продолжить (обрыв соединения, катастрофический сбой и т.п.) Если это не так - прощайтесь с таким сервером. MSSQL откатывает именно statement, по крайней мере при конфликте блокировок.

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

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

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

Формулировку теоремы привести можете ?
21 мар 05, 15:23    [1402362]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

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

В моем примере я просил убрать Read не в первой, а во второй транзакции. Тогда транзакции становятся сериализуемыми t1,t2 и "умная" СУБД не выдала бы ошибку "конфликт сериализации".

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

serg99

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

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

StalkerS

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

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

StalkerS

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

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

StalkerS

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

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

StalkerS

в том числе поймете, что за зверь такой, этот dirty read, и с чем его едят

Боюсь, что не пойму до тех пор, пока не будет точно установлено, что свойство транзаций - изолированость является необыкновенно вредной идеей.
Пока, однако, все обстоит иначе. И думаю, что если mssql станет истинным версионником (в поздних версиях Юникона), то появятся книжки по mssql, в которых будут говорить - какая гадость это ваше грязное чтение.
21 мар 05, 16:26    [1402708]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Юкон...
Guest
Я не Юникон - я Юкон!
21 мар 05, 17:03    [1402935]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

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

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

Это ваше право !
и вообще, при чем здесь DB2
hvlad

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

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

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

во-первых, все читать совершенно не обязательно (особенно про recovery)
во-вторых, английский язык полезно знать ;)
в-третьих, вот здесь все разжевано по-русски и в гораздо меньшем обьеме
vadiminfo

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

посмотрите вышеуказанную ссылку, хотя там все на примере mssql
vadiminfo

Да у Кайта - это Вы как в воду глядели.

не в воду, а в книгу Кайта ;)
vadiminfo

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

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

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

аналогично
vadiminfo

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

с появлением версионности, использование грязного чтения и в самом деле должно скатиться практически к нулю, так как немногим сложнее можно получить полностью согласованную картину. Тем не менее, не забывайте, что не все работают в банках, и далеко не все отчеты требуют точных цифр.
21 мар 05, 21:28    [1403640]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Gluk (Kazan)
Member

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

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


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

Так-что это Вы слегка запутались
22 мар 05, 08:05    [1404031]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Zaxx
Guest
Вы таки хотите сказать что IB\FB не блокирует изменённую запись до завершения транзакции ?????????????

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


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

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

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

Берём вторую сесиию : говорим
update org set notes='ГЫ' WHERE CLIENT_UID='54d8ad103b004ba0a7f7121ceb5d9fad'
и получаем :
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.

Это то что вы называете "нет блокировок" ?????????????????
22 мар 05, 09:29    [1404173]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
StalkerS
hvlad

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

Сессия №1
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

Её результаты
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
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). Смотрим результаты
(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)
во-вторых, английский язык полезно знать ;)
в-третьих, вот здесь все разжевано по-русски и в гораздо меньшем обьеме
Во-первых, я не собираюсь качать кучу неизвестно чего, неизвестно для чего, уж извините.
Во-вторых, с английским на этом уровне я проблем не испытаваю, спасибо за совет
В третьих - я схожу туда... чуть позже :)
22 мар 05, 10:22    [1404378]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
Gluk (Kazan)

Так-что это Вы слегка запутались

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

///////////////////
Все это очень хорошо работает при читающих запросах, однако при записи могут возникать конфликты. Если при выполнении обновления snapshot-транзакция доберется до записи, заблокированной другой транзакцией, то, возникнет конфликт версий. Если блокирующая транзакция успешно фиксируется, в чистом версионнике snapshot-транзакция откатывается, поскольку если она изменит данные более «молодой» транзакции и продолжит работу, вполне возможен феномен утерянного обновления. Сместить эти транзакции друг относительно друга во времени и считать snapshot-транзакцию более «молодой» тоже не получится, так как блокирующая транзакция могла добавить записи, удовлетворяющие условию выборки snapshot-транзакции, а значит, все snapshot-запросы должны были эти записи увидеть. То есть snapshot-транзакция все равно должна выполниться заново, с более поздней временной меткой, чтобы увидеть все изменения, внесенные блокирующей транзакцией.
//////////////////////
22 мар 05, 10:33    [1404417]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
2 hvlad
с вашим ответом разберусь вечером, а то обед кончается, а нада еще поесть ;)
22 мар 05, 10:35    [1404429]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
Zaxx
Вы таки хотите сказать что IB\FB не блокирует изменённую запись до завершения транзакции ?????????????
Сколько раз мне это повторить ? Столько, сколько знаков вопроса ?


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


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

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

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

Берём вторую сесиию : говорим
update org set notes='ГЫ' WHERE CLIENT_UID='54d8ad103b004ba0a7f7121ceb5d9fad'
и получаем :
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 сходить ? Здесь этого навалом
22 мар 05, 10:35    [1404431]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Все принимаем на веру ? А самому проверить не судьба ???
Вы поняли автора слишком буквально Как правило, особенно начинающие разработчики, реагируют на подобный exception откатом транзакции. Но при чем тут Oracle и Yukon ??? Кстати, выше приведен пример работы Юкона если я не ошибаюсь :)
22 мар 05, 10:37    [1404440]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
StalkerS
Про Оракл утверждать не буду, но вот что написано про такие транзакции в статье про версионность в Yukon (ссылка есть выше)

StalkerS
...Если блокирующая транзакция успешно фиксируется, в чистом версионнике snapshot-транзакция откатывается
Автор статьи должен признать, что имел в виду оператор, а не тр-цию.
22 мар 05, 10:40    [1404451]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
StalkerS
2 hvlad
с вашим ответом разберусь вечером, а то обед кончается, а нада еще поесть ;)
У кого обед заканчивается, а у кого завтрак ещё не переварился
22 мар 05, 10:41    [1404461]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

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

посмотрите вышеуказанную ссылку, хотя там все на примере mssql

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

StalkerS

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

Ну как это где? Вот за иерархическую или сетевую БД (а возможно и ООСУБД) посадить студента двоечника совсем сложно - банк бы вообще бы не дождался никогда системы.
Вот в чем краегольный камень успеха РМД в плане продвижения на рынке.
А Вы говорите.
22 мар 05, 11:23    [1404675]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Zaxx
Guest
hvlad
Может быть только одна активная (незакоммиченная) версия записи. Вторая попытка создать версию будет или ждать завершения первой тр-ции,
или отвалится сразу с сообщением lock conflict (см. ниже ;) - это зависит от режима wait\no_wait второй тр-ции.


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

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


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

Если вы говорите про отсутствие блокировок "по чтению", то во первых надо указывать явно что речь идёт именно о блокировании/неблокировании читателя, а во вторых это (отсутсвие блокировок читателей в версионниках) и ежу понятно (на он он и версионник).
22 мар 05, 11:28    [1404697]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
Zaxx
hvlad
Может быть только одна активная (незакоммиченная) версия записи. Вторая попытка создать версию будет или ждать завершения первой тр-ции,
или отвалится сразу с сообщением lock conflict (см. ниже ;) - это зависит от режима wait\no_wait второй тр-ции.


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

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


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

Zaxx
Если вы говорите про отсутствие блокировок "по чтению", то во первых надо указывать явно что речь идёт именно о блокировании/неблокировании читателя, а во вторых это (отсутсвие блокировок читателей в версионниках) и ежу понятно (на он он и версионник).
Я говорю только то, что я говорю. Не нужно проводить аналогии с блокировочниками, тем более не корректные.
22 мар 05, 11:54    [1404824]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67447
Блог
hvlad
Если я в одной тр-ции сделаю апдейт миллиону записей, то у меня не возникнет миллиона блокировок записей. Так понятнее ?

Вы спорите ни о чем. Знаете старую фразу - "если нечто плавает как утка, крякает как утка и несет утиные яйца, значит это утка"?

В Вашем случае возникнет миллион незакоммиченных версий. Причем, сидя в SQL-консоли, отличить их от блокировок будет достаточно трудно - они "крякают как блокировки".
22 мар 05, 12:11    [1404894]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить