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

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

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

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

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

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

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

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

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

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

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

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

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

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

select ProgrammerName from CoolProgrammers where City = 'Ekaterinburg'

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

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

update CoolProgrammers set ProgrammerName = 'BeerMan' where ProgrammerName = 'StalkerS'

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

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

Т.е. про разницу между журналами тразакций и повторного выполнения. А Вы, вроде, говорили, что нет разницы.

Да виноват, наверно я в самом деле не умею читать, так как вначале от меня ускользнула такая важная деталь. Я привык к тому, что журнал транзакций отвечает за все, и встретив журналы повторного выполнения, автоматически решил, что они используются так-же.
Ну а в Yukon с журналом вряд-ли случаться грандиозные перемены, наверняка все останется по старинке.
19 мар 05, 17:38    [1399785]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Yo!!
Guest
автор
Принципиальное отличие в том, что как-бы криво я ни писал процедуры, нужная версионная информация всегда будет доступна. В то-же время, как-бы качественно ни писали вы свои процедуры, всегда есть вероятность напороться на ORA-01555.
Почувствуйте разницу ! (из рекламы не помню чего, наверно пива ;)


судя по всему уйти от обсуждения некоторых личвных качеств некотрых участников обсуждения нам все таки неудастся ;)
ув StalkerS давайте все таки напряжемся и попытаемся понять зачем оракл затерает данные ?
почему он предпочитает откатить 1 транзакцию с ORA-01555 ? зачем это лишнее ограничение безразмерного роста сегмента отката ? что было бы если сегмет отката рос бесконечно ?
да это просто дыра для DOS атак, в сиквеле получается любой юзер может вызвать остановку всего инстанса, просто сделать бесконечный цикл который переполняет tempdb.
19 мар 05, 18:10    [1399816]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
да, насчет версионности, еще вариант : работадатели обращаются с запросами только по ночам, поэтому днем работаем как блокировочник, а на ночь включаем версионность
19 мар 05, 18:12    [1399817]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

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

судя по всему уйти от обсуждения некоторых личвных качеств некотрых участников обсуждения нам все таки неудастся ;)

да, вы правы, сдержаться сложно, но я стараюсь !
Yo!!

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

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

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

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

удачи!
19 мар 05, 18:24    [1399826]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Yo!!
Guest
2StalkerS

какая производительность ? еще раз ORA-01555 это защита от остановки всего истанса. т.е. у сиквела просто баг раз такой защиты нет. наверника в следующем релизе в sql2010 им это прийдется сделать тоже самое.
19 мар 05, 18:38    [1399839]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
Не корысти ради (c) но влезу с точки зрения реализации версионности в IB\FB, с которой я немного знаком, да и, насколько я в курсе, реализация в Yukon'е много ближе к IB чем к ORACLE.

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

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

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

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

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

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

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

Отсюда можно заключить, что блокировочник вынужден запоминать много блокировок одновременно и действуют они достаточно долго - дольше, чем происходит собственно обновление записи, но у него не остаётся мусорных версий.
Версионник управляет значительно меньшим кол-вом блокировок одновременно и живут они очень недолго. Зато приходится чистить мусор. При многопользовательской работе версионник однозначно будет меньше простаивать на блокировках и общая пропускная способность у него будет выше.
19 мар 05, 18:39    [1399841]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
StalkerS
блокировочный подход :

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

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

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

Я не буду комментировать знание автором Oracle :)

У меня есть 2 вопроса к автору:
1. Как считает автор, есть ли разница (и велика ли она, если есть) в стоимости (скорости) установки и снятия блокировки с записи в первом и втором случаях?
2. Предположим, в блокировочнике требуется выполнить транзакцию, скажем, из 5 вставок, 5 обновлений и 5 удалений строк. Предположим, на пятом удалении получена ошибка и требуется откатить все изменения, выполненные в данной транзакции. Где будет брать блокировочник старые версии данных?
19 мар 05, 20:06    [1399904]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
serg99
Member

Откуда:
Сообщений: 422
vadiminfo
Я воспроизвел Ваш пример. При попытке добавленя 1 в транзакции 2 получили сообщение об ошибке ORA-08177 can't serialize access for this transaction

А транзакция_1 к этому времени уже была закоммичена? Интересно кстати если во второй транзакции не читать атрибут, а просто сразу записать какую нибудь константу, то то же будет ORA-08177?

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

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

