oracle: transaction. Транзакция. Физический уровень выполнения

Источник Транзакция. Физический уровень выполнения

Транзакция. Физический уровень выполнения

Как организован механизм транзакции на физическом уровне? Какие физические объекты ORACLE задействованы при выполнении транзакции? Что происходит при сбое системы? Насколько надежен механизм транзакции?


Механизм работы транзакции основан на двух физических объектах: журнал повторного выполнения и сегмент отката. При выполнении оператора (insert, delete, update) генерируются:

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

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

• происходит сбой системы
• заполняется буферный кеш
• заканчивается транзакция по commit
• заканчивается транзакция по rollback

Происходит сбой системы.

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

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

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

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

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

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

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