При возникновении любого аппаратного или программного сбоя СУБД должна восстановить последнее согласованное состояние БД.
Основные принципы восстановлениязаключаются в следующем:
1) Результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии БД;
2) Результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии БД.
Основные функции восстановления, представляемыетипичной СУБД:
1) механизм резервного копирования, предназначенный для периодического создания копий базы данных;
2) средства ведения журнала транзакций, в котором фиксируются текущее состояние транзакций и вносимые в базу данных изменения;
3) функция создания контрольных точек, обеспечивающая перенос выполняемых в базе данных изменений во вторичную память с целью сделать их постоянными;
4) менеджер восстановления, обеспечивающий восстановление согласованного состояния базы данных, нарушенного в результате отказа.
8.2. Механизм резервного копирования.
Любая СУБД должна предоставлять механизм, позволяющий создавать резервные копии базы данных и ее файла журнала через установленные интервалы и без необходимости останавливать систему. Резервная копия базы данных используется в случае повреждения или разрушения файлов базы данных во вторичной памяти. Резервное копирование может выполняться для базы данных в целом или в инкрементном режиме. В последнем случае в копию помещаются сведения только об изменениях, накопившихся с момента создания полной предыдущей или инкрементной копии системы. Как правило, резервные копии создаются на автономных носителях. Для фиксации хода выполнения транзакций в базе данных СУБД использует специальный файл, который называют журналом транзакций.Он содержит сведения обо всех обновлениях, выполненных в базе данных. В файл журнала транзакций может помещаться следующая информация:
1) записи о транзакциях;
2) записи контрольных точек.
Записи о транзакциях включают:
1) идентификатор транзакции;
2) тип записи журнала (начало транзакции, операции вставки, обновления или удаления, отмена или фиксация транзакции);
3) идентификатор элемента данных, вовлеченного в операцию обработки базы данных (операции вставки, удаления и обновления);
4) копиюэлемента данных дооперации, т.е. его значение до изменения (только операции обновления и удаления);
5) копиюэлемента данных послеоперации, т.е. его значение после изменения (только для операций обновления и вставки);
6) служебную информацию файла журнала, включающую указатели на предыдущую и следующую записи журнала для этой транзакции (любые операции);
По причине его важности для процессов восстановления, файл журнала транзакций может создаваться в двух и даже в трех экземплярах, которые будут автоматически поддерживаться системой. В случае повреждения одной копии при восстановлении будет использоваться другая.
Один из подходов к автономной обработке файла журнала состоит в разделе оперативного файла журнала на две независимые части, организованные в виде записей с произвольным доступом. Записи журнала помещаются в первый файл до тех пор, пока он не оказывается заполненным до установленного уровня (например, на 70%). Затем открывается второй файл, и все записи журнала для новыхтранзакций записываются уже в него. Сведения о старыхтранзакциях помещаются в первый файл до пор, пока обработка всех старых транзакций не будет завершена. В этот момент первый файл закрывается и переводится в автономное состояние. Подобный подход упрощает восстановление отдельных транзакций, поскольку записи о каждой отдельной транзакции всегда содержатся в одном фрагменте файла журнала – либо в оперативном, либо в автономном. Следует отметить, что файл журнала потенциально является узким местом с точки зрения производительности любых систем, поэтому скорость записи информации в файл журнала может оказаться одним из важнейших факторов, определяющих общую производительность системы с базой данных.
