|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
Yo.!ну например для того, что бы получить кол-во записей в таблице, вместо той цифры с потолка, что дает блокировочный RC вместо кол-ва записей в таблице ... Про опцию READ_COMMITED_SNAPSHOT, я так понял, он не в курсе? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2011, 18:25 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
pkarklinПро опцию READ_COMMITED_SNAPSHOT, я так понял, он не в курсе? гы. он в курсе. причем как он утверждает будет та же хрень что и на блокировочном RC. занятно мсскл же версионность на уровне строк содержит и если запись переезжает, похоже действительно дважды/трижды прочтет. надо попробовать. это будет даже для меня открытием ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2011, 18:33 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
Yo.!мсскл же версионность на уровне строк содержит и если запись переезжает, похоже действительно дважды/трижды прочтет. надо попробовать. это будет даже для меня открытием Ну расскажешь, как все прошло. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.12.2011, 19:30 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
pkarklin, нет, на версионном RC мне двоиться заставить не удалось. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2011, 12:55 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
Yo.!нет, на версионном RC мне двоиться заставить не удалось. Yo.!, спасибо, что проверил все на практике! ... |
|||
:
Нравится:
Не нравится:
|
|||
28.12.2011, 16:20 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
softwarerserg99а уровень Serializable сводился к обнаружению конфликта сериализации и откату конфликтующих транзакций в результате чего приложение должно было просто "зайти позже" в надежде что этого "больше не повторится". По хорошему сервер должен сам заниматься сериализацией без участия автора транзакций. Было бы любопытно, если бы Вы расшифровали мысль поподробнее. Скажем, на примерах - вот пользователи делают вот это, по-плохому обнаруживается конфликт, а по-хорошему сервер должен был бы вот так заняться сериализацией. Тут много букв понадобится и наверное рисунков. У нас теория изоляции транзакций вырабатывалась в рамках разработки собственной СУБД. Суть в том что используется отличный от общепринятого механизм "приватной версионности" и сервер сам занимается разруливанием конфликтов сериализации (при уровне Serializable) не утруждая этим приложения (за исключением отдельных случаев для длинных тарнзакций). Существуют естественно различия для оптимистического и пессемистического подхода в разруливании. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2011, 21:15 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
serg99softwarerпропущено... Было бы любопытно, если бы Вы расшифровали мысль поподробнее. Скажем, на примерах - вот пользователи делают вот это, по-плохому обнаруживается конфликт, а по-хорошему сервер должен был бы вот так заняться сериализацией. Тут много букв понадобится и наверное рисунков. У нас теория изоляции транзакций вырабатывалась в рамках разработки собственной СУБД. Суть в том что используется отличный от общепринятого механизм "приватной версионности" и сервер сам занимается разруливанием конфликтов сериализации (при уровне Serializable) не утруждая этим приложения (за исключением отдельных случаев для длинных тарнзакций). Существуют естественно различия для оптимистического и пессемистического подхода в разруливании. Можно и без рисунков, тут многие уже знают варианты реализации для различных СУБД. И к чему вы пришли? 1. При отпимистической версионности, выполняются действия над копиями данных и если при коммите исходные данные не изменились то коммитим, если изменились СУБД заново выполняет всю транзакцию? 2. При писсимистическом подходе накладываем S-блокировку на все читаемые данные и U-блокировку изменяемые, но меняем их в копии, а при коммите заменяем те данные что были под U-блокировкой измененной копией. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.12.2011, 23:34 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
И к чему вы пришли?Можно и без рисунков, тут многие уже знают варианты реализации для различных СУБД. И к чему вы пришли? К тому что нет нехороших феноменов, которые есть даже в Оракле и что сервер всё что может делает сам. И к чему вы пришли?1. При отпимистической версионности, выполняются действия над копиями данных и если при коммите исходные данные не изменились то коммитим, если изменились СУБД заново выполняет всю транзакцию? Нет. Тут в зависимости от ситуации существует несколько решений. Во многих случаях для успешной сериализации достаточно поменять порядок коммита транзакций. И к чему вы пришли?2. При писсимистическом подходе накладываем S-блокировку на все читаемые данные и U-блокировку изменяемые, но меняем их в копии, а при коммите заменяем те данные что были под U-блокировкой измененной копией. Какие то блокировки могут появиться только при записи и строго говоря блокируются не данные. Вероятность конфликта уменьшается так же благодаря тому что конфликтующей единицей является не строка таблицы, а как бы конкретное поле строки. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2011, 01:47 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
serg99 , Все это уже реализовано во всех СУБД 1. Переупорядочивание 2. Различная гранулярность блокировок, т.е. эскалация. Самое простое что можно было бы сделать, это оставить гранулярность блокировок на уровне полей. Неужели вы думаете что MS SQL и Oracle зря сделали блокировки на уровнях записей, страниц и таблиц? Тут стоит сказать, что гранулярность блокировок в подавляющем большинстве случаев стоит увеличивать, а не уменьшать. - Во-первых это уменьшает вероятность возникновения дедлоков - Во-вторых уменьшение гранулярности - это увеличение количества блокировок - а это увеличения затрат на поиск дедлоков для прохода по их графу serg99Какие то блокировки могут появиться только при записи и строго говоря блокируются не данные. А вот тут поподробней, что именно вы хотели сказать, кто блокируется если не данные и почему? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2011, 02:42 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
кто блокируется если не данные serg99 , Все это уже реализовано во всех СУБД 1. Переупорядочивание 2. Различная гранулярность блокировок, т.е. эскалация. Самое простое что можно было бы сделать, это оставить гранулярность блокировок на уровне полей. Неужели вы думаете что MS SQL и Oracle зря сделали блокировки на уровнях записей, страниц и таблиц? Тут стоит сказать, что гранулярность блокировок в подавляющем большинстве случаев стоит увеличивать, а не уменьшать. - Во-первых это уменьшает вероятность возникновения дедлоков - Во-вторых уменьшение гранулярности - это увеличение количества блокировок - а это увеличения затрат на поиск дедлоков для прохода по их графу Собственно при оптимистичном алгоритме блокировок практически нет, но правда возможны частичные откаты транзакций или создание приватных версий данных. serg99Какие то блокировки могут появиться только при записи и строго говоря блокируются не данные. А вот тут поподробней, что именно вы хотели сказать, кто блокируется если не данные и почему?[/quot] При пессимизме блокируются как бы транзакции, вернее синхронизируются на ожидании разруливания конфликтов сериализуемости. Дедлоки возможны но они случаются среди активных транзакций, которых одновременно не так уж и много (их легче контролировать и разрывать циклы в графе) . Ну и учитывается конечно что не все зависимые операции приводят к конфликтам сериализуемости. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2011, 05:23 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
serg99Во многих случаях для успешной сериализации достаточно поменять порядок коммита транзакций. Ага, то бишь если одна транзакция выдаёт Код: sql 1.
а другая Код: sql 1.
то достаточно вторую закоммитить первой?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2011, 14:18 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
serg99Собственно при оптимистичном алгоритме блокировок практически нет, но правда возможны частичные откаты транзакций или создание приватных версий данных. А как выглядит и называется та структура данных по которой определяется изменялись ли исходные данные и надо заново провести транзакцию или не изменялись и её можно коммитить, не блокировки ли? serg99При пессимизме блокируются как бы транзакции, вернее синхронизируются на ожидании разруливания конфликтов сериализуемости. Дедлоки возможны но они случаются среди активных транзакций, которых одновременно не так уж и много (их легче контролировать и разрывать циклы в графе) . Ну и учитывается конечно что не все зависимые операции приводят к конфликтам сериализуемости. Очень трудно сказать какая транзакция какую будет блокировать пока они не наткнуться на одни и те же данные. Ну и когда транзакция наткнётся на заблокированную строку, сама транзакция заблокируется и пока она находиться в ожидании, ресурсы ядра будут использоваться для других запросов. Или вы что-то другое имели ввиду под блокировкой транзакций? И помимо активных транзакций какие ещё бывают? ... |
|||
:
Нравится:
Не нравится:
|
|||
31.12.2011, 14:59 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakovserg99Во многих случаях для успешной сериализации достаточно поменять порядок коммита транзакций. Ага, то бишь если одна транзакция выдаёт Код: sql 1.
а другая Код: sql 1.
то достаточно вторую закоммитить первой?.. Здесь я не вижу конфликта сериализуемости, поэтому представляется что все равно в каком порядке коммитить. Собственно сериализация это когда результат параллельного выполнения транзакций равен результату их последовательного выполнения. В данном случае любой порядок коммита удовлетворяет этому условию. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.01.2012, 01:00 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
Лучше вот так: Ага, то бишь если одна транзакция выдаёт Код: sql 1.
а другая Код: sql 1.
то достаточно вторую закоммитить первой?.. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.01.2012, 01:28 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
не блокировки ли?serg99Собственно при оптимистичном алгоритме блокировок практически нет, но правда возможны частичные откаты транзакций или создание приватных версий данных. А как выглядит и называется та структура данных по которой определяется изменялись ли исходные данные и надо заново провести транзакцию или не изменялись и её можно коммитить, не блокировки ли? Нет. Кстати при конфликте совсем не обязательно заново проводить транзакцию. Да и вообще СУБД о которой я говорю даже не является реляционной. не блокировки ли?serg99При пессимизме блокируются как бы транзакции, вернее синхронизируются на ожидании разруливания конфликтов сериализуемости. Дедлоки возможны но они случаются среди активных транзакций, которых одновременно не так уж и много (их легче контролировать и разрывать циклы в графе) . Ну и учитывается конечно что не все зависимые операции приводят к конфликтам сериализуемости. Очень трудно сказать какая транзакция какую будет блокировать пока они не наткнуться на одни и те же данные. Ну и когда транзакция наткнётся на заблокированную строку, сама транзакция заблокируется и пока она находиться в ожидании, ресурсы ядра будут использоваться для других запросов. Или вы что-то другое имели ввиду под блокировкой транзакций? Пессимизм предполагает что при возникновении зависимых операций могущих превратиться в конфликт сериализуемости транзакция считает что такой конфликт с большой вероятностью случится, а потому останавливается и ждет произойдет конфликт на самом деле или нет. Это минимизирует необходимость частичных откатов транзакций в будущем. Но происходит это ценой необходимости постоянного анализа взаимозависимостей. При оптимизме анализ зависимостей можно проводить только во время коммита, но при этом увеличивается вероятность частичных откатов. Как я и говорил здесь нужно много букв и всё это в данной теме скорее всего офф-топик. не блокировки ли?И помимо активных транзакций какие ещё бывают? В определенной степени можно считать все незаконченные транзакции активными. В данном контексте терминологические ньюансы не важны. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.01.2012, 01:42 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
Лучше вот такЛучше вот так: Ага, то бишь если одна транзакция выдаёт Код: sql 1.
а другая Код: sql 1.
то достаточно вторую закоммитить первой?.. Здесь то же нет конфликта. Любой порядок соответствует сериализации. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.01.2012, 02:02 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
А вот так?: Ага, то бишь если одна транзакция выдаёт Код: sql 1.
а другая Код: sql 1.
то достаточно вторую закоммитить первой?.. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.01.2012, 02:34 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
А вот так?А вот так?: Ага, то бишь если одна транзакция выдаёт Код: sql 1.
а другая Код: sql 1.
то достаточно вторую закоммитить первой?.. Если речь о "потерянном обновлении", то пример лучше сформулировать типа Код: sql 1.
а другая Код: sql 1.
Понятно что "а" в итоге должно увеличиться на 3. Здесь в 2х случаях транзакции могут коммититься в том порядке в котором хотят, в двух других возникает конфликт сериализуемости и необходимость отката одной из транзакций до точки конфликта. Так как в данном случае транзакции заранее сообщают серверу что они хотят сделать, то сервер может просто не стартовать одну из транзакций пока не закончится другая. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.01.2012, 17:47 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
serg99Так как в данном случае транзакции заранее сообщают серверу что они хотят сделать, то сервер может просто не стартовать одну из транзакций пока не закончится другая. Что-то мне подсказывает, что Вы только что изложили своими словами суть понятия "блокировка". ... |
|||
:
Нравится:
Не нравится:
|
|||
01.01.2012, 18:21 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
softwarerserg99Так как в данном случае транзакции заранее сообщают серверу что они хотят сделать, то сервер может просто не стартовать одну из транзакций пока не закончится другая. Что-то мне подсказывает, что Вы только что изложили своими словами суть понятия "блокировка". "Хоть горшком назови, только в печку не ставь" (с) :-). Главное что бы работало и не было бы тех же оракловских аномалий. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.01.2012, 03:30 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
serg99Вероятность конфликта уменьшается так же благодаря тому что конфликтующей единицей является не строка таблицы, а как бы конкретное поле строки. Где-то я это уже слышал... ANTs Data Server? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2012, 19:15 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
pavelvpserg99Вероятность конфликта уменьшается так же благодаря тому что конфликтующей единицей является не строка таблицы, а как бы конкретное поле строки. Где-то я это уже слышал... ANTs Data Server? Не знаю таких. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.02.2012, 19:53 |
|
Informix SDS и Oracle RAC: давайте сравним
|
|||
---|---|---|---|
#18+
serg99softwarerпропущено... Что-то мне подсказывает, что Вы только что изложили своими словами суть понятия "блокировка". "Хоть горшком назови, только в печку не ставь" (с) :-). Главное что бы работало и не было бы тех же оракловских аномалий. Извините, но если все же Вы и в правду своими словами пытались описывать понятие "блокировка", то, скорее всего, луче в этом довериться "оракловым аномалиям". Вероятность, что в том, что они модели транзакций юзают не "своими словами", а книжными повыше все же буит. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2012, 08:53 |
|
|
start [/forum/topic.php?fid=35&msg=37601331&tid=1552589]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
37ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 157ms |
0 / 0 |