Изложено основное правило организации транзакций: они могут быть короткими или длинными - это определяется необходимостью. Размер транзакции определяется требованием целостности данных - вот основная мысль, которую мы пытались донести до вас в этой главе. Только установленные в системе правила обработки данных должны определять размер транзакций, но никак не размер сегментов отката и не количество блокировок.

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

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

Повторное выполнение и

откат

В главе 4 мы рассмотрели основы повторного выполнения и отката (отмены) транзакций. Там было описано, что такое данные повторного выполнения. Это данные, которые сервер Oracle записывает в активные файлы журнала для повторного выполнения транзакций в случае сбоя. Они позволяют серверу Oracle восстанавливать выполненные транзакции. Мы также рассматривали данные отмены, или отката, которые сервер Oracle записывает в сегменты отката для отмены, или отката, транзакции. Кроме того, мы затронули несколько проблем, например причины возникновения ошибки ORA-01555: snapshot too old или прекращения обработки контрольной точки (checkpoint not complete, cannot allocate new log). В этой главе я хочу более глубоко рассмотреть суть процессов повторного выполнения и отката, а также описать, что должны знать о них разработчики.

Повторное выполнение и откат - это темы, одинаково важные для администратора базы данных и для разработчиков. И тем, и другим необходимо глубокое понимание их назначения, алгоритмов работы, а также знание того, как избегать связанных с этими процессами проблем. Эта информация будет представлена в данной главе. Мы не будем касаться средств, использование и настройка которых является исключительной прерогативой администратор базы данных. Например, мы не будем рассматривать, как найти оптимальное значение параметров инициализации RECOVERY PARALLELISM или FAST START IO TARGET. Мы сконцентрируемся на проблемах, о которых должен знать разработчик, и на том, как они могут влиять на приложение.

Повторное выполнение

Файлы журнала повторного выполнения чрезвычайно важны для базы данных Oracle. Это журналы транзакций базы данных. Они используются только для восстановления; единственное их назначение - предоставить необходимую информацию в случае сбоя экземпляра или носителя. Если на машине, где работает сервер, пропадает питание, что приводит к сбою экземпляра, сервер Oracle будет использовать активные журналы повторного выполнения для восстановления системы в состояние на момент, непосредственно предшествующий отключению питания. Если происходит сбой диска, сервер Oracle будет использовать архивные журналы повторного выполнения для восстановления резервной копии этого диска на соответствующий момент времени. Кроме того, если случайно удалена таблица или важные данные и это изменение зафиксировано, можно восстановить потерянные данные с резервной копии, а затем с помощью активного и архивных файлов журнала повторного выполнения привести их в состояние, соответствующее моменту, непосредственно предшествующему этому случаю.

Сервер Oracle поддерживает два типа файлов журнала повторного выполнения: активные и архивные. В каждой базе данных Oracle есть по крайней мере два активных файла журнала повторного выполнения. Эти активные файлы журнала повторного выполнения используются циклически. Сервер Oracle будет выполнять запись в журнальный файл 1, а добравшись до конца этого файла, переключится на журнальный файл 2 и начнет записывать в него. Заполнив журнальный файл 2, он опять переключится на журнальный файл 1 (если файлов журнала повторного выполнения всего два; если их три, сервер, конечно же, переключится на третий файл). Архивные файлы журнала повторного выполнения - это просто копии старых, заполненных активных файлов журнала повторного выполнения. Когда система заполняет журнальные файлы, процесс ARCH копирует активный файл журнала повторного выполнения в другое место. Архивные файлы журнала повторного выполнения используются для восстановления носителя, когда сбой приводит к порче диска или в случае другого физического сбоя. Сервер Oracle может применять эти архивные файлы журнала повторного выполнения к резервным копиям файлов данных, чтобы привести их в соответствие с остальной базой данных. Эти журналы содержат хронологию транзакций в базе данных.

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

Важно понять, какое значение файлы журнала имеют для разработчиков. Мы рассмотрим, как различные способы написания кода влияют на использование журналов.