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

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

• порядковый номер, тип и время изменения;
• идентификатор транзакции ;
• объект, подвергшийся изменению (номер хранимого файла и номер блока данных в нём, номер строки внутри блока);
• предыдущее состояние объекта и новое состояние объекта.

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

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

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

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

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

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

Мультиплексирование

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

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

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

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

Реализации

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

Oracle Database

В Oracle Database используются журналы изменений двух видов: циклический оперативный журнал повтора ( redo log ) и архивный журнал повтора ( archive log ), в которой переносятся записи из первого журнала при прохождении полного цикла первого. Оба журнала записываются на постоянный носитель, в оперативный журнал данные об операции попадают в момент перед фиксацией данных на энергонезависимом носителе, архивный журнал работает только в особом режиме поддержки журнального архивирования базы данных ( archivelog ). Информация из журналов изменений не используется для отката транзакции, но применяется для восстановления. Процесс восстановления производится администратором с использованием резервной копии базы данных и последовательного приложения к ней архивных журналов и журналов повтора.

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

Informix

В СУБД Informix журнал изменений представляет собой дисковое пространство, разделённое на части, называемые файлами журнала транзакций (эти файлы не имеют ничего общего с файлами на файловой системе) или логическим журналом . Запись изменений в этот журнал зависит от того, в каком режиме находится база данных — без журналирования, с буферизованным журналированием или с небуферизованным. Все изменения сначала попадают в буфера логического журнала, а дальнейший сброс их в журнал транзакций зависит от режима журналирования базы данных.

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

См. также

• Журнализация изменений проекта

Примечания

Литература

• К. Дж. Дейт Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2006. — С. 1328. ISBN 0-321-19784-4
• Томас Коннолли, Каролин Бегг Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management Third Edition. — 3-е изд. — М.: «Вильямс», 2003. — С. 1436. ISBN 0-201-70857-4