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

L выполнения

Теперь на диске могут оказаться и блоки, но мы этот случай не рассматриваем. Затем мы изменяем данные. Происходит примерно то же самое. В этот раз объем данных отмены больше (теперь в результате изменения нам надо сохранить ряд предваритель-н1х образов). Имеем следующую картину:

: Буферный

----------

Буфер журнала повторного выполнения

Юегмент отката

=5 г~

Индекс 1 Таблица Т

Журнал Ez

ПОВТОРНОГО

выполнения

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

Гипотетический сценарий: сбой системе! происходит в этот момент. При запуске сервер Oracle будет считывать журналы повторного выполнения и обнаружит ряд записей повторного выполнения транзакции. С учетом состояния системы (записи повторного выполнения для оператора вставки находятся в файлах журнала на диске, а записи повторного выполнения для оператора изменения - все еще в буфере) сервер Oracle на-

катит (roll forward) вставку. В результате получится схема, аналогичная первой: в памяти имеется ряд блоков отмены из сегмента отката (для отмены вставки), измененные (после вставки) блоки таблицы и измененные (после вставки) блоки индекса. Теперь сервер Oracle обнаружит, что транзакция не зафиксирована, и откатит ее, поскольку выполняется восстановление после сбоя, а наш сеанс, конечно же, не подключен. Сервер прочитает данные отмены, помещенные при накате в буферный кэш, и применит к блокам данных и индексов, приводя их к состоянию, которое было до вставки. Все вернулось на свои места. Блоки на диске могут отражать (или не отражать) результаты выполнения оператора INSERT (это зависит от того, были ли они сброшены на диск перед сбоем). Если были, значит, вставка отменена, и при сбросе блоков из буферного кэша на диск эта отмена будет отражена и в файлах данных. Если же результатов вставки в этих блоках нет, - пусть так и будет, их все равно потом перезапишут.

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

Первый сценарий затрагивает некоторые детали восстановления в случае сбоя. Сервер выполняет его за два шага. Сначала он накатывает изменения, приводя систему к состоянию на момент сбоя, после этого откатывается все, что не было зафиксировано. Это действие повторно синхронизирует файлы данных. Сервер повторно выполняет все действия, а затем отменяет все, что не было завершено.

Со вторым сценарием мы сталкиваемся намного чаще. Следует помнить, что в ходе отката журналы повторного выполнения никогда не используются. Журналы повторного выполнения читаются только при восстановлении и архивировании. Это ключевая концепция настройки: журналы повторного выполнения - только для записи. В ходе обычной обработки сервер Oracle их не читает. Если имеется достаточное количество устройств, т.е. при считывании процессом ARCH файла процесс LGWR выполняет запись на другое устройство, конфликты доступа к журналам повторного выполнения не возникают. Во многих других СУБД файлы журналов используются, как журналы транзакций . В них нет разделения данных повторного выполнения и отмены - и те, и другие хранятся в одном файле. Для таких систем откат может оказаться катастрофой: в процессе отката должны считываться журналы, в которые выполняет запись процесс, сбрасывающий буферы журнала. В результате конфликты возникают в той части системы, где они наименее желательны. Разработчики Oracle постарались сделать так, чтобы журналы записывались последовательно и никто не читал бы их в процессе записи.

Теперь переходим к оператору DELETE. И в этом случае генерируются данные отмены, блоки изменяются, а записи повторного выполнения отправляются в буфер журнала повторного выполнения. Это мало отличается от обработки оператора UPDATE, рассмотренной ранее, поэтому перейдем к оператору COMMIT. При обработке этого оператора сервер Oracle сбросит буфер журнала повторного выполнения на диск, и схема происходящего будет выглядеть примерно так:

Буферный кэш

Буфер журнала повторного 1 \ 1 выполнения

Сегмент отката Индексы ТаблицаТ

Журнал

ПОВТОРНОГО

.вы1полнения .

Измененные блоки находятся в буферном кэше; возможно, некоторые из них были сброшены на диск. Все данные повторного выполнения, необходимые для восстановления транзакции, находятся в безопасности на диске, и теперь изменения стали постоянными. Если придется считывать данные непосредственно из файлов данных, то блоки будут получены в том состоянии, в котором они находились перед началом транзакции, поскольку процесс DBWR их скорее всего еще не записал. Это нормально: в случае сбоя записи в журнале повторного выполнения можно будет использовать для восстановления блоков. Данные отмены будут сохраняться еще некоторое время - до повторного использования сегмента отката и перезаписи соответствующих блоков. Сервер Oracle с помощью этих данных отмены обеспечит согласованное чтение измененных объектов любыми сеансами, которым это надо.

Резюме

В этой главе мы рассмотрели различные аспекты управления транзакциями в Oracle. Поддержка транзакций - одна из основных особенностей, отличающих базу данных от файловой системы. Понимание их механизма и способов использования необходимо для создания корректно работающих приложений для любой СУБД. Понимание того, что в Oracle все операторы (включая их побочные эффекты) - неделимы и что эта неделимость распространяется на хранимые процедуры, имеет принципиальное значение. Мы показали, как добавление обработчика исключительных ситуаций WHEN OTHERS в блок PL/SQL может радикально повлиять на изменения в базе данных. Для разработчиков приложений глубокое понимание работы транзакций принципиально важно.

Мы рассмотрели весьма сложное взаимодействие требований целостности (уникаль-н]х ключей, требований проверки и т.д.) и транзакций в Oracle. Б]ло описано, что сервер Oracle обычно обрабатывает требования целостности сразу после выполнения оператора, но при желании можно отложить проверку требований до конца транзакции. Эта возможность является ключевой при выполнении сложных многотабличных изменений, когда изменяемые таблицы - взаимозависимы. В качестве примера рассматривалось каскадное изменение.

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