powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Informix SDS и Oracle RAC: давайте сравним
23 сообщений из 98, страница 4 из 4
Informix SDS и Oracle RAC: давайте сравним
    #37595762
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!ну например для того, что бы получить кол-во записей в таблице, вместо той цифры с потолка, что дает блокировочный RC вместо кол-ва записей в таблице ...

Про опцию READ_COMMITED_SNAPSHOT, я так понял, он не в курсе?
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37595778
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
pkarklinПро опцию READ_COMMITED_SNAPSHOT, я так понял, он не в курсе?
гы. он в курсе. причем как он утверждает будет та же хрень что и на блокировочном RC. занятно
мсскл же версионность на уровне строк содержит и если запись переезжает, похоже действительно дважды/трижды прочтет. надо попробовать. это будет даже для меня открытием
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37595856
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!мсскл же версионность на уровне строк содержит и если запись переезжает, похоже действительно дважды/трижды прочтет. надо попробовать. это будет даже для меня открытием

Ну расскажешь, как все прошло. :)
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37596919
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
pkarklin,

нет, на версионном RC мне двоиться заставить не удалось.
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37597437
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Yo.!нет, на версионном RC мне двоиться заставить не удалось.

Yo.!, спасибо, что проверил все на практике!
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37600653
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerserg99а уровень Serializable сводился к обнаружению конфликта сериализации и откату конфликтующих транзакций в результате чего приложение должно было просто "зайти позже" в надежде что этого "больше не повторится". По хорошему сервер должен сам заниматься сериализацией без участия автора транзакций.
Было бы любопытно, если бы Вы расшифровали мысль поподробнее. Скажем, на примерах - вот пользователи делают вот это, по-плохому обнаруживается конфликт, а по-хорошему сервер должен был бы вот так заняться сериализацией.
Тут много букв понадобится и наверное рисунков. У нас теория изоляции транзакций вырабатывалась в рамках разработки собственной СУБД. Суть в том что используется отличный от общепринятого механизм "приватной версионности" и сервер сам занимается разруливанием конфликтов сериализации (при уровне Serializable) не утруждая этим приложения (за исключением отдельных случаев для длинных тарнзакций). Существуют естественно различия для оптимистического и пессемистического подхода в разруливании.
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37600698
serg99softwarerпропущено...

Было бы любопытно, если бы Вы расшифровали мысль поподробнее. Скажем, на примерах - вот пользователи делают вот это, по-плохому обнаруживается конфликт, а по-хорошему сервер должен был бы вот так заняться сериализацией.
Тут много букв понадобится и наверное рисунков. У нас теория изоляции транзакций вырабатывалась в рамках разработки собственной СУБД. Суть в том что используется отличный от общепринятого механизм "приватной версионности" и сервер сам занимается разруливанием конфликтов сериализации (при уровне Serializable) не утруждая этим приложения (за исключением отдельных случаев для длинных тарнзакций). Существуют естественно различия для оптимистического и пессемистического подхода в разруливании.
Можно и без рисунков, тут многие уже знают варианты реализации для различных СУБД.
И к чему вы пришли?
1. При отпимистической версионности, выполняются действия над копиями данных и если при коммите исходные данные не изменились то коммитим, если изменились СУБД заново выполняет всю транзакцию?
2. При писсимистическом подходе накладываем S-блокировку на все читаемые данные и U-блокировку изменяемые, но меняем их в копии, а при коммите заменяем те данные что были под U-блокировкой измененной копией.
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37600764
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И к чему вы пришли?Можно и без рисунков, тут многие уже знают варианты реализации для различных СУБД.
И к чему вы пришли?

К тому что нет нехороших феноменов, которые есть даже в Оракле и что сервер всё что может делает сам.

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

Нет. Тут в зависимости от ситуации существует несколько решений. Во многих случаях для успешной сериализации достаточно поменять порядок коммита транзакций.

И к чему вы пришли?2. При писсимистическом подходе накладываем S-блокировку на все читаемые данные и U-блокировку изменяемые, но меняем их в копии, а при коммите заменяем те данные что были под U-блокировкой измененной копией.
Какие то блокировки могут появиться только при записи и строго говоря блокируются не данные. Вероятность конфликта уменьшается так же благодаря тому что конфликтующей единицей является не строка таблицы, а как бы конкретное поле строки.
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37600783
serg99 ,
Все это уже реализовано во всех СУБД
1. Переупорядочивание
2. Различная гранулярность блокировок, т.е. эскалация. Самое простое что можно было бы сделать, это оставить гранулярность блокировок на уровне полей. Неужели вы думаете что MS SQL и Oracle зря сделали блокировки на уровнях записей, страниц и таблиц?
Тут стоит сказать, что гранулярность блокировок в подавляющем большинстве случаев стоит увеличивать, а не уменьшать.
- Во-первых это уменьшает вероятность возникновения дедлоков
- Во-вторых уменьшение гранулярности - это увеличение количества блокировок - а это увеличения затрат на поиск дедлоков для прохода по их графу

