Журнализация транзакций

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

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

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

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

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

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

Архивирование

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

Реализации

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

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

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