Nikolay

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

Не сказала бы что ээто никого не интересует.

Народ интересует кол-во обработанных транзакций за определенное время, время реакции на определенный запрос и так далее.

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

Я уже писала

Насчет скорости выборки данных (время отклика), возможно что например DB2, MS SQL и MySQL выбирают данные в ряде случаев быстрее чем Oracle. Но также надо учитывать, что какой-нибудь запрос может поставить другие в очередь и сделать обработку попросту последовательной из за наложения слишком "сильных" блокировок. Пусть например MySQL очень быстр в отношении выборки данных и времении отклика, но какой от этого толк, если

Из документации по MySQL
This means that if you have many updates on a table, SELECT statements will wait until there are no more updates.

To work around this for the case where you want to do many INSERT and SELECT operations on a table, you can insert rows in a temporary table and update the real table with the records from the temporary table once in a while.

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

to stdio

Потому что в конфигурационные файлы надо SQL-запросы вытащить.

Такая здравая мысль и так мало програм, где это делается ...

to ggv

Ну вот нашла пример.

ADM5500W DB2 is performing lock escalation.

авторИ все же, не следует забывать, что данные лочатся даже при выборке, и не тянуть с COMMIT\'ом после нее.

Типичная неоракловая философия:) А в Oracle транзакция может и должна длиться столько сколько требует бизнес логика. Принудительно подкомичивать ради требований экономии ресурсов СУБД и блокировок нет необходимости.

авторЭскалация блокировок - необязательно плохо. LOCK TABLE - почти то же самое, только вручную.

Сделать LOCK TABLE в транзакции перед SELECT.


Это вообще нонсенс с точки зрения Oracle - делать LOCK всей TABLE в транзакции перед SELECT.

to ggv

Of course anyone with appropriate permisions could run "Select * from table" with autocommit off and stop a whole system

А если продолжительные селекты или селекты с "широким охватом" данных нужно в системе выполнять в силу требований к ней? Тогда обычно начинается - отчеты только вечером или по выходным или мол нужно рядом небольшой DWH ставить.

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

to ggv

Хорошо. поставлю вопрос по конкретнее. Как решается следующая задача в DB2?

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

Вопросы

1) При низкой активности, влияние блокирующих селектов минимально. Но существует ли опасность в силу наложения блокировок при чтении, что при значительном росте количества одновременных пользователей такие штатные селекты в системе могут отрицательно сказаться на ее пропускной способности? Ведь при большом количестве одновременных пользователей селекты(обобенно с агрегацией) и операции изменения данных будут "мешать" друг другу.

Пожалуйста обоснуйте ответ, хотя бы на том уровне, на каком я рассказала про механизм блокировок в Oracle. Тирады типа "excellent IBM software lets you solve any problems" не надо.

2) Если такие проблемы будут иметь место, какими путями они решаются при таком механизме блокировок как в DB2? Грязное чтение не предлагать.

3) Если работающий селект натыкается на измененную но незакомиченную запись, которую ему нужно учесть, он ждет? Какие еще могут быть решения, кроме как требование коммитить как можно быстрее?

to ggv

You will be wondered - but it works. Works for two years now.
Do you think the whole business use Oracle only? do you really think so? It's not first time I see oracle dba think there are no any other rdbms except their favorite.


Ну вот... Я же просила без выпадов. Я же задала конкретные технические вопросы - возникают ли проблемы в описанной ситуации и как они решаются в DB2. Жаль, что ответ по существу и пример из доки я получила от Ораклоида, а не от представителей DB2. Действительно, сладывается впечатление что

Gt.типа спецов по дб2 настолько мало что мало кто может ответить на простейшие вопросы ? хоть бы линк на раздел дал ну не знаешь - промолчи зачем на гугл отсылать ?

ggvIt's not first time I see oracle dba think there are no any other rdbms except their favorite.

Это не так. Я спросила про оптимизатор и привела пример, что понравилось моему знакомому специалисту по DB2 в Oracle - механизм блокировок. Сразу последовал выпад, что механизм реализован неудачно. Приведу экстракт завязавшейся дискуссии по поводу механзима блокировок.

NikolayПо мне так Oracle механизм блокировок не есть GOOD для чистого OLTP или DW слишком много ресурсов допоглнительных требует.


Абсолютно необоснованное утверждение. Можно было бы гордо упоминуть на zero knowledge of the matter, кинуть ссылками на concepts и порекомендовать поставить Oracle. Но я решила попытаться развеять такое заблуждение.