serg99Какие то блокировки могут появиться только при записи и строго говоря блокируются не данные.
А вот тут поподробней, что именно вы хотели сказать, кто блокируется если не данные и почему?
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37600831
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кто блокируется если не данные serg99 ,
Все это уже реализовано во всех СУБД
1. Переупорядочивание
2. Различная гранулярность блокировок, т.е. эскалация. Самое простое что можно было бы сделать, это оставить гранулярность блокировок на уровне полей. Неужели вы думаете что MS SQL и Oracle зря сделали блокировки на уровнях записей, страниц и таблиц?
Тут стоит сказать, что гранулярность блокировок в подавляющем большинстве случаев стоит увеличивать, а не уменьшать.
- Во-первых это уменьшает вероятность возникновения дедлоков
- Во-вторых уменьшение гранулярности - это увеличение количества блокировок - а это увеличения затрат на поиск дедлоков для прохода по их графу

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

serg99Какие то блокировки могут появиться только при записи и строго говоря блокируются не данные.
А вот тут поподробней, что именно вы хотели сказать, кто блокируется если не данные и почему?[/quot]
При пессимизме блокируются как бы транзакции, вернее синхронизируются на ожидании разруливания конфликтов сериализуемости. Дедлоки возможны но они случаются среди активных транзакций, которых одновременно не так уж и много (их легче контролировать и разрывать циклы в графе) . Ну и учитывается конечно что не все зависимые операции приводят к конфликтам сериализуемости.
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37600923
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
serg99Во многих случаях для успешной сериализации достаточно поменять порядок коммита транзакций.

Ага, то бишь если одна транзакция выдаёт
Код: sql
1.
update t set a=1 where b=1


а другая
Код: sql
1.
update t set a=2 where b=1


то достаточно вторую закоммитить первой?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37600934
serg99Собственно при оптимистичном алгоритме блокировок практически нет, но правда возможны частичные откаты транзакций или создание приватных версий данных.
А как выглядит и называется та структура данных по которой определяется изменялись ли исходные данные и надо заново провести транзакцию или не изменялись и её можно коммитить, не блокировки ли?

serg99При пессимизме блокируются как бы транзакции, вернее синхронизируются на ожидании разруливания конфликтов сериализуемости. Дедлоки возможны но они случаются среди активных транзакций, которых одновременно не так уж и много (их легче контролировать и разрывать циклы в графе) . Ну и учитывается конечно что не все зависимые операции приводят к конфликтам сериализуемости.
Очень трудно сказать какая транзакция какую будет блокировать пока они не наткнуться на одни и те же данные. Ну и когда транзакция наткнётся на заблокированную строку, сама транзакция заблокируется и пока она находиться в ожидании, ресурсы ядра будут использоваться для других запросов. Или вы что-то другое имели ввиду под блокировкой транзакций?

И помимо активных транзакций какие ещё бывают?
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37601116
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakovserg99Во многих случаях для успешной сериализации достаточно поменять порядок коммита транзакций.

Ага, то бишь если одна транзакция выдаёт
Код: sql
1.
update t set a=1 where b=1


а другая
Код: sql
1.
update t set a=2 where b=1


то достаточно вторую закоммитить первой?..

Здесь я не вижу конфликта сериализуемости, поэтому представляется что все равно в каком порядке коммитить. Собственно сериализация это когда результат параллельного выполнения транзакций равен результату их последовательного выполнения. В данном случае любой порядок коммита удовлетворяет этому условию.
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37601123
Лучше вот так:

Ага, то бишь если одна транзакция выдаёт
Код: sql
1.
update t set a=2 where a=1


а другая
Код: sql
1.
update t set a=1 where a=2


то достаточно вторую закоммитить первой?..
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37601126
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
не блокировки ли?serg99Собственно при оптимистичном алгоритме блокировок практически нет, но правда возможны частичные откаты транзакций или создание приватных версий данных.
А как выглядит и называется та структура данных по которой определяется изменялись ли исходные данные и надо заново провести транзакцию или не изменялись и её можно коммитить, не блокировки ли?

