Лекция 3. Журнализация и восстановление

Лекция 3. Журнализация и восстановление

Журнал транзакций.

Транзакция – последовательность операций над базой данных, отслеживаемая системой управления БД от начала до завершения как единое целое.

Выделяют следующие типы транзакций:

· Плоские или классические (традиционные);

· Цепочечные;

· Вложенные.

Плоские и классические транзакции характеризуются следующими свойствами:

· Атомарности выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе.

· Согласованности, которое гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое – транзакции не разрушают взаимной согласованности данных;

· Изолированности означает, что конкурирующие за доступ к БД транзакции физически обрабатываются последовательно, изолированно друг от друга, но для пользователей это выглядит так, как будто они выполняются параллельно.

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

Журнал транзакций – это некоторая системная структура, которая обеспечивает реализацию в СУБД принципа сохранения промежуточных состояний, подтверждения или отката транзакции специальным механизмом.

Журнал транзакций содержит дополнительную информацию об изменениях БД и предназначен для обеспечения надежного хранения данных в БД.

Возможны два основных варианта ведения журнальной информации:

· Отдельный локальный журнал, который поддерживается для каждой транзакции и используется для индивидуальных откатов транзакций;

· Общий журнал изменений БД, используемый для восстановления состояния БД после мягких и жестких сбоев.

Структура журнала условно м. б. представлена в виде последовательного файла, в котором фиксируется каждое изменение БД. Каждая запись в журнале транзакций помечается номером транзакции, к которой она относится, и значениями атрибутов, которые она меняет.

Откат транзакции выполняется следующим образом:

· Выбирается очередная запись из списка данной транзакции;

· Выполняется противоположная по смыслу операция, восстанавливающая предыдущее состояние объекта БД;

· Любая из обратных операций также заносится в журнал.

· При успешном завершении отката в журнал заносится запись о конце транзакции.

Цель журнализации изменений БД – обеспечение возможности восстановления согласованного состояния БД после любого рода сбоев (аппаратных и программных). Основой поддержания целостного состояния БД является механизм транзакций.

Одним из основных требований к СУБД является надежность хранения данных во внешней памяти.

Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя.

Обычно рассматриваются два вида аппаратных сбоев:

· мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания);

· жесткие сбои, характеризуемые потерей информации на носителях внешней памяти.

Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.

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

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

Во всех случаях придерживаются стратегии " упреждающей " записи в журнал (так называемого протокола Write Ahead Log - WAL ). Эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

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

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

Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД.

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

Контрольные вопросы

1. Что такое транзакция?

2. Назовите типы транзакций и их свойства.

3. Что такое журнал транзакций?

4. Какие существуют варианты ведения журнальной информации?

5. Воспроизведите алгоритм отката транзакций.

6. Сформулируйте цель журнализации изменений БД.

7. Назовите виды аппаратных сбоев

8. Как вы понимаете термин «избыточность хранения данных».

9. В чем суть стратегии «упреждающей» записи?

10. Какие способы восстановления данных после мягких сбоев вы знаете?

11. Какие способы восстановления данных после жестких сбоев вы знаете?