Добрый день !

Вчера разобрались с тем, что хранится в transaction log — ms sql — спасибо Merle за помощь.
Но этот вопрос был как бы подготовкой к сегодняшнему вопросу

Проблема в том, что я как человек выросший на MS SQL (который имеет всего одну сущность для хранения истории состояний БД — transaction log), никак не могу понять — в чем различие между двумя этими механизмами в Oracle ?


Спасибо за помощь.

Здравствуйте, DemAS, Вы писали:

Насколько я понимаю то различия следующие:

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

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



DAS> Спасибо за помощь.

Здравствуйте, DemAS, Вы писали:

В redo log записываются все изменения с БД.
А нужен он для восстановления основных datafile'ов.

Подробнее:

Oracle 9i Database Concepts, 
    Part I - What is Oracle?, 
        Chapter 1 - Introduction to the Oracle Server, 
            страница 1-7.

Здравствуйте, DemAS, Вы писали:

DAS> Проблема в том, что я как человек выросший на MS SQL (который имеет всего одну сущность для хранения истории состояний БД — transaction log), никак не могу понять — в чем различие между двумя этими механизмами в Oracle ?

В rollback пишутся старые версии блоков, чтобы, например, в случае долго выполняющегося запроса можно было восстановить блоки в том виде, в каком они были на момент _начала_ запроса — "read consistency". Если запрос выполняется два дня, и за это время изменились данные, то они будут выведены в том виде, в каком они были два дня назад — соответствующие версии данных хранятся в rollback-ах. Цель — не блокировать таблицу для изменений на два дня.

В redo log пишется как содержимое операций insert/update/delete/truncate (+ commit | rollback), так и содержимое соответствующих им rollback-записей. До версии 10g они писались туда попарно ("before image" + "after image"), теперь все немного сложнее, но суть та же. Смысл redo log-а — абсолютно тот же, что и в MSSQL: write-ahead. То есть защитить данные от вещей типа выключения питания. Защищаются как сами данные, так и rollback, чтобы при восстановлении база накатилась точно до того состояния, в котором она была на момент аварии. Затем незакоммиченные транзакции откатываются обратно.

Все это и многое другое есть в разделе "Concepts" документации.

Здравствуйте, SQE, Вы писали:

SQE>В онлайновом журнале повторения храняться записи о подтвержденных, но еще не записанных транзакциях.

Что такое "подтвержденная, но еще не записанная транзакция" ? Подтвержденная транзакция — это транзакция уже завершившаяся COMMIT-ом.
А что значит не записанная ? И куда не записанная ? В redo log ? Так это redo log buffer cache как я понял.

SQE>В сегментах отката содержатся данные, о еще не подтвержденных транзакциях.

Что за данные ?
Например при такой транзакции (псевдокод):

        начало транзакции;
        select ....  from t1;
        insert ... values(...) t2;
        delete t3 where ....;
        update t4 set .... where ...;

какая именно информация попадет в rollback segment ?

Далее, из твоих утверждений, что:
1) все что попало в redo log, прошло (когда-то) через rollback segments.
2) все что "записалось" (опять же вопрос — куда ?) удаляется из redo log-а
Это так ?

Далее — redo log -и можно автоматически архивировать. Зачем это может понадобится. Какой смысл в архивировании подтвержденных, но не записанных транзакциях ? Не проще из "записать" ?

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

Ага ? Как я понял из этого утверждения — "записанная" запись все-таки не удаляется из redo log, а продолжает храниться там. Так ?
То есть, в моем понимании redo log — это просто журнал всех изменений совершенных с БД. И в нем хранится информация о том, что в такой то момент времени такой-то экстенд был изменен с такого то значения, на такой. О том, что в этот момент времени был удалена такая-то запись из такого-то сегмента. Так ?

На основании твоих замечаний и своих предположений попробую с формулировать след. утверждение:
MS SQL хранит всю информацию о транзакциях (как завершившихся, так и нет) в одном файле — transaction log, в то время как в Oracle информация о завершенных и незавершенных транзакциях хранится отдельно в разных структурах.
Это так ?

Здравствуйте, SQE, Вы писали:

SQE>Насколько я понимаю то различия следующие:

SQE>В онлайновом журнале повторения храняться записи о подтвержденных, но еще не записанных транзакциях.
В redo log идут записи обо _всех_ транзакциях. См. мой пост ниже.

SQE>В сегментах отката содержатся данные, о еще не подтвержденных транзакциях.
В rollback-ах содержатся старые версии измененных данных. Как закоммиченные, так и нет.

Здравствуйте, <Аноним>, Вы писали:

А>В rollback пишутся старые версии блоков, чтобы, например, в случае долго выполняющегося запроса можно было восстановить блоки в том виде, в каком они были на момент _начала_ запроса — "read consistency". Если запрос выполняется два дня, и за это время изменились данные, то они будут выведены в том виде, в каком они были два дня назад — соответствующие версии данных хранятся в rollback-ах. Цель — не блокировать таблицу для изменений на два дня.

То есть, в rollback хранятся старые копии(версии) всех блоков, измененных транзакцией ? При чем, как я понял, сама причина изменения содержимого этих блоков там не фиксируется (те самые insert, delete, update) ?