Нет. Кстати при конфликте совсем не обязательно заново проводить транзакцию. Да и вообще СУБД о которой я говорю даже не является реляционной.

не блокировки ли?serg99При пессимизме блокируются как бы транзакции, вернее синхронизируются на ожидании разруливания конфликтов сериализуемости. Дедлоки возможны но они случаются среди активных транзакций, которых одновременно не так уж и много (их легче контролировать и разрывать циклы в графе) . Ну и учитывается конечно что не все зависимые операции приводят к конфликтам сериализуемости.
Очень трудно сказать какая транзакция какую будет блокировать пока они не наткнуться на одни и те же данные. Ну и когда транзакция наткнётся на заблокированную строку, сама транзакция заблокируется и пока она находиться в ожидании, ресурсы ядра будут использоваться для других запросов. Или вы что-то другое имели ввиду под блокировкой транзакций?

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

не блокировки ли?И помимо активных транзакций какие ещё бывают?
В определенной степени можно считать все незаконченные транзакции активными. В данном контексте терминологические ньюансы не важны.
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37601128
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Лучше вот такЛучше вот так:

Ага, то бишь если одна транзакция выдаёт
Код: sql
1.
update t set a=2 where a=1


а другая
Код: sql
1.
update t set a=1 where a=2


то достаточно вторую закоммитить первой?..
Здесь то же нет конфликта. Любой порядок соответствует сериализации.
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37601132
А вот так?
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А вот так?:

Ага, то бишь если одна транзакция выдаёт
Код: sql
1.
update t set a=2 where a=1


а другая
Код: sql
1.
update t set a=3 where a=1


то достаточно вторую закоммитить первой?..
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37601216
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А вот так?А вот так?:

Ага, то бишь если одна транзакция выдаёт
Код: sql
1.
update t set a=2 where a=1


а другая
Код: sql
1.
update t set a=3 where a=1


то достаточно вторую закоммитить первой?..

Если речь о "потерянном обновлении", то пример лучше сформулировать типа
Код: sql
1.
update t set a=a+1


а другая
Код: sql
1.
update t set a=a+2


Понятно что "а" в итоге должно увеличиться на 3. Здесь в 2х случаях транзакции могут коммититься в том порядке в котором хотят, в двух других возникает конфликт сериализуемости и необходимость отката одной из транзакций до точки конфликта.

Так как в данном случае транзакции заранее сообщают серверу что они хотят сделать, то сервер может просто не стартовать одну из транзакций пока не закончится другая.
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37601218
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
serg99Так как в данном случае транзакции заранее сообщают серверу что они хотят сделать, то сервер может просто не стартовать одну из транзакций пока не закончится другая.
Что-то мне подсказывает, что Вы только что изложили своими словами суть понятия "блокировка".
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37601331
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerserg99Так как в данном случае транзакции заранее сообщают серверу что они хотят сделать, то сервер может просто не стартовать одну из транзакций пока не закончится другая.
Что-то мне подсказывает, что Вы только что изложили своими словами суть понятия "блокировка".
"Хоть горшком назови, только в печку не ставь" (с) :-). Главное что бы работало и не было бы тех же оракловских аномалий.
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37650637
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
serg99Вероятность конфликта уменьшается так же благодаря тому что конфликтующей единицей является не строка таблицы, а как бы конкретное поле строки. Где-то я это уже слышал... ANTs Data Server?
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37650689
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pavelvpserg99Вероятность конфликта уменьшается так же благодаря тому что конфликтующей единицей является не строка таблицы, а как бы конкретное поле строки. Где-то я это уже слышал... ANTs Data Server?
Не знаю таких.
...
Рейтинг: 0 / 0
Informix SDS и Oracle RAC: давайте сравним
    #37651151
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
serg99softwarerпропущено...

Что-то мне подсказывает, что Вы только что изложили своими словами суть понятия "блокировка".
"Хоть горшком назови, только в печку не ставь" (с) :-). Главное что бы работало и не было бы тех же оракловских аномалий.
Извините, но если все же Вы и в правду своими словами пытались описывать понятие "блокировка", то, скорее всего, луче в этом довериться "оракловым аномалиям". Вероятность, что в том, что они модели транзакций юзают не "своими словами", а книжными повыше все же буит.
...
Рейтинг: 0 / 0
23 сообщений из 98, страница 4 из 4
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Informix SDS и Oracle RAC: давайте сравним
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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