Журнализация изменений БД
Общие принципы восстановления:
- результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных;
- результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных.
Ситуации, при которых требуется производить восстановление состояния базы данных:
- Индивидуальный откат транзакции.
- Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой).
- Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой).
Журнализация и буферизация
Два вида буферов - буфер журнала и буфер страниц оперативной памяти, которые содержат связанную информацию.
Индивидуальный откат транзакции
Индивидуальный откат транзакции выполняется следующим образом:
- Выбирается очередная запись из списка данной транзакции.
- Выполняется противоположная по смыслу операция: вместо операции INSERT выполняется соответствующая операция DELETE, вместо операции DELETE выполняется INSERT, и вместо прямой операции UPDATE обратная операция UPDATE, восстанавливающая предыдущее состояние объекта базы данных.
- Любая из этих обратных операций также журнализуются.
- При успешном завершении отката в журнал заносится запись о конце транзакции.
Восстановление после мягкого сбоя
Основная проблема восстановление после мягкого сбоя - одна логическая операция изменения базы данных может изменять несколько физических блоков базы данных.
К моменту мягкого сбоя возможны следующие состояния транзакций:
- Для транзакции T1 никаких действий производить не требуется. Она закончилась до момента t1pc, и все ее результаты отражены во внешней памяти базы данных.
- Для транзакции T2 нужно повторно выполнить оставшуюся часть операций (redo).
- Для транзакции T3 нужно выполнить в обратном направлении первую часть операций (undo).
- Для транзакции T4, которая успела начаться после момента t1pc и закончиться до момента мягкого сбоя, нужно выполнить полную повторную прямую интерпретацию операций (redo).
- Для начавшейся после момента t1pc и не успевшей завершиться к моменту мягкого сбоя транзакции T5 никаких действий предпринимать не требуется. Результаты операций этой транзакции полностью отсутствуют во внешней памяти базы данных.
Физическая согласованность базы данных
Два основных подхода обеспечения наличия точек физической согласованности базы данных: подход, основанный на использовании теневого механизма, и подход, в котором применяется журнализация постраничных изменений базы данных.
Общая идея теневого механизма:
Журнализация постраничных изменений. Первый: постраничный откат незакончившихся логических операций. Второй: поддержание отдельного (короткого) журнала постраничных изменений.
Восстановление после жесткого сбоя
Основа восстановления - журнал и архивная копия базы данных.
Если нельзя восстановить БД после сбоя автоматически, восстановление БД выполняется в два этапа:
- перенос на рабочий диск резервной копии базы данных (или той её части, которая была повреждена);
- перезапуск сервера БД с повторным проведением всех транзакций, зафиксированных после создания резервной копии и до момента возникновения сбоя.
В результате сбоя могут возникнуть две потенциальные ситуации:
- Блоки, содержащие подтверждённые модификации, не были записаны в файлы данных, так что эти изменения отражены лишь в журнале транзакций. Следовательно, журнал транзакций содержит подтверждённые данные, которые должны быть переписаны в файлы данных.
- Журнал транзакций и блоки данных содержат изменения, которые не были подтверждены. Изменения, внесенные неподтверждёнными транзакциями, во время восстановления БД должны быть удалены из файлов данных.
Для того чтобы разрешить эти ситуации, СУБД автоматически выполняет два этапа при восстановлении после сбоев: прокрутку вперед и прокрутку назад.
- Прокрутка вперед заключается в применении к файлам данных всех изменений, зарегистрированных в журнале транзакций. После прокрутки вперед файлы данных содержат все как подтверждённые, так и неподтверждённые изменения, которые были зарегистрированы в журнале транзакций.
- Прокрутка назад заключается в отмене всех изменений, которые не были подтверждены. Для этого используются журнал транзакций и сегменты отката, информация из которых позволяет определить и отменить те транзакции, которые не были подтверждены, хотя и попали на диск в файлы БД.