15. Журнализация изменений бд

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

Восстановление БД может производиться в следующих случаях:

1. Индивидуальный откат транзакции. Индивидуальный откат транзакции может быть инициирован либо самой транзакцией путем подачи команды Roll Back, либо системой. СУБД может инициировать откат транзакции в случае возникновения какой-нибудь ошибки либо, если эта транзакция выбрана в качестве жертвы при разрешении тупика.

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

3. Жесткий сбой системы (аварийный отказ аппаратуры) - характеризуется повреждением внешних носителей памяти. Жесткий сбой может произойти, например, в результате поломки головок дисковых накопителей (физическая поломка).

Во всех 3-х случаях основой восстановления является избыточность данных, обеспечиваемая журналом транзакции.

Поддерживается 2 вида буферов:

1. Буферы страниц БД;

Буферы журнала транзакции;

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

Имеются 2 причины для периодического выталкивания страниц во внешнюю память:

1. Недостаток ОП;

2. Возможность сбоев;

Основным принципом согласованной политики выталкивания буфера журнала и буфера страниц БД является то, что запись об изменении объекта БД должна попадать во внешнюю память журнала раньше, чем измененный объект оказывается во внешней памяти БД. Соответствующий протокол журнализации называется WHL (write a head lock - пиши сначала в журнал) и состоит в том, что, если требуется вытолкнуть во внешнюю память измененный объект БД, то перед этим нужно гарантировать выталкивание во внешнюю память журнала записи об его изменении.

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

Индивидуальный откат транзакции.

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

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

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

Восстановление после мягкого сбоя.

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

Восстановление после жесткого сбоя.

При жестком сбое, БД на диске нарушается физически. Основой восстановления в этом случае является журнал транзакции и архивная копия БД. Архивная копия БД должна создаваться периодически, а именно, с учетом скорости наполнения журнала транзакции.

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

Имеется несколько способов создания архивной копии БД:

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

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