Violina
Блокировки в Oracle это просто атрибут данных. В этом отношении механизм отличается от других СУБД. Отсутсвует такое узкое место как менеджер блокировок, это одна из причин почему Oracle практически никогда не делает эскалацию блокировок , в ней просто нет необходимости.
Про то, что запись никогда не блокирует чтение, и чтение никогда не блокирует запись вы наверное знаете .
И то что нет необходимости подкоммичивать периодически изменения, чтобы освободить ресурсы и предотвратить дедлоки.


Последовал контраргумент, что такой механизм означает большие дополнительные затраты IO.
NikolayХранение блокировок в страницах имеет следствие - более высокиe требования к IO.

Было объяснено почему это не так.

ViolinaС этим можно было бы согласиться, если бы IO делалось исключительно для блокировок, но поскольку IO так и так делаются в силу изменения данных ( при чтении ВООБЩЕ НЕ накладываются какие бы то ни было блокировки ), то убиваются сразу 2 зайца, см. мой постинг

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


Плюс аналогия с попутчиком

ViolinaОпять же приведу аналогию. Одно дело когда ты не планировал ехать например в центр города, а тебя попросили кого то свозить туда, другое дело когда ты так и так по своей надобности поехал туда и к тебе примазался попутчик. Конечно будут дополнительные затраты на бензин из за возросшей массы (+попутчик), но они не существенны.

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

NewYear там есть какие-то дурацкиe rollback-segments,
которые никому не нужны

Было объяснено, что сегменты отката не полностью повторяют redo журнал а частично облегчают его. Так что избыточность rollback segments не равна 100% а намного ниже. INSERT генерит много redo, но мало undo. DELETE наоборот. В случае update имеет место некоторая избыточность, однако в случае изменения "маленького" значения на "большое" и наоборот имеет место ситуация, аналогичная INSERT / DELETE.

ViolinaЯ говорю о разделении следующих задач в Оракл

- откат транзакций и получение before images
и
- защита(журнализация) изменений на случай сбоя

целями которго являеются в частности

- осутствие взаимных блокировок чтение/запись
- избежание узких мест/конкуренции при записи в журнал в моменты массивных нагрузок. Другими словами минимизация объемов данных, которые должны быть записаны на диск немедленно и окончания записи которых необходимо обязательно дождаться.


Был задан встречный вопрос/аргумент, что если есть только redo журнал, то просто необходимо больше данных писать в него (+ UNDO данные, которые в Оракл пишуться в сегменты отката). И окончания записи всех этих данных при комите нужно обязательно дождаться.

Violina Ведь раз UNDO тоже пишется в REDO журнал , оно тоже должно гарантировано быть записано на диск на случай сбоя , чтобы откатить незакомиченные данные на момент сбоя. В Oracle этого делать не нужно, redo журналы для отката как такового не используются , но например измения в rollback segments также защищены redo журналом , так что они (измения в rbs) тоже могут быть записаны Ораклом тогда, когда он сочтет нужным.


Реакции на него не последовало. И так, описанный механизм блокировок в Oracle имеет следующие фичи

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

И называть его просто так с потолка "неудчным" для OLTP систем по крайней мере несколько странно. Что мы имеем в DB2

- блокирующее чтение
- эскалация блокировок
- необходимость комитить как можно чаще, чтобы освободить ресурсы

Замечательно. Вот более "удачный" механизм для OLTP систем. Какие же аргументы приводяться.

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

Интересный агрумент. И главное с чего решили, что механизм блокировок Oracle снижает время отклика, а у DB2 повышает? Если селект натыкается на изменненные данные, он берет старую версию из сегментов отката, да в этом случае это делается чуть дольше чем просто чтение, в DB2 же в этом случае тоже будет задержка, пока данные не закомитят или откатят.

Слкдующий аргумент - эти проблемы вроде как решаемы, однако описание конкретных способов приведено не было, Только Gt. привел подтверждение их наличия и описание мер, которые необходимо принимать чтобы обеспечить a compromise between availability and concurrency of data.

Потом последовали выпады, не имеющиме ничего общего с технической стороной вопроса.

По поводу

Sybase has an excellent memory management, if to compare the lack of it in oracle ('named buffer pools'), and sybase has it for years, since 10.x, if I remember correctly.

Не надо просто искать точный эквивалент:) В Oracle есть опция CACHE для таблицы и есть три пула, каждый со своим механизмом кэширования

DEFAULT
Кэширование/вытеснение по частоте использования.

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

KEEP
Привилигерованный пул. Кэширование/вытеснение по частоте использования. Объекты в нем конкурируют только с другими привилигированными объектами а не со всеми остальными. Как раньше было в очередях за пивом - обычная очередь (DEAULT), и очередь с заднего хода (KEEP), где пиво продается дороже, но и очередь поменьше:)

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

Данный механизм обеспечивает не менее эффективный memory management.