То есть получается что СУБД сама по себе не обеспечивает уровень изоляции транзакций соответсвующий "честной" сериализуемости. Хотя пользователь задавая ISOLATION_LEVEL = SERIALIZABLE ожидает именно этого.
19 мар 05, 20:13    [1399906]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 StalkerS
Про ORA-01555. Я же и грил Вам - давайте посмотрим что будет у Юникона. Вы думаете что версионность такая халява? И что Оракл не мог сделать сохранение версий на столько на сколько может Юникон. Значит есть причины. Потому и не могу пока почуствовать разницу. Мож у Вас там вылезет какой-нибудь сюрприз. Разве так не бывало?
Добавлю только что в 9 ни разу не натыкался еще на ORA-01555. Писал почему. Надеюсь, Вы прочли. Там по умолчанию ставится 3600 сек. 6 часов.



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

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

Я тоже попью с Вами пивка, но включу с Вашего позволения версионность. В частности, чтобы не беспокоиться вообще ни о чем, включая и заграницу.
Что-то мне говорит, что если у Юникона версионность будет не хуже, чем у Оракла, то и Вы через какое-то время навсегда забудете про блокировочники.
19 мар 05, 21:54    [1399972]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

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

А транзакция_1 к этому времени уже была закоммичена? Интересно кстати если во второй транзакции не читать атрибут, а просто сразу записать какую нибудь константу, то то же будет ORA-08177?

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



serg99

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

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

Кстати все утро прорыля в литре. Нашел, что этот уровень блокировки просто запрещает грязное чтение,..., фантомы. Но не нашел, что он реально должен обеспечивать последовательный график.
Более того, вот вычитал, что последовательный график не гарантирует, что результаты применения всех вариантов последовательного выполнения заданного набора транзакций будут одинаковы.
Т.е. получается, что не все можно просто так поручить СУБД и пить пивко.
Должен быть разумный копромис наверное.
19 мар 05, 22:22    [1400012]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
serg99
Member

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

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

Trans1              Start Read1 Write1 Commit
Trans2     Start                                          Write1 Commit

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

vadiminfo
Насколько я понял Вашего коллегу в MS SQL выдается тоже ошибка.

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

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

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

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

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

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

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

vadiminfo
Т.е. получается, что не все можно просто так поручить СУБД и пить пивко. Должен быть разумный копромис наверное.

Беда похоже в том что поручить нельзя потому как СУБД этого не умеет. Если бы умела, то желающие поручить наверное нашлись бы.
20 мар 05, 02:28    [1400121]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

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

Тут есть блокировка, но не такая, как у блокировочника - это блокировка не записи (логического объекта), а физической страницы

В Yukon блокировка именно записи
hvlad

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

Как это ? эксклюзивная блокировка не может сняться до окончания транзакции, так как транзакция может откатиться
hvlad

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

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

При многопользовательской работе версионник однозначно будет меньше простаивать на блокировках и общая пропускная способность у него будет выше

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

Я не буду комментировать знание автором Oracle :)

Все написанное мной относиться только к Yukon. В Оракле я понимаю очень мало
Markelenkov

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

Нет, с какой стати ?
Markelenkov

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

В логе транзакций
vadiminfo

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

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

Добавлю только что в 9 ни разу не натыкался еще на ORA-01555.

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

Поэтому тратить время на разборы не буду

Зря
vadiminfo

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

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

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

Вот оно, вредное влияние Кайта ;)
Грязное чтение это не недостаток, а ловкий способ обойти другой недостаток, который вы указали. Другое дело, что пользоваться такой вещью нужно с умом. Собственно, вся версионность для того и нужна, чтобы такого недостатка не стало. Однако включив версионность, получаем другие недостатки.
А то, что отсутствие эсколации - это недостаток Оракла, я уже писал
20 мар 05, 08:33    [1400156]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
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.
Для того, чтобы оценивать уровень знаний Кайта, а тем более его ругать, нужно сначала свой уровень чуть приподнять над плинтусом. С этим и откланиваюсь...
20 мар 05, 13:33    [1400247]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
StalkerS
hvlad
Тут есть блокировка, но не такая, как у блокировочника - это блокировка не записи (логического объекта), а физической страницы
В Yukon блокировка именно записи
Это блокировка дороже, чем блокировка физ.страницы, таких блокировок больше, чем блокировок страниц.
К тому же, я не уверен, что Yukon в версионном режиме создаёт именно блокировки записей и удерживает их до конца тр-ции.

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

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

Всё что я пишу о версионнике, относится к IB\FB, так что ораклистов прошу понимать меня правильно :)
20 мар 05, 14:54    [1400301]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

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

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

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

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

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

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

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

Это блокировка дороже, чем блокировка физ.страницы, таких блокировок больше, чем блокировок страниц.

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

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

есть подозрение, что вы пытаетесь описать уровень snapshot !
20 мар 05, 16:23    [1400371]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
StalkerS
hvlad

