to Splain

Это особенности работы СУБД, и не более.

Из одного прикола "А давайте объявим этот баг фичей ..."

Особенности бывают удачно реализованные и неудачно.

Дискусия по поводу undo - от лукавого.

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

В этом смысле у DB2 и Оракл просто разные сегменты рынка.

Не поняла аргумент? Что дейсвительно настолько разные?

to NewYear

Неблокирующий селект не случайный побочный эффект а поставленная цель в достижении минимального наложения блокировок. И то что он не блокирует, это большое преимущество и достижение. Селект он предназначен для чтения, а не для блокирования. Просто из за его блокирующих свойств во многих СУБД разработчики быстро взяли этот эффект на вооружение. А завязывать логику программы на побочных эффектах и применять фичи не по назначению это не есть gut.
Если вы хотите заблокировать данные, вы делаете это явно select for update. Если вы их просто читаете, вы не накладываете никаких блокировок и не мешаете другим сеансам. Вот и всё.

PS
Таких примеров использования не по назначению уйма. Например в Oracle появились фичи flashback database/flashback queries - можно запрашивать базу по состоянию на момент времени в прошлом. Уже назревают попытки использовать такую фичу для хранения исторической информации.

А аргумент, вот мол чтобы у нас заблокировать запись досточно написать

select from

а у вас надо писать

select from for update

просто смешон.

а может данные уже изменены, а я читаю устаревшие данные. это явно баг.

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

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

а может данные уже изменены, а я читаю устаревшие данные. это явно баг.

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

При изоляции dirty read проблема устаревших данных отсутвует, но присутсвуют другие проблемы:). Non repetable read/Phantom Read позволяет видеть вам закомиченные данные после начала вашей транзакции - в Oracle это тоже. Serializable более высокий уровень изоляции, он существует и может использоваться если этого потребует логика приложения. Но используется он редко. Не понимаю почему вы зацепились за уровень с самой высокой изоляцией для аргументации по вашему мнению "бага". Это просто свойство уровня "repretable read/no phantom read". Можно попробовать направить в комитет по стандартам SQL bug report, что уровни repretable read/no phantom read это "баги" и их нужно исправить:)

если б я реально писал те транзакции, я бы про блокировки даже и не вспомнил.

Первое что должен сделать разработчик начав писать под другую СУБД, это ознакомиться с поддерживаемыми уровнями изоляции и механизмом блокировок.
Если бы я так поступала, я бы тоже начав писать под DB2 спокойно без опасений использовала бы селекты не боясь заблокировать что либо. Последтсвия были бы еще более катострофические.

Что действительно БАГ имхо, это неконсистентные результаты запроса в уровне изоляции READ COMMITTED, котоый вам очень наглядно описал vc123

vc123Under the default READ COMMITTED IL, SQL Server does not leave behind any locks -- as soon as the row is read, the lock is removed. This can lead to well-known anomalies with inconsistent aggregates or incorrect bank transfers

However, any locking scheduler has a much nastier anomaly that allows incorrect aggegates (sum/avg/etc) in the Read Committed isolation for which there is no good cure at all.

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

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

to gvv

And thank you very much for the perfect explanation what is a resource manager and what is a summary table and how to use them :)

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

wow! DO you really want to find a business tasks which could be implemented in one, and could not be in other??? Good luck.


Похожего ответа я от вас и ожидала - просто передергивания. Я спросила конкретную вещь. Вы сказали что memory management в Oracle poor и что named buffers намногое эффективнее? Ведь на основе чего то вы сделали такое заключение? Какие задачи они (named buffers) вам позволили бы решить намного эффективнее. Иначе на чем основывается ваше утверждение?

gvv"В Oracle это встроенная фича. С пом. profiles можно ограничить" - exactly. Oracle way is "All in one". IBM way is "A set of tools/utilities", if to say in short.

Ранее
gvvNewYear - as for me, IBM MUST supply MQSeries with DB2.

Слишком обще. То что лучше - часть системы или external tool - зависит от конкретного случая. ИМХО, в случае profiles and resource manager лучше, если они реализованы в ядре самой СУБД.

to Я и ёжик

цель любого планировщика транзакций сохранить целостность базы при выполнении серии паралельных транзакций

А при чем тут целостность базы? Селект не изменяет данных, почему селект должен заботиться о целостности базы? Это делается при кокурентном измении базы а не при чтении.

to Я и ёжик

Так вот неблокирующий селект это побочный эффект "версионной" части Oracle механизма concurency control.

А что же тогда по вашему есть цель "версионной" части Oracle механизма concurency control?

to gvv

if I remember correctly, I said imho. I hop you know what it does mean.

Конечно знаю. И я задала конкретный вопрс. Почему ваше мнение таково?

I agree for you it could be not the same.

Сейчас я не могу высказать объективное мнение, у меня нет конкретных аргументов что Oracle memory management справится с этим лучше. У вас оно (мнение) есть. Значит есть аргументы, почему named pools лучше. Что плохого в желании узнать его причины?

But as for me (again as for me) having MQSeries as a separate product allows me to use it _without_ DB2.

Согласна и об этом уже писала ранее.

to NewYear

не уверен. лучше, когда они реализованы в OS, как в OS/400.


И как OS будет разбираться во внутренних особенностях процессов БД, особенно если shared server configuration (несколько сессий обслуживаются одним процессом) при распределении ресурсов?

commit и rollback здесь - команды OS, а sql commit то же самое, что OS commit.


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

to NewYear

авторда не селект, транзакция, транзакция изменяет данный. Нельзя рассматривать сетект вне транзакции

Какие данные изменяются здесь?


PS
В Oracle также есть еще уровень изоляции READ ONLY = serializable read only.

to riman

Всё вышеперечисленное про интерфейс

Совершенно согласна. В свое время я тоже возмущалась что как можно так мало внимания и усердия выделять тому, что является ИМХО визитной карточкой продукта. Но Oracle считает это малоприоритетным. Слышала что эти явавские GUI тулзы пишут в Индии.