Тема 5.9 Восстановление информации в базах данных

Алгоритмы восстановления основаны на двух базовых средствах — ведении журнала и поддержке теневых состояний сегментов. Нет смысла повторяться и останавливаться на принципах механизма журнализации и правила \УАЬ; рассмотрим подробнее вопросы, не затронутые ранее.

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

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

Следует отметить, что на самом деле теневой механизм используется не для упрощения процедуры восстановления после мягкого сбоя, а в связи с тем, что восстановление БД можно начинать только от ее физически согласованного состояния. Дело в том, что в журнал помещается информация об изменении объектов БД, а не страниц. Например, в журнале может находиться информация о модификации кортежа в виде триплета <tid, старое состояние кортежа, новое состояние кортежа>. Реально же при выполнении операции модификации изменяются несколько страниц: исходная страница; возможно, страница замены, если кортеж не поместился в исходную страницу; страницы индексом. И так происходит при выполнении любой операции изменения БД. Поскольку буфера страниц выталкиваются во внешнюю память по отдельности, то к моменту мягкого сбоя во внешней памяти может возникнуть набор физически рассогласованных страниц, не соответствующий никакой журнализуемой операции. При таком состоянии внешней памяти восстановление по журналу невозможно.

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

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

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

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