А>В redo log пишется как содержимое операций insert/update/delete/truncate (+ commit | rollback),

А информация об этих insert/update/delete хранится в redo log. Так ?

А>так и содержимое соответствующих им rollback-записей.

То есть после коммита транзакции, старые версии блоков копируются в redo log ?

Хм... тогда возникает вопрос — а почему эти старые версии блоков сразу не помещать в redo log ? Зачем их сначала писать в отдельную структуру, а потом все-таки копировать в redo-log ?

Здравствуйте, Sergey Ten, Вы писали:

ST>В redo log идут записи обо _всех_ транзакциях. См. мой пост ниже.

Как я понял, Аноним ответивший на мой вопрос выше — это ты ?
Я тогда здесь продублирую оценку — чтобы она все-таки тебе досталас — действительно полезный мне ответ.

Здравствуйте, DemAS, Вы писали:

DAS> То есть, в rollback хранятся старые копии(версии) всех блоков, измененных транзакцией ? При чем, как я понял, сама причина изменения содержимого этих блоков там не фиксируется (те самые insert, delete, update) ?

Причина изменения нв rollback-е не фиксируется — она фиксируется в redo. В rollback идет лишь SCN — sequence change number, чтобы было понятно, на какой момент времени эти "старые" данные числились еще "новыми".

DAS> А информация об этих insert/update/delete хранится в redo log. Так ?
Так.

DAS> То есть после коммита транзакции, старые версии блоков копируются в redo log ?
Нет, коммит здесь не причем. В redo сразу пишутся как insert, так и rollback — в одну redo запись пишутся предыдущие и измененные данные, _попарно_ и сразу, не дожидаясь коммита. Если все рухнуло до коммита, то при следующем старте базы данные берутся из redo log-а. Оттуда же берутся все rollback-блоки. Оттуда же берутся записи о коммитах. Затем все это вместе сопоставляется и делается вывод, какие данные было прокоммичены (будут записаны на диск, если, скажем, на момент катастрофы коммит для них уже прошел, но они все еще находились в кэше), а какие прокоммичены не были — для них будет произведен откат. Данные для отката есть в rollback-e, восстановленном из того же redo.

Здравствуйте, Sergey Ten, Вы писали:

DAS>> То есть после коммита транзакции, старые версии блоков копируются в redo log ?
ST>Нет, коммит здесь не причем. В redo сразу пишутся как insert, так и rollback — в одну redo запись пишутся предыдущие и измененные данные, _попарно_ и сразу, не дожидаясь коммита. Если все рухнуло до коммита, то при следующем старте базы данные берутся из redo log-а. Оттуда же берутся все rollback-блоки. Оттуда же берутся записи о коммитах. Затем все это вместе сопоставляется и делается вывод, какие данные было прокоммичены (будут записаны на диск, если, скажем, на момент катастрофы коммит для них уже прошел, но они все еще находились в кэше), а какие прокоммичены не были — для них будет произведен откат. Данные для отката есть в rollback-e, восстановленном из того же redo.

Тогда вообще не понял — зачем нужен rollback, если он фактически продублирован в redoLog'е ?

Здравствуйте, DemAS, Вы писали:

DAS>Здравствуйте, Sergey Ten, Вы писали:

DAS> Тогда вообще не понял — зачем нужен rollback, если он фактически продублирован в redoLog'е ?

Для обеспечения "read consistency" — данных в том виде, в котором они были на момент начала запроса. Redo log — вещь по сути своей последовательная, и доставать старые данные оттуда (особенно из архивов) — занятие еще то. Придется перелопачивать десяток архивов для чтения одного блока, так как в redo уже записалась пара гигабайт активности против других таблиц, и где находится нужная тебе версия блока нужной тебе таблицы — одному Ему известно.

Здравствуйте, DemAS, Вы писали:

DAS> Спасибо за помощь.
Кстати, для ознакомления с принципами работы журналов, тем какие они бывают (redo/undo/redo+undo/no redo+no undo и т. д.) и зачем они вообще нужны, очень рекомендую почитать книжку Бернстайна.
Concurrency Control and Recovery In Database Systems
Там отдельная глава посвященная как раз Recovery и журналированию, где все очень толково расписано. Книжка валяется в свободном доступе.

Что же касается конкретно Оракла, то формально там так же присутствуют и Redo и Undo журналы, но они разнесены по разным группам файлов. Одна из основных причин этого заключается в том, что в версионнике, каковым Оракл отчасти является, вероятность отката транзакции гораздо выше, и чтобы не создавать ненужного ажиотажа при доступе к диску со стороны транзакций сбрасывающих Redo данные и откатывающихся (которым нужны Undo данные), сделано так, чтобы они писали и читали в разные места. Тем более, что журналы очень любят последовательный доступ.
Если я ошибся, то Sergey Ten меня поправит...

Здравствуйте, Merle, Вы писали:

M>Если я ошибся, то Sergey Ten меня поправит...


В общем, осталось подвести резюме: redo — для защиты от сбоев, rollback — для версионности. Ну и заметить, что в "нормальном" режиме работы Oracle только пишет в redo log, и никогда не читает. А читает только при восстановлениях после сбоев.

Кстати, о книгах. Если есть под рукой первая книга Тома Кайта, то там есть глава, которая так и называется — "Redo and Rollback".