Это блокировка дороже, чем блокировка физ.страницы, таких блокировок больше, чем блокировок страниц.
зато увеличивает паралелльный доступ. Если начинаются проблемы с ресурсами и пр. - происходит эскалация - так что никаких препятствий !
Как долгоживущая блокировка может увеличить параллельность доступа ? Эскалация, насколько мне известно, служит только для уменьшения накладных расходов на поддержку большого числа мелких блокировок. И она никак не способствует увеличению параллельности доступа :)

StalkerS
hvlad
Я же сказал - это другая блокировка. Она предотвращает доступ к памяти от одновременных модификаций, поэтому снимается сразу же после окончания
есть подозрение, что вы пытаетесь описать уровень snapshot !
shapshot есть наиболее естественный способ работы для версионника. Насколько я понял здесь сравниваются именно версионные механизмы работы ? :) К тому же, эксклюзивные блокировки накладываются при апдейтах и удерживаются до конца тр-ции независимо от её уровня изоляции, не так ли ?
20 мар 05, 17:47    [1400437]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
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 бьемся над какими-то заоблачными уровнями изоляции, для каких-то фантастических ситуаций в жизни БД оперативной обработки транзакций, а Вы говорите, что грязное чтение не недостаток? Оно же отрицает самае идею изолированности транзакций на корню, и не является недостатком? А тот бесхитростный способ обойти ее, описанный в любой книжке про СУБД, ловким способом? Вы меня разыгрываете? Нарочно сбиваете с толку? Чтобы я потом запутался окончательно?
Не знаю, что за недостаток в отсутствие эскалации блокировок в Оракле, но ее присутствие – там, где она есть недостаток, который перевисит много достоинств. Он просто способен навести ужас на иного разработчика и уже точно на конечного пользователя, и отбить всякую охоту. Он влияет на логику приложений и работу с БД вообще в худшую сторону. Нужно было заблокировать несколько записей, а заблокирована вся табла. Здорово. Не знаю, Вы первый кто мне сказал о ее пользе. В литре ничего подобного не видел. Да и сам термин эскалация подобран не случайно. Он звучит угрожающе. Разве нет?
20 мар 05, 18:20    [1400466]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
serg99
Member

Откуда:
Сообщений: 422
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
Ну или в том, что задача на оптимум: быстрый параллельный доступ и обеспечение всех требований к транзакциям. Они, наверное, противоречат друг другу.. Я говорил Вам, что парни придумываю разные модели транзакций. Делают на этом диссеры, наверное. Потому и СУБД не умеет, что есть, скорее всего, теор проблемы.
Наверное плохие дисеры пишут :-). Проблемы конечно и практические и теоретические, но вполне решаемые.
20 мар 05, 20:50    [1400541]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6905
Объясните кретину - ну пусть Юкон в версионном режиме хранит версии данных в TempDB, он же не может хранить их там вечно? Иначе размер TempDB должен быть бесконечным. Значит, должен, просто-таки обязан существовать механизм получения юзером ошибки, аналогичной ORA-01555, т.к. вероятность перезаписи данных в TempDB ограниченного размера - ненулевая. Это раз. Двас - сегменты отката/undo-сегменты в Oracle замечательно растут и сдуваются при необходимости, а в 9i и выше - создаются и удаляются автоматически, равно как и для датафайлов таблеспейсов, задействованных под хранение undo-информации, можно поставить атрибут автоматического их расширения, буде нужно писать или долго держать много старых версий (если подобный функционал поддерживается ОС), а понимания, сколько нужно места, нет. Это не очень круто с точки зрения производительности (процесс будет ждать окончания расширения), да и есть определённые ограничения на размер каждого датафайла, но механизм такой имеется и нормально работает.
20 мар 05, 21:16    [1400562]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
Scott Tiger
Объясните кретину - ну пусть Юкон в версионном режиме хранит версии данных в TempDB, он же не может хранить их там вечно?
Не может, и не будет. Версии становятся ненужными после того, как завершатся все заинтересованные в них тр-ции. После этого их можно удалять.

Scott Tiger
Иначе размер TempDB должен быть бесконечным. Значит, должен, просто-таки обязан существовать механизм получения юзером ошибки, аналогичной ORA-01555, т.к. вероятность перезаписи данных в TempDB ограниченного размера - ненулевая. Это раз.
Кто сказал, что TempDB - ограниченного размера ? В пределах дисков - неограниченного :)
20 мар 05, 21:26    [1400572]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
Scott Tiger
Объясните кретину - ну пусть Юкон в версионном режиме хранит версии данных в TempDB, он же не может хранить их там вечно? Иначе размер TempDB должен быть бесконечным. Значит, должен, просто-таки обязан существовать механизм получения юзером ошибки, аналогичной ORA-01555, т.к. вероятность перезаписи данных в TempDB ограниченного размера - ненулевая.

