Физический уровень работы транзакции в Oracle

dbstalker, 01 мая

Механизм работы транзакции основан на двух физических объектах: журнал повторного выполнения и сегмент отката. Сейчас и поговорим о них.

При выполнении оператора (insert, delete, update) генерируются:

  • данные отмены (undo), для того, чтобы при отмене транзакции можно было восстановить согласованное состояние базы данных на начало транзакции (накат назад). Данные отмены состоят из нескольких частей. Например, в данных отмены должны быть не только данные для отмены изменений в таблицах, но и в индексах. Данные отмены хранятся в сегментах отката. Сегменты отката хранятся в табличных пространствах.
  • Данные повторного выполнения, для того, чтобы в случае сбоя системы можно было восстановить согласованное состояние системы (накат вперед). Эти данные хранятся в журналах повторного выполнения. Журналы в ORACLE есть оперативные и архивные.
  • Данные повторного выполнения формируются также и на изменения в сегментах отката.

Возможные исходы при сбое

В буферном кэше после проведенных изменений находятся изменения блоков данных, блоков индексов, сегментов отката. А в буфере журнала повторного выполнения находятся данные повторного выполнения для сегментов отката, блоков данных, блоков индексов.

Возможны следующие варианты дальнейшего развития событий:

Сбой системы при выполнении транзакции

Если информация находилась только в SGA, и на диск ничего не переносилось, то после перезапуска системы, база данных будет в согласованном состоянии таком, как если бы мы транзакция не начиналась.

Если же буфер журнала повторного выполнения был сброшен на диск (это происходит при обработке контрольной точки, или каждые три секунды, или буфер заполнен на треть), то сценарий будет немного другим. После перезапуска системы, будет выявлено в журнале повторного выполнения некоторые записи повторного выполнения транзакции. Все эти данные будут накатаны (выполнены). Но потом обнаружится, что транзакция не зафиксирована, и будет проведен откат. База будет в согласованном состоянии, как будто транзакция не выполнялась вообще.

Если же на диск были частично перенесены кроме данных журналов повторного выполнения ещё и измененные блоки таблиц, индексов, то сценарий будет таковым: так как на изменения в сегментах отката есть записи в журналах повторного выполнения, то сегменты отката будут восстановлены после перезапуска, а система выполнит накат, затем откат. Даже если блоки таблицы были до сбоя записаны на диск, после перезагрузки блоки будут кэшированы, возвращены на основе данных сегментов отката в первозданное состояние и со временем будут сброшены на диск. Таким образом, база данных и при этих обстоятельствах в согласованном состоянии, в таком как была до начала транзакции.

Заполняется буферный кэш.

Запускается фоновый процесс lgwr, который на диск сбросит буфер журнала повторного выполнения, чтобы были защищены на случай сбоя как сегменты отката, так и блоки таблиц и индексов. И только после этого фоновым процессом dbwr будут блоки из буферного кэша сброшены на диск.

Заканчивается транзакция по commit.

Фиксация изменений никогда не занимает много времени. Еще до этой команды, скорее всего буфер журнала повторного выполнения сбрасывался на диск, и, возможно, измененные блоки из буферного кэша были сброшены на диск.

По команде commit генерируется для транзакции номер системного изменения (SCN), буфер повторного выполнения (все, что там ещё осталось) сбрасывается на диск в файлы журнала изменений, записывается в них же и SCN. Только после этого транзакция считается зафиксированной.

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

Блокировки снимаются.

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

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

Заканчивается транзакция по rollback.

Достаточно продолжительная операция, зависит от объема измененных данных. Буфер журнала повторного выполнения уже сбрасывался на диск, возможно, и часть измененных блоков из буферного кэша была сброшена на диск. Система вынуждена будет все соответствующие блоки с диска прочитать в кэш, откатить назад на основе данных сегментов отката. То есть выполнить все обратные операции. Снимутся все блокировки. Операция требуем много системных ресурсов.

ОднаКнопка

2 комментария

Прокоментировать

Anonymous
28 июня 2008 г. в 16:55

Опечатка:
redo log buffer сбрасывается на диск каждые три секунды, а не минуты

dbstalker
1 июля 2008 г. в 10:58

Благодарю! Надеюсь на такое же внимание к моему блогу и в дальнейшем.

 

Новый комментарий

Я не спамер: введите суму 5+4



 

От авторов блога

О Блоге - прочитай перед началом.

Задать вопрос и получить ответ - уже решено 94 вопросов

Глоссарий - список терминов и сокращений


 
 

Бизнес форум

Последние темы:

Шины бу
26 апреля, 2 ответа
Потрібна порада
25 апреля, 2 ответа
Посоветуйте адвоката
25 апреля, 1 ответа