4. 38. Журнализация и буферизация в субд.

5. 39. Журнализация. Связь с восстановлением бд. (вместе с 38)

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

Типичная СУБД должна предоставлять такие функции восстановления, как:

1. механизм резервного копирования, предназначенный для периодического создания копий базы данных;

2. средства ведения журнала, в котором фиксируются текущее состояние транзакций и вносимые в базы данных изменения;

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

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

Возможны следующие ситуации, при которых требуется производить восстановление состояния базы данных:

1. Индивидуальный откат транзакции. Типичной ситуацией отката транзакции является ее завершением оператором ROLLBACK; откат транзакции может быть инициирован системой. Для восстановления согласованного состояния базы данных при индивидуальном откате транзакции нужно устранить последствия операторов модификации базы данных, которые выполнялись в этой транзакции.

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

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

Файл журнала.

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

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

• результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных;

• результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных.

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

Основой восстановления является избыточное хранение данных; эти данные хранятся в журнале, содержащем последовательность записей об изменении базы данных. Возможно два варианта ведения журнальной информации:

1. в первом варианте - для каждой транзакции поддерживается отдельный локальный журнал изменений базы данных этой транзакции и может поддерживаться в оперативной (виртуальной) памяти; кроме того, поддерживается общий журнал изменений базы данных. Этот вариант позволяет быстро выполнить индивидуальные откаты транзакций, однако приводит к значительному дублированию информации в локальных и общем журналах;

2. Второй вариант - поддержание только общего журнала изменений базы данных, который и применяется выполнении индивидуальных откатов. Так как второй вариант применяется наиболее часто в СУБД, рассмотрим его более подробно.

Журнализация и буферизация.

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

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

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

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

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

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

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

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