Легко могу предположить, что из маркетинговых соображений не будет такой ошибки. А будет аналог ORA-600 :)

Типа, мы круче, у нас "snapshot too old" не бывает
20 мар 05, 21:44    [1400586]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
StalkerS
Member

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

Как долгоживущая блокировка может увеличить параллельность доступа ? Эскалация, насколько мне известно, служит только для уменьшения накладных расходов на поддержку большого числа мелких блокировок. И она никак не способствует увеличению параллельности доступа :)

Внимательно прочитайте мой первый пост, и несколько следующих. Там очень доступно написано про эскалацию
hvlad

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

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

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

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

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

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

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

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

а Вы говорите, что грязное чтение не недостаток? Оно же отрицает самае идею изолированности транзакций на корню, и не является недостатком?

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

Да и сам термин эскалация подобран не случайно. Он звучит угрожающе. Разве нет?

Я вам могу ответить только то-же, что сказал hvlad'у, прочитайте внимательно первые посты данного топика
20 мар 05, 21:45    [1400587]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
hvlad
Guest
StalkerS
Внимательно прочитайте мой первый пост, и несколько следующих. Там очень доступно написано про эскалацию
Если речь о "Concurrency Control and Recovery in Database Systems", то у меня нет этого заочно уважаемого труда, и поэтому я не могу сказать, что там всё очень доступно. Если вы предоставите ссылки на упоминаемую теорему, то я хотя бы смогу понять - в каком контексте она применима.
Судя по реакции участников обсуждения (и по моему опыту, и опираясь на здравый смысл) - эскалация блокировок всё-таки та соломинка, без которой блокировочник не смог бы выжить в море конкурентных запросов

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

Честно говоря, я вмешался в этот топик, т.к. увидел ваше недостаточное понимание механизма работы версионности. О чём мы спорим сейчас - я уже не понимаю, впрочем это часто бывает :)
20 мар 05, 22:28    [1400607]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
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'у, прочитайте внимательно первые посты данного топика

Прочитал. Во-первых. Если даже какой-то разработчик сочтет нужным заблокировать всю таблу, то такая возможность в Оракле у него есть . Во-вторых Ваш пример не до конца ясен. Ведь если там много транзакций и заблокируются все, в том числе и те, которые можно не блокировать, то вряд ли это улучшит ситуацию. Но и вообще это все пока предположения. Цифры нужно было Вам привести. Для этого нужно экспериментировать с Ораклом. А так это всего лишь предположение, и не совсем очевидное. А пока, кажется, что эскалация блокировок - это все-таки, скорее всего, больше - очень плохое, чем просто плохое. И нужно оно тока в блокировочнике из-за того, что без этого все будет еще хуже. Либо не предсказуемый результат, либо все затормозится из-за непомерных объемов для хранения инфы про все блокировки в таблице блокировок. Всех процедур с этим связанных. Всякие проверки заблокирована запись или нет, и все такое.
21 мар 05, 02:18    [1400732]     Ответить | Цитировать Сообщить модератору
 Re: Различия в работе версионных механизмов в Oracle и Yukon  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
А пока, кажется, что эскалация блокировок - это все-таки, скорее всего, больше - очень плохое, чем просто плохое. И нужно оно тока в блокировочнике из-за того, что без этого все будет еще хуже. Либо не предсказуемый результат, либо все затормозится из-за непомерных объемов для хранения инфы про все блокировки в таблице блокировок. Всех процедур с этим связанных. Всякие проверки заблокирована запись или нет, и все такое.

С учетом того, что у меня в ASA эскалации нет, однако без всяких затрат ресурсов и потери производительности на уровне ROWLOCK спокойно проходят блокировки на десятки миллионов записей, лично мне думается, что эскалация - это частное решение для оптимизации работы механизма блокировок определенной СУБД - MSSQL и блокировочники с другой архитектурой имеют свои способы оптимизировать блокировки. Например в ASA во первых есть явный оператор LOCK TABLE, во вторых все блокировки честно идут на уровне ROWLOCK и впервую очередь они завязываются на уникальные индексы, кроме уровня изоляции SERIALIZABLE - там с целью понижения накладных расходов и большей гарантии правильной работы изоляции блокировки идут на уровне PAGELOCK, что однако все равно не мешает продолжать другим сессиям вставлять новые записи и при наличие граммотно подобранного кластерного ключа снижает вероятность блокировки на этом уровне изоляции не попадающих других записей.
21 мар 05, 07:43    [1400808]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить