to riman

По моим представлениям - это объекты в памяти, хранящие изменения в БД. Эти изменения периодически скидываются на диск, во время простоев или в т.п. ситуациях. А если произошел сбой в питании? Данные теряются что ли? Видимо я что то неправильно понял

Нет, есть непосредтвенно блоки данных и есть redo журнал, это две разные разницы. Реду журнал пишется постоянно и без кэширования, сразу на диск - в режиме O_SYNC. Успешность коммита подтверждается тогда и только тогда, когда все redo entries, относящиеся к транзакции, сброшены на диск.

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

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

См. также

Advantages of the Fast COMMIT
The fast commit mechanism ensures data recovery by writing changes to the redo log
buffer instead of the data files. It has the following advantages:
• Sequential writes to the log files are faster than writing to different blocks in the
data file.
• Only the minimal information that is necessary to record changes is written to the
log files, whereas writing to the data files would require whole blocks of data to be
written.
• If multiple transactions request to commit at the same time, the instance
piggybacks redo log records into a single write.
• Unless the redo log buffer is particularly full, only one synchronous write is
required per transaction. If piggybacking occurs, there can be less than one
synchronous write per transaction.
• Because the redo log buffer may be flushed before the COMMIT, the size of the
transaction does not affect the amount of time needed for an actual COMMIT
operation.
Note: Rolling back a transaction does not trigger LGWR to write to disk. The Oracle
server always rolls back uncommitted changes when recovering from failures. If there
is a failure after a rollback, before the rollback entries are recorded on disk, the
absence of a commit record is sufficient to ensure that the changes made by the
transaction are rolled back.

to riman

Both products can be used to build stable and efficient system and the stability ...

Безусловно. У обеих баз есть свои сильные и слабые стороны. Мне просто было интересно узнать о них. Как я уже писала я действительно была впечатлена "спосбоностью" оптимайзера DB2, если он действительно такой умный.

И, согласитесь, например метод реализации блокировок в Oracle при котором

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

тоже заслуживает уважения.

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

to Nikolay

Я вас уверяю идеологически у всех почти все одно и тоже.

Иначе я и не думала. Трудно представить, как это могло бы быть сделано подругому. Просто riman спросил про redo, я ему ответила и указала на разницу работы с самими данными и с журналом. Вопрос опять же, в способах реализации механизма защиты/отката сделанных изменений.

У Оracle в отличии от остальных надо писать еще в UNDO tablespaces. Что опять есть дополнительная нагрузка на IO. С другой стороны это плюс для выполнения отчетов по OLTP системе.


Да, общий прирост в нагрузке на IO есть, но он частично компенсирован облегчением нагрузки на redo журнал. Откатывать транзакцию и восстанавливать версии данных на определенное состояние эффективнее/быстрее с пом. rollback segments чем проигрывая redo журнал в обратном направлении. rollback segments также цена за отсутстсвие блокировок при чтении/изменении. Классическая дилема - память/быстродейтвие.

PS
Ссылку посмотрю, может еще вопросы возникнут:)

to Nikolay

Эффективнее использовать UNDO вместо REDO в Oracle, не в DB2.

Не сомневаюсь. Естественно раз UNDO информация также лежит в журнале, оптимизация идет в направлении эффективного отката с пом. redo журнала. Я говорю о разделении следующих задач в Оракл

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

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

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

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

Насколько я знаю в 8.2 будет вещь сходная с HINTS только с моей точки зрения реализованная более красиво. Optimization profiles. Некоторый XML документ сужающий для оптимизатора список возможных вариантов оптимизации. Опятьже это делает администратор а не разработчик. Исходя из данных (знаний) которые оптимизатору могут быть не доступны


В Oracle есть несколько похожая фича - execution plan outlines.

Для Ораклоидов

Вот нашла интересную статью про LEO

http://www.citforum.ru/database/articles/leo.shtml

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

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

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

to riman

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


Нее, я не имела в виду, встроенный язык программирования. У Oracle PL/SQL в этом отношении тоже не слабый. И также есть поддержка явы.

Меня интересует именно чистый SQL, который якобы позволяет делать некоторые вещи, для которых в других СУБД пришлось бы прибегать к встроенному языку программирования.
Как говорит Том Кайт

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

вот хотелось бы конкретный пример мощности чистого SQL. Так что пока не приведете пример, буду считать высказывание о SQL энджине мифом:)

Я где то читал, что PL/SQL у Oracle богаче.

Сравнить не могу, скажу что PL/SQL действительно полноценный многофункциональный язык. Например в PL/SQL есть триггреры на DDL.