to NewYear

Ну, значит я получу отлуп :)
Не уверен, что этот вариант лучше, чем блокировка. посуди сама -- если 2 транзакции делают UPDATE одной строки с SERIALIZABLE, одна из них обязательно получит отлуп.


Это и есть обычная блокировка/ожидание:) Которая возникает если изменена и еще незакомичена строка а другой сеанс пытается изменить ее тоже. Здесь можно выбрать - ждать окончание другой транзакции или получать отлуп сразу.

посуди сама -- если 2 транзакции делают UPDATE одной строки с SERIALIZABLE, одна из них обязательно получит отлуп.


Уж не хотите ли вы сказать что в DB2 есть dirty write ? Я не поверю! Что произойдет в DB2 если будет попытка изменить уже измененную незакомиченную строку в другом сеансе? Да тоже самое - блокировка.

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

Если же речь идент о желании перепичать закоммиченные данные, используйте уровень изоляции read commited.

а вот так что будет :)

insert into test values ('A' , ... );
insert into test values ('B' , ... );


это побочный эффект того что select не накладывает какие бы то нибыло блокировки. Частая ошибка девелоперов перешедших с других СУБД, где блокирование селектом частый прием. Если вышеописанная логика необходима, используйте select for update.

to stdio

Эх, Виолина, Виолина. Ну кто же так легко с голословными утверждениями соглашается?

О MQSeries знаю по наслышке, что это отдельный мощный многофункциональный продукт, что подтвердил NewYear. О том догоняет ли его AQ могу только делать догадки, я счмтала что AQ догнать пока не успел:) Спасибо что просветили.

to ggv

MQ solves many problems, and which Violina mentioned also.

Какие из? И как?

to Nikolay

2Violina: Давайте не использовать слово IMHO и "мне кажется" только осязаемые измеримые аргументы.


В отношение пишеться ли UNDO и как в DB2 это были мои догадки. Поэтому я и использую ИМХО и поэтому просила вас о коментарии по этому поводу. За ссылку и объяснение спасибо.

to vc123

Well, let me surprise you -- DB2 does have 'undo data'. While Oracle supports ROLLBACKs with a separate structure called the "undo tablespace" or "rollback segments", IBM's DB2 stores both redo and undo portions of the log in one place (transaction log).

Any database implementing rollback must have a way to preserve undo information. I hope there would be no argument about that.


Для меня это тоже /не побоюсь этого слова:)/ кажется очевидным о чем я и спрашивала. Именно об этом я и говорила.

to Nikolay

Очень интересная статья! еще раз спасибо. Если не возражаете у меня есть пара вопросов.

Используется широко известный метод упреждающей журнализации (write ahead log, WAL), предполагающий, что записи о некоторой операции над базой данных попадают на жесткий диск раньше, чем в базу вносятся изменения, произведенные этой операцией.

Здесь отличий от Oracle нету.

Еще раз забудте про UNDO здесь его пока нет.

Как это нет? Давайте рассмотрим пример:

1) транзакция удалила строки
2) транзакция перезаписала во многих строках старые значения полей новыми (все изменения в оперативной памяти не помещаются)
3) коммит не пока не делается
4) происходит сбой

Вопрос

При восстановлении незакомиченные изменения нужно откатить. Где находится undo информация - данные удаленных строк, старые значения измененных строк? Разве не в журнале?

Поскольку в ARIES на журнал возлагается вся ответственность за восстановление данных , записи журнала достаточно сложны, содержат массу информации и в зависимости от журнализуемого действия имеют различную структуру. Скажем, запись, помещаемая при обычной работе транзакции, несколько отличается от так называемой компенсационной записи (compensation log record, CLR), помещаемой в случае частичного или полного отката транзакции.

to Nikolay

Спасибо за объяснения. Признаюсь, я не предполагала что в отношении redo logs у Oracle избыточность такого масштаба по сравнению с DB2. В общем теперь у меня есть более или менее реальное представление в этом вопросе.

to gvv

Using db2 governor, MQSeries, and OS level resource management (solaris and aix) we have an ability to assign resource (like CPU - first at all) to groups of tasks according their privileges.

В Oracle это встроенная фича. С пом. profiles можно ограничить

CPU_PER_SESSION
SESSIONS_PER_USER
CONNECT_TIME
IDLE_TIME
LOGICAL_READS_PER_SESSION

И с помощью resource manager можно делать fine grained management of CPU resources для различных групп - в зависимости от вида активности, времени суток (типа по выходным и внерабочее время можно на просмотр отчетов больше времени выделить).

direct access to a database have only a few rare running tasks with almost an access to summary tables, which do not compete with others tasks.

Обычный метод применения summary tables (materialized views) для разгрузки "горячих" таблиц со соответсующими соображениями - тратить ресурсы на их постоянное поддержание uptodate или позволить delay.

oralce memory management (different type of caches) looks poor if to compare even with sybase 10.x imho.

Ну, я еще не упомянула про multiple buffer pools в зависимости от размера блока заданного для объектов.
Возможно конечно, что такой уровень гранулярности как named pools позволяет творить чудеса. Хотелсь бы увидеть пример задачи/проблемы, которую можно эффективно решить используя named pools и которую было бы сложно или невозможно решить в модели Oracle. Гарантировано удержать важные объекты в кэше модель Oracle тоже позволяет.