to NewYear

авторну а как поисходит изоляция транзакций? если меня интересует уровень RR, скажем. я что, так и буду работать с какой-то версией, а в это время кто-то изменит данные или прочитает неверные данные? я пишу mission-critical application, и у меня на первом месте стоит сохранность данных.

В Oracle 2 уроня изоляции

READ COMMITED и SERIALIZABLE



То что вы хотите достигается уровнем SERIALIZABLE.

я что, так и буду работать с какой-то версией, а в это время кто-то изменит данные

Oracle в этом отношении не полный версионник. То есть такие сюрпризы из-за одновременного изменяющего доступа в одной и той же строке не откладываются до коммита а проявляются немендленно.

См. здесь

Oracle9i - read uncommitted
ViolinaИнтересно так же поведение при возникновении блокировок, когда наша транзакция пытается изменить строку, уже изменненую в другой транзакции после начала нашей. В нашей транзакции возникнет ожидание, до тех пор пока другая транзакция не будет завершена - коммитом или ролбэком. При ролбэке в нашей транзакции все пройдет так, как быдто бы другой транзакции и не было. При коммите произойдет следующее. Если уровень изоляции нашей транзакции READ COMMITTED, то изменение будет успешным. Мы как бы смогли увидить новые данные и изменить их. В случае если уровень изоляции нашей транзакции SERIALIZABLE, мы получим отлуп

ORA-08177: can\'t serialize access for this transaction


Если вы не хотите, чтобы юзер ждал окончания транзакции другого юзера. Можно делать предварительно select * from update nowait и информировать его сразу что ресурс заблокирован.

или прочитает неверные данные

В Oracle dirty read отсутсвует, так что неверные данные он не прочитает. В Oracle запросы согласованы на момент его начала и выполняются в режиме serializable. Так же исклчены такие ситуации, описанные ниже для MS SQL

Oracle9i - read uncommitted
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 (I believe at least one of them is described in the Kyte book). The problems of course can easily be fixed programmatically. Moving up to a higher isolation level, REPEATABLE READ, may and does create deadlocks in the situations where RC IL leads to inconsistencies.


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

Возможно. Но ... Принципы разработки под Oracle я уже приводила

- если можно, сделай это с помощью одного оператора SQL
- если это невозможно, сделай это в PL/SQL
- если это невозможно в PL/SQL, сделай это с помощью Java
- если это невозможно с помощью Java, сделай внешнюю процедуру на С
- если и это невозможно, надо серъезно подумать зачем это вообще нужно

Внешние процедуры в Oracle пишут когда нужны очень массивные вычисления с данными, с которыми лучше справятся например модули написанные на С чем PL/SQL программы. Писать внешние процедуры чтобы использовать SQL имхо не логичный подход. Этовсе равно что ездить в Мюнхен из Питера чтобы купить пиво "Балтика".

Oracle Advansed Queuing, мне просто смешно читать. В сравнении с WebSphere MQ. или это к теме не относится?

Относится, мне интересно узнать про фичи DB2 из первых рук. Так что не стесняйтесь, рассказывайте:)
С утверждением согласна, Oracle Advansed Queuing не так сильно развито, до его появления вообще был проблематично с решениями задач, решать которые призвано Oracle Advansed Queuing. В Oracle есть еще поддержка pipes, что эффективно позволяет решить множество задач, в DB2 наверняка тоже есть.

а ПК и UNIX это тоска смертая.

В смысле?

to riman

Да, ваши аргументы меня убедили:) Завтра начинаю учить DB2.

Вы не там книжки смотрите. Стоимость хороших книжек по Oracle 700-1000 рублей, за границей 30-60 Евро. А вот книжек по DB2 трудно найти, нет спроса нет предложения, не так уж сильно распостранена эта СУБД.

PS
Только без обид, каков наезд таков отет:)

to Nikolay

Про lock escalation я значит не так выразилась, извиняюсь. Я имела в виду что дополнительное IO меньшее "зло" чем lock escalation, ИМХО.

28 + 24 *4 = 124 байта. Размер блока 124/2048*100=6%


Размер блока и INITTRANS/MAXTRANS можно менять. При резком скачке заитересованных транзакций, Oracle может занимать место из свободного места блока, предназначенно для данных. Если хочеться сэкономить место, например для редко изменяемых справочников, можно INITTRANS в 1 выставить и pctfree в 0, стандартный прием. Так что вместо 6% можно написать и 2% и 10%.

А на мой встречный вопрос/аргумент по поводу IO и записи UNDO в журнал будет реакция? Правильно мое предположение или нет? Если нет то аргументы ...

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

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

to riman

А кстати это хорошая книжка по Ораклу или нет:
Использование Oracle8/8i Специальное издание.

НЕТ!!! Но я по ней учить Оракл начинала за отсутствием чего то лучшего в то время. На самом деле действительно хороших книг по Oracle очень мало, так что выручает только документация.

Кто ищет тот и обрящет. :)

Это да. Кстати у меня тоже есть одна. Завтра скажу название (на ПТ чтобы здесь не засорять) а вы мне скажете хорошая ли она.

По Оракл хорошие книги

Oracle для профессионалов, Том Кайт
Oracle проектирование баз данных, Дейв Энсор
Oracle PL/SQL для профессионалов, С. Фейерштейн

to NewYear

зачем добавлять еще язык, если и так можно писать на чем угодно?
"других вариантов нет, кроме как писать на чем угодно"

Когда есть втроенный платформонезависимый язык все же приятней. Знаете такую несколько шуточную притчу про программное обеспечение - а именно гибкость versus простота использования. Крайние варианты

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

На этой шкале Oracle лежит ближе к варианту "кнопка" а DB2 к варианту "компайлер":)

А написать свой язык для DB2 сейчас действительно нереально. Oracle проделал большой путь в PL/SQL - наработки, объединение PL/SQL и SQL энджин итп. Такое не сделаешь за год и это потребует больших затрат девелоперских ресурсов.